Two of the most dangerous terms in Agile; Done and Whole Team
I have come to realize in the last two weeks that there are two words in the Agile lexicon that really bug me. Not because they are bad per se, but that they are so commonly misused and abused. Not to mention being insanely context sensitive.
I’m doing what might be considered an agility assessment for a company and am entering the report generation phase after a number days of observation and data gathering. There is nothing too ‘OMG! MY PANTS ARE ON FIRE!!!’ but one thing that sticks out is their working definition of ‘Done’.
I don’t think anyone who has played the role of Agile coach or consultant has not written a blog or paper at some point on ‘Done vs Done Done vs Done Done Done’.
This company has four different teams which are pretty autonomous and effective and one of the things each have done is define their own understanding of Done. While this seems like a good idea on the surface it is really quite dangerous. With each team having their own definition of Done there can be no common understanding when something is Done and that information rolled up with other non-contextual information to management.
Having the development teams generate the definition of Done also means it is limited to their scope of influence, care and interaction. The net result is a very naive scope of Done. Stories that are ‘done’ frequently will go out into production without adequate analytics hooks or means of monitoring the health of the component being created.
This nicely dovetails to the other most dangerous term; The Whole Team. I was at an automation workshop this past weekend and the people there spent almost 45 minutes talking around this subject. In retrospect no one asked what everyone meant by ‘the whole team’. This is another area I suspect Agile teams need to work better on. I would bet that most people’s working definition of the whole team includes the developers, the testers and someone in some sort of product ownership role (either directly or in proxy). But what about the analytics team, or the sales folks who use the output from the analytics team? Or the Ops team, including the DBAs that need to push the code out onto the iron? How about the customer support people who deal with the brunt of the code team’s mistakes?
The list is not endless, but it is large. One thing I like from the Lean Startup [Cult | Movement] is the the story isn’t done until it in production getting validated by real users. The user is on the team whether they realize it or not. We’ll just gloss over the lack of humans in the release process… |
I think there is actually some sort of circular feedback loop at play between Done and Whole Team and you cannot address just one in isolation. Instead, really figure out who your team’s stakeholders are and what skin they have in the game. Only then do you have a chance, and only a chance, of coming up with an appropriate, inclusive, accurate definition of Done.