Agile teams are supposed to be self-managing, but I have yet to see a team that didn’t have a cadre of managers helping them along. Now, that’s not necessarily a bad thing. There certainly are times when a politically-savvy project manager can ease the path to production for a team, or when a development manager can spend the extra time needed to argue the case for a virtual build box or a coffee maker.
But, the team needs to know how to manage itself as well. How do tasks get doled out? What happens when a team member is consistently late to stand-up? How do architectural decisions get made?
Agile teams can take a page from the Boy Scouts – be prepared. Take a little time to explore some “what ifs” and create an agreements document – essentially a working document identifying what to do in specific situations.
An agreements document is an excellent tool for two reasons:
· Team-building – the best kind of team-building doesn’t happen on a paint-ball range. It happens in the office, where you actually can start to see the results of your work as you… well, work. Creating agreements on tardiness, the presence of phones in meetings, etc. can help the team recognize the behaviors that are each person’s “nails on the blackboard.”
· Less need to think during a crisis – if process are identified and documented on what to do when production servers die or when an architectural discussion turns nasty, the need to remember isn’t left to our flaky brains, and the tendency to revert to old ways won’t happen. To paraphrase Einstein, “The application will not evolve past its current state of crisis by using the same thinking that created the situation.”
While there will remain time where the team needs to actively respond to a situation (underestimation of the sprint’s tasks, architectural disagreements, a dev environment dying right before a release), the creation of team agreements will help the group be ready for many issues they face on a day-to-day basis.