New to Agile? Use a Rules of Engagement document.
How do we work together? Seems like a simple question, right? How wrong you could be! For an agile team, working together is vitally important, but it is also the hardest thing to accomplish. Why? Because we don’t normally work together very well. Think about the stereotypical high tech company and their sterile cubicles with “resources” working hard in isolation. This is a far cry from the PEOPLE on an effective agile team who work in an open, collaboration friendly environment. (In case you can’t tell, I have a pet peeve about calling people anything except people – in my opinion it is degrading to call people anything else) But this isn’t the only problem…
Once we get the team working well together, we still have those pesky PEOPLE known as managers and executives that want to pry into every little detail. Sorry, but that isn’t very agile, so wouldn’t it be nice if we could keep them from doing it? What about the product people constantly changing the focus of the team on a day to day basis? Or how about fixing the problem of the development manager constantly trying to tell the team they can do more work than is possible? All of these things and many more come into play when we talk about the seemingly simple question “How do we work together?”
Because all of these things add up in a hurry, I encourage teams to put together a rules of engagement document to make clear some of the most basic rules and interactions. I do this in conjunction with having the team determine their definition of what “done” means. Both of these items are completed prior to starting the first iteration. For maximum effectiveness have the team, managers and executives all sign the document as a sort of contract among themselves. Having executives sign the document is extremely empowering to the team and helps them recognize they have the full support of the organization to be successful!
Feel free to use my sample Rules of Engagement document for your team. If you make changes, please leave a comment here so I can consider making your change to the master document I use when I train teams. If you have questions about the document either leave a comment here or email me and I’ll try to get you an answer. This way we all can learn and improve this document for the teams that will use it in the future.
Until next time I’ll make sure teams I train use a Rules of Engagement document because it provides a lot of help in Making Agile a Reality™ for an organization.
Darn, this didn’t fit into a twitter response. This is very useful, Thank you!
Thoughts for your next round of editing…
Should “The team will” be “The team member will”, or will that help break the first part down into two groups? Committment of team to organization, and Team members to other team members. This is my dilemna with Team #1.
Team #5 I would Bullet this one before hanging it on the wall.
Team #9 Is “At standup” soon enough to replace “As soon as possible”?
Team #10. I need to learn more about this as I may be missing a critical cue, but the logic here isn’t making the connection for me.
Team #11. This one is too long and seems to try to cram a lesson on Priority vs. Value into a focus rule regarding the current and next item. Maybe I missed the point, but like #10, that’s why I’m noting it.
I was surprised not to see an entry in the Team section regarding Retrospectives.
For Team #9 “at standup” would not be sufficient. That would imply an impediment could exist for 23 hours and 45 minutes before getting exposed to anyone else. I like the “as soon as possible” wording. The Scrum Master isn’t only working during the daily stand-up!
For Team #10 it goes back to the way the team was taught. When a developer (or other) is unclear on how something should work, they can get a lot of clarity by asking “How will I know I’ve done that?” The resulting answer is acceptance criteria rather than diving into the details. I have a blog entry on it here.
Team #11 is about making sure no one assigns work (push system) but rather that everyone pulls work using the same rule. It is to encourage swarming on the highest priority items in order to get them to “done” as quickly as possible.
As for retrospectives, the team is doing all of the normal Scrum meetings, so they do retrospectives. I guess they didn’t think they had to call that out as a special case.
I hope the above explanations help.
“3. Use the rule of “yesterday’s weather” for iteration velocity and therefore will never commit to more work in an iteration than was completed in the prior iteration.”
and
“8. Strive to improve every iteration.”
doesn’t make sense to me in combination
Cheers
Stephan
http://twitter.com/codemonkeyism
Stephan, if the team finishes all of the work for an iteration early they are supposed to take more work from the backlog. In that case “yesterday’s weather” will be higher than it was before, and the team will have improved.
However, improvement can also involve other things. It can be easier to do certain types of testing, or planning meetings can be more efficient. Those are just two examples, but there are many, many more ways to “improve” that don’t necessarily reflect in the velocity of the team.
– Bob –
>>Use the rule of “yesterday’s weather” for iteration velocity and therefore will never commit >>to more work in an iteration than was completed in the prior iteration.
How do you test the limits of the team if you don’t add work to the Sprint?
Sandra, at the start of an iteration or sprint (during planning) a team will not commit to more work than they completed in the previous iteration. However, if they finish the work with time remaining in the iteration they can pull more work from the prioritized product backlog. In this way they can complete more work and in the next iteration their commitment will be based on a higher number.
Hi Bob, thanks for the article! The PDF gives a 404, much appreciated if you can put it back. Thanks in advance!
Julien, thanks for pointing that out. It is now fixed.
Hi Bob, I know it has been some time since you posted this, but in the event you can still receive comments about it, I wanted to say thank you- this was very helpful. I’m using your RoE in the context of creating a similar document for cross-team collaboration in a sales department. Very helpful!
This is really very very useful topic. Thank You for the pdf…