Agile Lagging to Leading Metric Path

Even in an Agile environment there is a benefit to applying measures to understand progress.  It can be tempting to apply the same iron triangle input metrics (based on cost, schedule, and scope) that may have been used in a more traditional mindset to Agile projects and initiatives.  Those, however, tend to be output related. Instead, I suggest removing all of those metrics and start with a clean slate. On the clean slate, first consider your outcomes.

An Agile mindset asks that you consider an outcome instead of output as a measure of success.  This means you should first start with understanding your desired outcomes for an initiative or project.  Within a business context of building products, one measure of success is an increase in revenue. Having a customer revenue metric helps you understand whether the products being built are increasing revenue upon release. While capturing revenue is a good starting point, it is a “lagging” indicator meaning you don’t recognize the evidence of revenue movement until after the release is in production and has been in the marketplace for a period of time.

To supplement a lagging measure, it is beneficial to have corresponding leading measures or indicators that provide you with visibility during creation to gauge if you are moving the product into a position of increased revenue. I call this framework the Lagging to Leading Metric Path.  This visibility is important because it provides input for making decisions as you move forward. Making the right decision leads to improved results. As you consider measures (or indicators), think about how they help you gain visibility and information for decisions in building a product that helps you lead toward an increase in revenue.

For a hopeful increase in customer revenue, what leading metrics can we put in place to ensure we are moving in the right direction?  Let’s say in this case that increased revenue is the hopeful lagging metric based on expected customer sales.  Examples of leading measures or indicators to achieve an outcome of this lagging metric for increased customer revenue include:

• Customers attending Sprint Review: a leading metric where you capture how many customers are actually attending the sprint review and how much feedback they give. This indicates engagement and interest. 
• Customer satisfaction from Sprint Review: a leading metric is capturing customer satisfaction from the functionality they viewed within the sprint review.  This indicates levels of satisfaction with the functionality as the product is being built. 
• Customer satisfaction of product usage: an indicator of the most recent release highlighting a level of satisfaction on the usage of the current product including commentary.   

When applying Agile to product development, the outcome that matters most are often represented by lagging metrics.  Therefore you will need leading indicators to ensure you are moving in the right direction, to provide visibility, and to help you with decision-making.   Within your own context, consider constructing a lagging to leading metric path so that you know you are moving in the right direction during your Agile journey.

                    ------------------------------------------------------------------------
Note: the lagging to leading metric path really isn't specific to Agile and I would suggest applying this to an initiative or project aligning with any mindset, process, method, or practice of delivering value.

To read more about establishing an Agile Lagging to Leading Metric Path and Agile Measures of Success, consider reading Chapter 14 of Being Agile. 

Is it finally time to “Be Agile”?

As I look across the Agile landscape, I am worried that Agile has become little more than a superficial tag that some teams and companies seek without really aligning with the cultural shift that is needed to truly become Agile.  What I mean by this is to really align with Agile, it means to understand and embrace the Agile Values and Principles.  While this sounds obvious, I believe there is such little focus on the values and principles and much more so on the mechanics. 

I have hypothesized that those involved in Agile are more knowledgeable about the mechanics of “doing Agile” than understanding the cultural aspects needed for “being Agile”.  My specify hypothesis stated that I believe fewer people could name 3 of the 12.

As I look across the Agile landscape, I am worried that Agile has become little more than a superficial tag that some teams and organizations seek without aligning with the real cultural shift that is needed to truly become Agile.  What I mean by this is to really align with Agile, it means to understand and embrace the Agile Values and Principles.  While this sounds obvious, I believe there is such little focus on the values and principles and much more so on the mechanics. 

I have hypothesized that those involved in Agile are more knowledgeable about the mechanics of “doing Agile” than understanding the cultural aspects needed for “being Agile”.  My specify hypothesis stated that I believe fewer people could name 3 of the 12 Agile Principles, then could roughly name 3 of the 5 Scrum events (i.e., Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective).  In order to make my hypothesis meaningful, it was important to test it. 

With that in mind, I established an experiment that tests if people can articulate the Agile principles and if they can articulate the Scrum events.   I created a simple survey that asked Agile participants to write down as many of the five Scrum events that they knew and then write down as many of the twelve Agile Principles they knew.  I distributed this survey to two different Agile professional events and accumulated over 100 survey responses (109 to be exact).  The results were quite revealing and support my hypothesis.  Of the 109 Agile participants: 

• 59% knew 3 or more of the five Scrum events
• 11% knew 3 or more of the twelve Agile principles

I actually find these results quite astounding.  Could it really be true that only 11% of Agile professionals and enthusiasts could name just 3 Agile principles?  I don't mean they they memorize them but can provide at least the key words of the principle.  This means that 89% could only name 2 or less.  What makes this even more astonishing is that 67% could not name even a single Agile principle (and I did give credit to those who could name the key words of the principle - e.g., self-organizing,  frequent delivery, etc.). 

In reviewing the survey results, about half of the 67% confused the Agile principles with the Agile Values (e.g., Individuals and interactions over processes and tools).  On the flip side, 59% could name at least 3 of the mechanical Scrum events.  Here are two charts that illustrate the number of respondents that could name a certain number of Scrum events and Agile principles. 

Based on this data, my concluding hypothesis is that the reason there is such a lack of awareness of Agile principles is that there is very little education focused on the Agile principles.  This is particularly concerning since the principles form the basis for what an Agile culture should look like. A simple way for each and every one of us to test this hypothesis is to ask these two questions:

• How many Agile principles can you name?  Is it 3 or more?
• How much Agile related education have you have received and how much of it was focused on the Agile principles? 

Now do keep in mind, knowing the principles is just the first step and it doesn't make you Agile. Next its time to live it.  But how do we expect to “be Agile” if our focus is so much more focused on the mechanics or “doing Agile”.   I would suggest that anyone who claims to be an Agile enthusiast ought to periodically bring their work back to the Agile values and principles.  Maybe its time to revisit the values and principles and understand what it really takes to be Agile.

Calculating your Team’s Target Velocity

In an Agile world, using empirical data helps a team understand their pace (e.g., in regards to the Agile Principle of sustainable pace).  Sustainable pace is a concept that attempts to identify the reasonable amount of work a team member can complete while still being able to sustain that pace indefinitely while remaining engaged, innovative, and enthusiastic.  A key question is, how does a team know the amount of work they can do?

One way to do this is to capture a team's actual velocity.  A team's velocity is the amount of work a team can do in an iteration or sprint that meets a quality criteria such as Done Criteria.  The work is usually captured in several requirements or user stories each with an estimate or size in story points. The total story points of user stories completed in a sprint is an example of a team's velocity.  I'm using story points in this article as the example.  A story point is a scope measure which is equivalent to a unit of effort, complexity, and risk associated with the work.  The question is, how does a team determine their pace or target velocity (depending on the word you want to use) for the next sprint. 

There are several ways to approach this and using the empirical data from the previous sprint’s actual velocity is a good start.  It is up to you to determine what works best for your team and context:

• The simplest way to calculate the team’s target velocity (TTV) is take the previous sprint’s actual velocity and use this as the team’s target velocity.  An example if in the previous sprint, the team's actual velocity (TAV) is 120 story points, then for the next sprint, the TTV will be 120 story points.   
• Another simple way to calculate the team’s target velocity is take the average of the previous sprint’s actual velocity.  As an example, if the previous sprints’ TAVs were 80, 90, 110, 100, and 120 story points, then divide this by 5 and the TTV will be 100 story points. 
• A more complicated way is take the previous sprint’s actual velocity, plus credit points for completed effort of unfinished work, minus points that team members will be away on holiday, vacation, training (aka, out of office).  As an example, if the previous sprint’s TAV is 120 story points, then take credit for completed effort of unfinished work as 9 (3 points for 3 unfinished user stories), minus 10% of the previous sprint’s TAV due to the Thanksgiving holiday or 12 points, bringing the total to 117 story points (=120+9-12). 

As an aside, when your team is first starting out, you will not have any empirical data or previous actual velocity to work with.  In other words, you will have to guess your team's target velocity.  However, the good news is that because the sprint is often only 2, 3, or 4 weeks long, your team will not have to wait long to learn the team's actual velocity.  This can then be used as empirical data to help you calculate your team's next sprint's target velocity.  

In whatever way you decide to calculate the team's target velocity, ensure that the previous sprints’ actual target velocity is applied in some manner to bring as much empirical data into the calculation.  Also, attempt to apply a consistent calculation from sprint to sprint.  From there, inspect and adapt as appropriate.       

Size Matters – using “size” instead of “estimate” on Agile projects

When I help teams implement Agile methods, I find that some folks have a hard time getting their head around “estimating” user stories (aka, requirements) using story points. When I get to the discussion of Sprint Planning where we are scrubbing stories (aka, requirements) as a team, I used to say it is now time to “estimate user stories”. I would emphasize the importance of having the whole team estimate the story together. I also tend to apply the planning poker technique where each team member has a physical or virtual set of cards with the Fibonacci sequence (aka, law of distribution) of numbers on them (e.g., 1, 2, 3, 5, 8, 13, 21, 34, 55, etc.). When it is time to estimate the user story, each team member selects a card from their deck relating to the story points they think reflects their estimate of the work which should include their notion of complexity and risk for that story.

When I educate folks on estimating user stories, some folks ask me to align the story point with days or hours. That’s when it occurred to me… I realized that when I use the word “estimate” it would make some (many?) folks think of the traditional estimation that uses “schedule” as a measure (e.g., hours, days, weeks, months, years). However, in Agile the intent is to size the amount of work based on the functionality you are building for that story. So in effect in Agile, “scope” is the measure of progress. This is when I realized that folks were often trying to apply a schedule measure because of their familiarity with traditional estimation when in fact, story points is meant to represent the size of the functionality we are building or the scope of the work including the amount of work + complexity + risk of that work. In other words, it was like comparing apples and oranges.

With this in mind, I strongly advocate that in Agile it is much more meaningful and appropriate to use the term “size” as the verb to measure the user stories since this relates to the amount of functionality you are building. This is more than just semantics. This takes us a step away from the traditional mindset where schedule is “king” and moves us to the more important focus of scope since to our customers, the functionality is what is valuable. Now make no mistake, there will be trades offs between schedule and scope, but working software that meets customer needs and provides them value is IMHO slightly more important (e.g., working software over schedule).

It is also important to note that a team’s sprint velocity is a representation of how much functionality can be delivered within a sprint. This is yet another reason why I encourage you to use the term “size” since sizing individual stories relates to the functionality you are building and the sprint velocity relates to how much total functionality is delivered in a sprint.

So if you are having trouble understanding or explaining the concept of estimating user stories, think in terms of the scope of functionality and consider using the term “size” instead of “estimation” to break from the traditional mindset of schedule. So maybe size does matter after all…

Agile and the Cloud – Match made in Heaven!

Agile and the Cloud are both pervasive these days.  Agile is a software development method based on an iterative and incremental approaches. Applying an Agile method and mindset can, on the one side, can incrementally build Software as a Services (SaaS) based products and, on the other side, utilize IaaS (Infrastructure as a Service) and PaaS (Platform as a Service) to build the SaaS products and services.

As most software professionals are aware, the action of delivering the increment into the traditional on-premise software product environment is often laborious and time consuming. SaaS conveniently provides shared software products as services, and associated data via the Internet, a model that can be scaled and configured to a company’s or product team’s needs. SaaS changes the software paradigm by providing the software as a service “in the cloud” to people and companies that need that product or service. Companies no longer need local administrators to handle the rigorous and time-consuming effort of establishing on-premise product infrastructure and the installing the software.

When building products for the cloud, a production-ready environment is made available to teams almost instantly. While most products require an on-premise installation, building cloud products reduces the need for the often rigorous and time-consuming effort of installing the new releases of the software product infrastructure prior to the installation. Because Agile utilizes an iterative and incremental approach, SaaS products can be incrementally upgraded when the Sprint Review (aka, demonstration) indicates that the product is ready. The effort on the SaaS provider side is reduced also, because a few installations by experts are much easier to develop and manage than the many installations by customers (and documentation, ramp-up, and problem resolution that are included).

On the Agile side, the challenge is to build an infrastructure that supports Agile and does not impede the progress of the Agile team that must continue to deliver value. A simultaneous goal is to avoid investment in infrastructure that may not be needed in later phases of the project. One suggestion is to utilize the infrastructure envisioning approach, which applies an incremental approach to the continuous establishment of an effective infrastructure. This is where Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) can be useful to Agile teams. The cloud IaaS and PaaS approaches enable consumers to only use and pay for what they need. This is a distinct advantage for incremental development processes like Agile. This "use-what-infrastructure-you-need" approach minimizes technology debt and allows the team to adjust and scale its needs just-in-time.

As Agile methods continuously build SaaS product increments (i.e. functionality), the cloud delivers them as increasing business value to the customer with little effort from the customer. In addition, the cloud (by way of IaaS and PaaS) provides Agile projects with tools and infrastructure just-in time, so that the team always has the tools and infrastructure they need but never wastefully invests in unused equipment. Consequently, they are able to provide continuous value to the customer in the cloud. This mutually beneficial relationship is a “match made in heaven” for project teams utilizing Agile to build software in the cloud and using cloud infrastructure to support Agile projects. 

Have you benefited with the Agile and Cloud relationship?  If so, in what ways?  

Agile Value Capture Metric - Are you spending your time Building Value?

When applying an Agile mindset, a team should consider the value of each task that they are working on.  Agile often brings value concepts into play and determining the value of tasks is one way to achieve this.  Is the task considered value-added or non-value-added.   Sometimes folks have a hard time wanting to separate tasks into value and non-value because it highlights the non-valued tasks folks are doing. However, if you really want to know, then you must do this (typically at the Product team level).  Sometimes the answer surprises people.   

Keep in mind that in Agile, value-added tasks refer to only those tasks that are directly related to building the product and that your customer values.  This would primarily include user stories and the attributes of this work related to the “done” criteria (e.g., incrementally designed, developed, built, tested, etc.) in order to complete the user story.  Remember, value is from the customer's perspective.  

On the other hand, non value-added tasks do not contribute directly to building the product.  There are tasks that are out-right of no value including administrative related tasks, writing status reports, all-hands and other status meetings.  There are tasks with no direct customer value but have benefit to quality including spending time on correcting defects, tasks related to technical debt, performing refactoring. Please understand, there are levels of internal value in doing these things and the goal is to make the value levels of the work transparent. 

A good practice in Agile (e.g., value capture metric) is to capture all related work or activity a team does in a sprint (as backlog items) to understand what are value-added tasks vs the other tasks that we do.  For each story or backlog item, assign it an attribute of either “value-added” or “non-value-added”.  You can track this on a sprint basis (or release basis) or trend it over time (from sprint to sprint).  This is a team-based metric so it is for the team's eyes only.  Below are some examples:

Chart 1: Value of work per Sprint (can be rolled up to the release level)

Chart 2: Value of work per Sprint (at the detailed level)

Chart 3: Value of work from Sprint to Sprint (Trend line)

The big advantage of this type of metric is that it helps you 1) be aware of the value and non value related work that your team is doing and then 2) it allows you to make adjustments if you want to get to a more value-added stream of work.  Also, an important caveat: this metric is a team-based metric and not meant to be shown to management.  It is for the team to see where their work is being spent.   

Whether you call it value and non-value work, the key is that much like the prioritization of the backlog, that you become aware of the priority of the various types of work that is occurring on your team. This metric also brings transparency to the types of 'work' where the team members are spending their time.  While this may force you to make some tough decisions (what is value-added and what is not), it will be worth it in the long run to get your team more productive and focused on the value-added work for your customers.  This can help you on your Agile journey!