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.
