All articles in our "Measuring Agility" series:
- #1 Measuring agility: what does it mean?
- #2 Measuring agility: a good idea?
- #3 Measuring agility: what pitfalls to avoid (1)
- #4 Measuring agility: what pitfalls to avoid (2)
- #5 Measuring agility: what to measure (1)
- #6 Measuring agility: what to measure (2)
- #7 Measuring agility: the final word
Previously, in measuring agility...
We talked about what it means to "measure agility" based on a definition of what agility could be, which was:
A characteristic A characteristic of an individual, team or organization that is able to adapt to changes in its environment through :
- The most regular and frequent delivery of value possible, according to the evolving expectations of its users and its ecosystem;
- An exemplary mindset that promotes collaboration, autonomy and self-organization;
- The constant search for quality and improvement in its activities and interactions.
We have explained why there is no reason to perceive agility measurement as something negative or antinomic with agile values. It can help us situate ourselves in relation to a target we set for ourselves regarding our ability to deliver more value, collaborate, do quality work... and therefore improve.
We also talked about the pitfalls to avoid when implementing these types of practices. For example: measuring without knowing why, giving in to the temptation of wanting to control everything, putting individuals or teams in competition with each other... among others.
Having said that, what can we measure, what agile indicators should we follow and what will it do for us?
Agility Indicator #1: The evolution of the added value perceived by users
Peter Drucker* once said that "nothing is more useless than to produce something efficiently that should not have been done at all"..
* Peter Drucker is a relatively well-known American management professor (1909-2005). He is described as "the father of modern management".
Later, we will measure our ability to deliver new solutions on a regular basis, in a qualitative way from a code perspective. But will that tell us if we are really meeting the needs of our users? No. But it is essential.
The graph above shows theclassic evolution of a cumulative value added curve over time.
At the beginning, we will tend to work on subjects that are essential to the good start of our product, sometimes less rich in value for the users, while trying to bring some valuable features.
After a few weeks, we should normally be working on topics that are well identified as the most important for our users.
And over time, while we have dealt with the most important topics, the remaining ones should normally add less value.
Why measure this agile indicator?
It is a measure that will allow us to know whether or not we are going in the right direction with regard to what seems important to the people we work for. Satisfied users are users who will be loyal to you, who will not go to the competition. Or who will go to the competition for other reasons (like price). But they will come back one day if the competitors are not able to match their level of understanding.
How to measure it?
There are several possibilities. It can be, for example, assigning a value to each request, with the help of a panel of users. And counting the total value that has been reached each month. It can also be inviting key users to a regular product review. And ask them to rate what they saw, from a value-added point of view (a lot of value = a higher rating). There are definitely other ways to do this.
How to improve it?
User-perceived value added that decreases over time can be a symptom of several things. It may be because the team has spent more time working on subjects with low perceived added value. For example, technical topics: optimization, bug fixes... Hence the interest in smoothing this type of topics over time as much as possible. This can also be due to a poor understanding of the needs. Whether it is in their formulation, their prioritization or the response provided. This should encourage the team to work more closely with its stakeholders.
Agility Indicator #2: Cycle time evolution
What is cycle time? It is the time between when we start working on a subject and when it is considered finished.
In the context of a software development process, this is generally the time that elapses between the moment the team starts working on a development and its release to the production environment.
In the context of a non-IT business process approach, the same reasoning applies. Let's take the example of an HR department that processes applications. The cycle time could be the time elapsed between the moment the candidate's file starts to be reviewed and the final answer given to the candidate.
It is a duration: it is therefore generally expressed in days or hours. The cycle time of each request can be considered independently. But it is more interesting to visualize the average cycle time of a team, or even of a type of request. This allows you to see how it evolves over time.
Why measure it?
A better cycle time helps to achieve a better crossing time (see below).
How to measure it?
For each request, simply note the start date of the work on the expressed need. Then note the date of availability to the user, and make the difference between the two.
How to improve it?
To do this, we can reduce several things:
- delays in decision making,
- delays due to blockages in the work process,
- unnecessary back and forth.
This is a first axis that allows for serious gains, because the request will be completed more quickly. This is one of the reasons why self-organization and autonomy of teams and the composition of cross-functional teams are emphasized in agile approaches: to ensure better responsiveness.
Automating a number of time-consuming operations, such as testing, also helps. It saves time and reduces the risk of errors.
Agility Indicator #3: Crossing Time Evolution
The lead time is, in the most generic way possible, the time that elapses between the start of a process and its completion.
In the context of a software development process, this is generally the time that elapses between the expression of a need by a user and its release on the production environment. And if we go back to our HR department, what would be the crossing time? It could be the time between the receipt of the application and the final answer given to the candidate.
The cycle time is therefore included in the traverse time. A shorter cycle time will help to achieve a shorter throughput time. The traversal time consists, in addition, of the time that elapses while the request is in a queue. That is, waiting to be processed, but not being processed. Hence the interest, for more reactivity, to be able to reduce the length of this queue.
Why measure it?
A better throughput time means a faster response to a user's expressed need. This implies an ability to deliver value more regularly, which was one of the axes of our definition of agility seen earlier.
How to measure it?
For each request, simply note the date of the expression of the need by the user to the team. Then note the date of availability to the user. Finally, simply make the difference between the two.
How to improve it?
To improve the throughput time, it is important toimprove the cycle time (see above). It is also necessary to reduce the time during which the request remains in the state of an expressed request, but on which no work has yet been undertaken. One way to do this is to reduce the length of the backlog. This allows you to discard ideas that are not sufficiently valuable to focus on the essentials.
Next episode
We will cover three more agile indicators in our next article. Stay tuned for future articles on the subject.
