-
0
0
By Aaron
On February 11-13, 2001, at The Lodge at Snowbird ski resort, overlooking the Wasatch mountains of Utah, seventeen independent thinkers, self-described as “The Agile Alliance,” met to talk, ski, relax, and try to find common ground.
Representatives included those with backgrounds in #ExtremeProgramming, #Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation heavy software development processes.
What emerged was the Agile ‘Software Development’ Manifesto, a set of values and the “12 principles of Agile Software”.
This is the 7thin the series of articles discussing these principles in detail and examining their validity in today’s world. The intent of this article is to simply provide some guidance into how to apply Principle #7 with the best intentions.
Principle #7: Working software is the primary measure of progress.
Principle 7 is somewhat of a straightforward principle in that it encourages us to measure success and progress through the delivery of a working product to our customers. It indirectly challenges some traditional measurements of success and discourages vanity metrics. It implies that while we may measure progress in many ways, the primary and most important measurement is a demonstrable product that functions as designed and built.
Defining True Progress
Agile product development is not about how much we can “get done”, the amount of effort we put into our tasks, or how many points we were able to accomplish. Instead, agility should be measured through the delivery of working solutions to our customers, free of defects and bugs, while remaining flexible within changing priorities and requirements. If the valuable thing we are delivering works as designed and requested, we have progressed. If the products we build are not deliverable, not demonstrable, nor valuable to our customers, true progress is lacking.
When it comes to working products, our initial success should be determined when we demonstrate the product to our stakeholders and gain the invaluable feedback they provide as to its application and functionality in addressing whatever problem they have asked us to solve. When the product works, and resolves said problems, one can expect positive feedback and demonstrable progress. Even when we deliver only a small valuable fragment of it, and/or the feedback may encourage rethinking the solution, we can still consider that progress, as we now know more what the customers desires and can build a better product based on that.
Traditional and Managerial Measurement
In the event the product is unvalidated development (a common phase gate) the feedback from your stakeholders will be limited, as they cannot accurately evaluate its effectiveness. There could be significant deviation between their understanding of the product and how it looks or functions post validation. We need to be careful when assuming progress using phase gate performance measures.
When we measure an Agile team, or team of agile teams’ progress, management often measures story points and effort among other things. These both have their applications and may provide invaluable data to the organization (trend lines on both measurements can tell a very particular story, and point averages assist in agile contracting). However, Accounting for Defects in an Agile Environment has its own challenges and the aforementioned measurements of progress need to account for such things. For a team or individual completing more “effort” or “points” may simply be accounting in a duplicative manner for their own rework (defects/bugs).
Predictability Measurements Support Principle #7
Agile organizations should use predictability, measured by value delivery versus value planned. It is measured through stakeholder collaboration, demonstration, and evaluation of working products – preferably in some form of staging environment that emulates current systems. If the product works as designed, value is determined by the stakeholders and the team is successful and predictable. If it doesn’t work, or the teams under-deliver, their predictability suffers as the value delivered is lessened.
It is important for every organization to consider predictability a serious metric. When practicing #SAFe or any other form of #ScaledAgile, business owners identify expected business value during planning and then provide a comparative actual value post demonstration. In the event teams do not demo a working product but rather only a partial or buggy solution, the business value must reflect this. If it does not, the measurement loses its benefit. When practicing agile (scaled or otherwise) it is extremely important that predictability is measured based on those working products delivered that were committed to during planning. When products do not work appropriately or completely as planned, or are defect ridden, we should not accept those stories and features as complete. If measured by story points, these points should not be accepted and accounted for. This encourages teams to build quality into their production efforts and discourages overcommitting.
Summary
So, the intent behind this principle is to encourage teams to build quality into their products and always strive for greatest value delivery. It intends to discourage teams and organizations from measuring progress based on vanity metrics that may not be tied to any kind of real value delivery, as busy does not necessarily equate to progressive or productive.
It is more important for organizations to deliver working products that excite our customers than it is to show a great deal of effort on something that doesn’t work. Teams that practice principle #7 and build high quality functioning products are the teams that are most successful, the teams that other teams want to emulate, and the teams that make organizations great. In short, when we focus on building quality working systems, our teams, organization, and customers progress in ways traditional approaches fail.
