This theme of complete products, complete teams, and knowing what “done” means to the team keeps popping up here and there, and I’m starting to realize it’s all intertwined. In order to deliver a complete product, you need a complete team. In order to have a complete team, you need a common goal. You must know what your definition of “done” is for your product. It will be different for every team and it needs to be defined up front. Without this common goal, a team member will be more likely to say “I’m done with my part” because her individual definition of “done” is different than the team’s. With the common definition of “done”, it’s the project team’s responsibility to get to “done”, not just one individual’s.
This concept of “team” was also a common theme in a recent conference I attended. I often find that we think of team as “me and the other developers on the project”. Unfortunately, that is only one small part of the team. A project or story is not complete when I’ve finished coding it up. The team is the full delivery team – everyone that plays a part in the project from concept to delivery. Being agile requires us to breakdown the barriers between teams and dissolve the traditional “my title says X, so I can only do X” type of roles.
Johanna Rothman does an excellent job of explaining this and defining “done” in her post on Transitioning to Agile Testing. The most important message I pulled from this is that transitioning to agile, whether it be development or testing or whatever, is a team activity. A complete team activity.