Long-term teams

It takes time and effort for a team to learn to work together. Agile teams improve dramatically over the first 6-9 months of working together. Not only teams become more productive, they also get better at estimating, and learn deliver at a steadier pace. Team members learn to communicate well, acquire the cross-functional skills needed to reduce bottlenecks, become good at brainstorming and conflict resolution, form mentoring and supportive relationships that help maintain a great team atmosphere. Within a year of working together, many teams are rolling through the project smoothly, at a steady pace, and enjoying their success.

Yet, it is somewhat rare for the team to stay together for longer than half a year to a year.  There is churn of projects, people come and go, successful teams get broken up to “seed” or improve other teams, that may not be doing particularly well. A great value of a well-gelled team seems to be unaccounted for, and regularly lost, without the organization even noticing.

Agile frameworks do not promote any meaningful way to value teams.  It is hard to talk about the value of a well-gelled, long-term team, and compare it to the value of adding a person or two to some other teams. But it is a conversation worth having.

Early bird misses the bug

For teams doing Agile, there is often a push to get ready for implementing a story early – long before the story is scheduled for implementation. The prep work is often way beyond getting the basic understanding of what the story is about, and sharing the vision for the result. It involves delving deep into the technical details and complexities, code minutiae, architectural and environmental setup.  By gathering that intelligence early, the team tries to minimize the risk of uncovering additional complexity of the story and missing estimates when this story is finally scheduled into the iteration.

The intentions are good – having more details early seems more prudent, being knowledgeable about the story beforehand gives the team more confidence in providing estimates, and PO feels that she is doing a good job communicating with the team about future stories.

However, there are problems with pre-preparing stories ahead of time.   

For one, the team is pushed to work on stories that are not in the current iteration.  This work has no definition of done, no acceptance criteria, and pulls the team away from working toward current iteration goal.

A bigger problem is that once all this work is done, the story is about as likely to go into an iteration soon, as not. The intelligence gathered may get written up or not, but even if it is, this knowledge is still very perishable. If the pre-worked story sits on the backlog even for a couple of iterations, much of that intelligence deteriorates beyond any usefulness.

The biggest problem with pre-work, though, is the pressure it creates. Pressure to create exact estimates, since all this work has been done on the story beforehand.  Pressure to not ask questions later on, when the story is actually being worked, since the onus is on the team to ask questions early.  Pressure to burn the midnight oil, if the story turned out to be more complicated than expected, despite all that time spent researching it before.    

One of the rules in eXtreme Programming is “Keep the system uncluttered with extra stuff you guess will be used later”.  This is also a good rule to plan work by.  Do not pre-work the stories, let the team ask the questions and use the answers immediately, as they are working the stories in the iteration. It is OK to take the risk that sometimes some stories will turn out to be more complex than others, and will need to be continued in the next iteration.  Overall productivity will be higher, because the team will spend less time on work that is not moving the team closer to the iteration goal.  Overall quality will be higher, because the team will have the latest information available, obtained at the last responsible moment, and will not have re-research outdated intelligence.