It doesn’t matter how many lines of code are written. The languages the user training documentation is translated into doesn’t tell a complete story. Employee turnover, stock prices, how clean the break room is when the overnight crew comes in. All of these pale in comparison to the importance of Working Software when trying to understand how successful an Agile software Development Team is.
Working Software
over
comprehensive documentation
Of the four value statements in the manifesto, this is the only one that deals with output. It doesn’t look at lines of code, number of features, velocity, or any other common metric for this. It looks at working software.
Many wonder what working software is in this context and why we value it. This is important, but I think it’s just as important to consider what comprehensive documentation is and why we value it less.
I’ve often run into battles over whether a team should use a particular process or tool, but I’ve never run into opposition over releasing working software. Sure, there’s been a little debate in my career over just how much QA should be done, and whether something is MVP or not, but the goal of every person in those conversations has always been to release working software. This shows us the debate on this second value is not so much in whether we want to release working software, but what exactly dictates whether it’s working or not.
Any developer could tell you that bug-free software is working. A business analyst might content that software that delivers the required functionality is working. An end-user is like to give the working crown to the software that fills their need or solves their problem. These three ideas are all good indicators of working software, but they also make working software feel a little more complex and difficult to define.
I believe that the consultants actually win this one and the definition of working software depends. This isn’t as cryptic as it sounds though. Each team should have something similar to a definition of done which they’ve negotiated within the team and with their stakeholders. They’ll also have some version of a product backlog to work from, one that is defined and ordered in close partnership between themselves, the business units, and the end user. If these teams take something from that backlog and run it through to their definition of done then they have created working software by any measure. The definition of done dictates the state of bugs and other errors, the backlog definitions and priority dictate functionality and ability to solve problems.
This isn’t all there is here though, in all of this comprehensive documentation was never discussed. This can be a touchy subject for development teams, especially ones without access to a dedicated tech writer. Some people like to interpret the manifesto such that all documentation is second fiddle to working software. I’m not sure that’s the intent.
I see “comprehensive” as a key word in this phrase. I believe it is both a concession that some documentation is required and a slam on the level of documentation some business units and project managers have asked for in the past. If agile thinking was really about no documentation as some naysayers have posited then the word comprehensive would not be there. One of the most basic rules of writing things for wide distribution is to use the fewest and simplest words possible. Even if we assume they needed word pairs then there are many that would have made more sense there if all documentation was secondary.
In a perfect world, the proper level of documentation is mixed into that definition of done that was agreed upon. Chances are it isn’t, so an agreement on what level of documentation is required should be made separately.
If you’d like to know how I can help your organization define what working software is please contact me here for a free initial consult.
More
It doesn’t matter how many lines of code are written. The languages the user training documentation is translated into doesn’t tell a complete story. Employee turnover, stock prices, how clean the break room is when the overnight crew comes in. All of these pale in comparison to the importance of Working Software when trying to understand how successful an Agile software Development Team is.
