BE AGILE!
Everyone Tells Me We’re Agile… So Why Don’t I Feel Agile?
Introduction
As an Agile Training Provider, I meet with executives in a variety of industries. A topic that often arises is the difficulty of measuring agile success. How can a company know that its agile journey is realising meaningful and measurable benefits?
Over the past twenty-plus years, many organizations have employed agile development while others have modernized product planning. A common uneasiness amongst business users (such as product owners) and senior management is: “Everyone tells me we’ve gone agile… so why don’t I feel agile?” In other words, there is no clear connection between adoption of agile principles and the achievement of goals and economic outcomes desired by the organization.
Conclusion: sometimes even agile companies don’t feel agile.
In this blog, I will share some observations that we, at ACRA Training, have made over the years. I’ll provide guidelines for evaluating your overall business agility to help you ‘feel’ more agile. Of course, not all approaches are for all organizations so pick the ones that have the most benefit to you.
When you’ve incorporated measurements, you’ll know how your agile program is performing! And whether it’s perfect, or there’s room for continuous improvement, you will certainly know more, and feel more, agile!
Creating Business Measurements to Feel More Agile
Any search on the web will find many measurements for agile practices in an organization. (I checked as I wrote this – about 4.1 million hits!)
As attributed to Peter Drucker, “You can’t improve what you don’t measure.” So, let’s talk about practical measurement of agile for senior management and executives. We are not proposing dozens of complicated metrics just to feel better. We simply want to identify some Key Performance Indicators (KPIs) to assess if we are getting value for our investment in agile.
To accomplish this, each organization should have a lean set of KPIs which a) are not overly complex to prepare on a regular basis, b) can be applied across multiple teams and products, and c) are understood by the organization to aid in the continuous improvement of business practices and agile methods.
An example of a) above is that it should not require significant resource or cycle time to collect data and produce metrics. Data collection should be a part of the agile process itself and not gathered by after-the-fact status reporting.
An example of b) is that for governance processes, all products and teams must share common measurements. This helps management determine where upskilling or upstaffing is required. This supports long-term Demand and Capacity Planning by considering the capabilities of different teams and their anticipated workloads in relation to the strategic plans and business objectives.
An example of c) would be a cost/benefit statement. Although there is often temptation to find false accuracy by measuring to the dollar, the real goal is to determine whether the recovery of an investment is real and the rate at which it is occurring.
In this light, we recommend that each organization develop a set of meaningful business metrics for agile. Let me emphasize the word ‘business’ in that previous sentence. While it is important to measure lines of code or burndown rates, these measurements may not have deep meaning to the business units which want to benefit from the agile process. Certainly, these are excellent measurements for agile teams which strive to fine tune their agile implementation. But business agility must be measured with business metrics.
Business Metrics for Business Agility
From a business perspective, we tend to view agile measurement in three major areas. Each will be explored in depth in future blogs.
- Product Definition (Business Value)
- Product Needs and Strategic Alignment
Is there a product roadmap that aligns with stated short- and long-term business goals? Does the roadmap reflect organizational capacities, and can achievement of interim targets be predicted within a reasonable tolerance? - Time to Value and/or Investment Recovery
Is there a reliable estimating mechanism which predicts the investment required and the anticipated benefits once delivered? Does financial commitment occur within a Stage Gating process? Are there standardized tolerances which differentiate between good, fair, and poor investments and are they measured on an ongoing basis? - Time to Delivery
Once a project (a collection of features/epics aligned to a value stream) is underway, can the business rely on the forecasted implementation date?
- Product Needs and Strategic Alignment
- Product Development (On-time Delivery)
- Sprint Efficiency
Sprint efficiency can be measured in a myriad of ways – the most important thing to consider is: will your measurement make sense to persons not directly involved in agile day-to-day development? We agree that agile teams must self-measure to identify process improvements in each iteration. However, using terms such as velocity, story points, burndown rates, web-side process efficiency, interrupt buffers, etc. will not endear you to business users or senior management. We suggest a two-tiered measurement system – one for use by the team itself, and one for reporting and interacting with product owners and executive management. - Escaped Defects
Since the goal is minimal or no defects released into the production environment; how are escaped defects identified, corrected, tracked, and reported? Considering severity, is there such a thing as ‘an acceptable number’ of escaped defects? Where in the agile process should these defects be eliminated and/or detected for correction before release?
- Sprint Efficiency
- Product Deployment (User Satisfaction)
- Frequency
Does the organization’s agile process meet the target frequency for product releases? What are the measurements for on-time, late, and delayed? What are the criteria for a target date reset? Business units love predictability when it comes to product deployment. Often marketing materials and campaigns are tied to releases, features, or functions. Predictable product deployment equals a satisfied business user (and therefore the senior management that govern them, as well.) - Stability
An ideal release is one that a) provides the desired capability or functionality and b) does not disrupt or negatively impact clients and customers. What metrics are in place to determine whether a stability metric is met? A stable production environment plus target capabilities equals a satisfied business user. - Acceptance
User Satisfaction is a complicated and often subjective measurement. The organization should have an acceptance review cycle which looks at releases at a) deployment, b) deployment + x days (short term) and c) deployment + y days (long term). Over time, this can be an excellent indicator as to how well the agile process is meeting business needs.
- Frequency
Summary
Each organization should identify and codify key metrics which serve the business unit community and executive management.
- Metrics should be real.
- Metrics should be understandable by product owners and executive management.
- Metrics should be transparent and publicly reported on a routine basis.
- Metrics should be codified but not in stone. They need to be lean, limber, and evolve as the organization’s use of agile evolves.
In the final analysis, product owners and executives that understand key performance indicators for agile are far more likely to be feel agile. To make this happen, you must define usable metrics for the intended audience.
What’s Coming Next?
In our next blog, we’ll discuss Business Agility and Agile Maturity. We’ll have heart-to-heart about the key elements of a self-assessment and how to put together an action plan that will not stress you, the agile teams, or the organization.
That’s coming in our next blog.
Come with us on this journey as we explore how to determine where you’re at and where you want to go to. Many organizations want to be more agile… we’ll help you get there!
And then, you’ll feel more agile!
Subscribe!
If you’d like to receive our future articles via e-mail rather than waiting for the blog, please provide your contact information and we’ll be glad to send it to you. We won’t sell your information, we won’t overload your in-box, and we promise NOT to spam you.
Many thanks and see you soon!
For More Information
Contact Anna Mastropietro at ACRA Training.
amastropietro@acratraining.com
© 2022 ACRA Training and Consulting, Ltd.