Just because it is done, doesn’t mean it adds value.

In recent exchange after the 16th installment of the re-read Saturday of the Mythical Man-Month, Anteneh Berhane called me to ask one of the hardest questions I had ever been asked:

Why doesn’t the definition of done include value?

At its core, the question was asks how can we consider work “done”, if there is no business value delivered, even if the definition of done is satisfied including demonstrably meeting acceptance criteria. Is software are really done if the business need has changed so what was delivered is technically correct, but misses the mark based on the business environment today? This is a scenario I was all too familiar with during the 1980s and 1990s at the height of large waterfall projects but see less in today’s Agile development environment.  Anteneh Berhane’s question reminds us that the problem is still possible.  We discussed five potential problems that disrupt the linkage between done and value.  Here are the first two, and today we will discuss the second three.

Scaled efforts without plans for communication and coordination can result in lots of work that doesn’t meet needs. Scaled Agile is a group of teams working together toward a common goal.  These teams need to coordinate in order to achieve a specific goal. Coordination requires the adoption of techniques that help make coordination possible.  For example, the release train engineer and release train planning event are tools used by the Scaled Agile Framework Enterprise (SAFe) to ensure that what gets built is what is needed for the business across all of the teams.  Without communication, planning and feedback tools and techniques to ensure coordination, it is possible to a team or a group teams build the wrong thing while meeting all the criteria for being done. When more than one team is working in a coordinated fashion, someone must spend time and effort coordinating activities and work between all of the related teams.

A poorly defined value proposition is a BIG problem. One of the premises of Agile software development is that a team will deliver value on a regular cadence.  If the product owner or product management team has not spent the time needed to evaluate the features in the project backlog to determine which have the most value (or if specific requirements have any value at all) the software that gets delivered may be done, may meet acceptance criteria, but may not measure up on the value side of the equation. The simple fix for the product owner or product management group is to evaluate and rank features based on the business value they deliver. (Note: epics and stories can also be evaluated for value.)

Lack of product owner involvement is problematic for all Agile projects.  Pedro Serrador in an interview on SPAMCAST 368 stated that the level of product owner involvement was an indicator of success with Agile. Product owner involvement provides both the vision and the feedback needed to ensure the team is building the right software.  Projects without product owner involvement should not be done using Agile, and perhaps should not be done at all.

The definition of done often infers that the software being delivered has value. Unfortunately, that is not always true.  Evaluating and focusing on value is just as important and meeting the definition of done and whether the software has been evaluated to determine if it  meets the acceptance criteria.