We Love Definition of UnDone - And You Should, Too

So, your new team has gone through Agile training, established a team working agreement, and have all agreed to a definition of done. Ah yes, the Definition of Done...where the team agrees to what a body of work looks like when they are done. The teams acknowledge the value of what done looks like, which tends to eliminate “scope creep” and adds a team accepted and achievable goal for each body of work.

The team understands this value and truly likes the concept of this focus and self-identified objectives that add to the finality of work. Smiles all around...but wait!!...Is there more to this exercise? Is there something else we can do to identify improvement to value delivery for this team?

Did someone say feature team?

Typically, teams from a more traditional development environment are very isolated and highly specialized around a single component of a feature or even bigger component. This narrow focus around a very small subset of business value lends itself to high specialization, that on the surface may seem like a great method of efficiency. However, it is this very idea that causes the most inefficiency in teams. This inefficiency is generally hallmarked by delay to market and poor quality, and strains the networking paths within an organization. The concept of feature teams to replace the traditional component has become very popular to solve the bad stuff that results from component teams. Transitioning from a component team to a feature team can be somewhat of an arduous task, but this is where identifying and stating a Definition of Undone can help.

Asking the team to think and discuss what work tasks need to be done to deliver value from concept to production release may yield some varied responses. Many responses will be: “Our team doesn’t do that” or “We only do this part”. Add these to the “Undone” list. Some areas of undone work could include integration testing, back end database work, UI work, etc.

The goal is to have a team that can produce value from end to end. This can be best described from borrowing the “Single Piece Flow” concept from the lean principles where an isolated piece of value can be efficiently produced unencumbered by wait state.

The bad stuff it reveals…

Transitioning to a feature team concept can highlight many of the team’s working dysfunctions. Some of the more prevalent include: issues with cross-functionality, trust across the organizational landscape, and inter-team knowledge deficits.

Looking ahead…

As a team moves forward, one objective of the team’s retrospective could include a discussion on how to move items listed under Definition of Undone to Definition of Done. Solutions for this could include knowledge transfer, reassigning team members, and mentoring. There are, however, some items that could probably never be moved over, such as security auditing or language translation. The goal is to move as much undone work to done over time.

In Agile, there has been a lot of emphasis on discussing and identifying a Definition of Done and the other half of the equation where goals can be set for teams to transition into feature teams. Listing a Definition of Undone is the perfect starting point for a team’s journey to be even more highly functional and produce value with efficiency, clarity, and quality.