Agile Values and Principles in Software Systems: 4 Metrics
An organization that is on a journey to become Agile needs to identify necessary metrics based on Agile values and principles that will take the organization to the expected level of organizational agility. Introspection into what is working, what is not working, and what needs to be improved in the organization provides a good start for the Agile journey.
In this Advisor, we discuss four such metrics, how they are linked to the principles behind the Agile Manifesto, and how they will benefit the organization.
Metric 1: Value Delivered to Business in a Timebox
According to the Agile Manifesto, the first principle is to “satisfy the customer through early and continuous delivery of valuable software.”
Measuring the business value achieved from the delivered software system and the frequency of delivery is important for the organization to be competitive and adapt to changing market conditions. The business value of the delivered software as assessed by the business teams on an occasional basis (e.g., number of new customers added, reduction in time to market for features, reduction in delivery time for customer service, improved workflow for system users, quality improvement, delivery throughput, velocity, delivery frequency, and so on) helps to establish and track this metric based on the organizational context.
Metric 2: Impediment Impacts
To deliver working software at a desired frequency, organizations need to look at the impediments to delivery and address those impediments in a time-bound manner. Generally, additional effort is required to manage impediments in a project, taking time from the schedule. To ensure there is an adequate focus on addressing impediments, it is essential to track the additional effort required to address them or to project time lost due to any delay they cause.
Grouping the impediments as logical clusters (e.g., IT infrastructure issues, technical training, resource requirement, and so on) will give more insight into which impediments and in what priority they need to be addressed to minimize impact to delivery and to mitigate risks, which impediments can be addressed at the organization level to improve the success rate and effectiveness of resolution, which impediments will provide long-term strategic benefits, and so on.
The Agile Manifesto emphasizes “Build[ing] projects around motivated individuals. Giv[ing] them the environment and support they need, and trust[ing] them to get the job done.” The leadership team’s time-bound support for addressing impediments has a positive impact on the team environment. Using impediment boards along with task boards for visual displays, time-bound notification of impediments to owners and stakeholders, and addressing those impediments in a time-bound manner have been found to be beneficial in Agile transformation journeys.
Metric 3: Retrospective Impact
As the principles describe, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Teams should look for opportunities to quantify the benefits of the incremental changes implemented based on the retrospective outcomes.
This metric motivates teams to actively contribute to retrospective action items that are providing visible benefits to the team, product or project, and organization. A team environment that provides space for inspection and adaptation in a subtle and collaborative environment nurtures motivated individuals.
For example, assume a team decides to use test-driven development (TDD) for a project. A goal and a measurement model should be attached to this new practice so that the team can track its progress for the new practice and measure how TDD is helping to achieve the associated goal.
Another example is a team, having identified the need to improve test coverage, decides to build test cases in parallel to low-level design. At the end of two or three sprints, the team could reflect back on whether it helped to prevent defects so that there is continuous momentum to keep the practices that are useful.
Metric 4: Adaptability to Changing Requirements
Another principle advocates “Welcom[ing] changing requirements, even late in development…. Continuous attention to technical excellence and good design…. Simplicity [and]…. The best architectures, requirements, and designs emerge from self-organizing teams.”
Change adaptability, system architecture, and flexible system design are interlinked. Adaptability and scalability in the architecture and design enables an IT system to accept and absorb changing requirements quicker and with less impact. The system should have the capabilities to make changes, validate, and deploy in a shorter time period with minimum effort and impact. Business scenarios get disrupted and changed rapidly. It demands organizations to be responsive, and it is imperative that IT systems should enable business to be Agile.
Adaptability to changing requirements can be measured on an index-based scale of the following (among others):
- The capability of the delivery organization to change the priority of requirements as per business need at timebox intervals.
- How effective and flexible the business and IT team are in using requirement prioritization techniques to get better business results.
- The turnaround time in incorporating the outcome/feedback from customer demos to the software systems.
- How simplified and granular software system development approaches are adopted.
Self-organizing teams will develop inherent motivation and team balance to be in enquiry mode to elicit better requirements, debate and understand the customer’s business environment, and develop systems that are flexible and adaptable to changes.
Agility is about being adaptable to changing environment conditions, delivering or acting swiftly to fulfill customer needs, and in turn becoming a successful and sought-after organization. Being connected to the fundamentals of agility and tracking the transformation progress based on these Agile principles helps organizations to be on track toward transformation progress and stay connected to the big picture.
More: Articles Like This
- SLA for Agile Systems: Can Adaptability Be Procured?
- Enterprise Systems: Modeling Culture and Politics
- Managing Your Software Journey: Using Earned Value and Other Metrics
- The Pedagogy Principle: Teaching Agile Leaders How to Teach
- A Systems View of Agile Methodology Adoption: Part II-- Guiding Principles