Let the Ultimate Metric Build your Team

At a recent Agile KC meeting in Kansas City, Missouri we met to discuss, among other things, topics that might interest software developers and managers alike for upcoming meetings. One of the topics that always comes up when such a list is discussed is testing. It's interesting to see how software developers increasingly are discussing ways to test software. Everyone (QA, developers, managers, customers, etc.) wants to know what "done" means.

I know we have seen increased interest from our consulting clients in Kansas City where we coach software developers on agile software development techniques and teams and managers on agile project management. Software developers are interested in defining "done" (just as other stakeholders in the project)through the use of not only unit tests, where they're able to demonstrate the integrity of the code at the unit level, but also in terms of acceptance testing or functional testing where the focus is on defining "done" in the customer's eyes.

Acceptance tests sometimes known as "conditions of satisfaction" define the requirements for software features which are most often comprised of one or more user stories. They are defined from the perspective of the customer for a given business need, exactly where the emphasis should be in the first place. So the combined set of tests ideally maintained and run in an automated fashion to help speed up development, make up the overall requirements for the system.

Having the requirements defined in advance of each iteration planning session is a highly effective way to keep the team pointed in the right direction and create a focus for software development efforts.  The idea is that at the end of the each iteration, working software is available to potentially ship because it works or is "done" in that it has passed the tests defined at the beginning of the current iteration and all tests defined in previous iterations.

Knowing what targets to shoot for each iteration lets the team focus on what needs to be done, eliminates gaming other metrics in use and helps a team identify what adjustments they need to make to reach the goal of delivering running tested software every iteration in a just-in-time manner.

This emphasis not only ensures the software output matches the requirements but it results in leaner, more concise and targeted code that's developed with those conditions of satisfaction in mind. There's less of a tendency to get off track and build features that weren't requested resulting in overall lower maintenance costs and an overall better team in that they develop a shared understanding of the business domain and the software that supports it. It also helps with schedule and cost predictability in that untested code represents an undefined amount of work (potential bugs) that, if left to deal with toward the end of a project, can create wack-a-mole development that often accompanies the classic "stabilization" phase.

We have found that this "ultimate" metric is the best target to hang out at the end of every iteration. Even if it takes a number of iterations to establish the necessary rhythm to achieve the frequent and consistent delivery of running tested software, it's a goal worth tracking and building a team process around.