The Journey: Why the magic is not happening? Chapter XII - Part 3

Renato de Bruns and I learned the hard way, you don't have to. We are co-authoring our real-life experiences in a large corporation that is on its journey to Agile and that will give practicality to this not-so-magic world. This is being hard work and we are committed to the Agile community to share and learn, growing together, and give back.

Driving change

Before we even start talking about metrics, we need to talk about objectives. You shouldn't have charts with an objective to use data. You should have charts that track something you want to improve!

Metrics

Another analogy (yey!): an airplane pilot has on his cockpit several different indicators, so on the runway, he needs to know his velocity to know if he will be able to take off or not. For that, he has a speedometer (or maybe there is another fancy name in the airplane) as an indicator for his objective that is to take off safely. But he shouldn't only trust that indicator… maybe it is broken. A simple way is to test the truth: if he looks out the window, what will he see? Thus, supporting indicators are also important to make sure you are on the right path or not getting side effects.

Whatever you're measuring, must be tied to a higher objective. It must have the measurement alongside a strategy that will drive the metrics to change: training, (real) root cause analysis efforts, upgrades, technical stand-downs, etc. The work your team will do should be tied to that objective, or no changes will take place.

Also, a reason for creating that objective, thus the metrics, must be clear. As an example, if there are many incidents coming up to your team, a good start is to understand why they are happening (see 5-whys technique). With this understanding, you will be able to set goals that will lead to the incident reduction with the results directly influencing the number of incidents, thus driving the changes that you want to see on your metrics. The inspect & adapt practice will help you identify if the actions are being effective or not, so you can make the necessary adjustments.

How much change?

The number of objectives should also be limited. You can only drive so much change at once, so be careful and don't try to change the world.

Start with the biggest pain points from your team and customer and go from there. A good approach is to use the SMART technique: is this specific? Is it measurable? (quite important being on this topic, no?) and so on…

Also, the plan should not be created solely by whoever is interested in that. It needs to involve the team so you can use the collective intelligence to create the plan and ownership is shared.

Add more as you reach acceptable levels of maintenance for those metrics. You need to have an end goal where you will move into other pain points and manage this at an acceptable level. Back to the example of incidents, let's say you start with a 30% level of incidents on your team. Every month (or another timeframe of your choice) you can target to reduce it by 10%, but maybe not to take it to zero as an overall 10% level of incidents could be acceptable (point of diminishing returns). Then you can move to your next goal.

Don't be discouraged, driving change takes time and requires resilience. You may need to change approach but the objective, being real, is the enemy you will defeat. It will take time at first and when you see victory you will be proud.

Let's get real now!

Lead and Cycle Time: this is powerful yet simple to get implemented and needs careful assessment… One special case we had was the super-high lead time for old requests. Interestingly it is hard to cancel these old items as requestors can refuse to let them go even though they can stay in the backlog for years due to its low priority, thus keep asking always if that should be addressed or not. Nevertheless, it is worth keeping the backlog evergreen and continue to challenge these old requests. The common approach people take on this one is to use Lead/Cycle time to determine the team's predictability, however, they calculate the average of Lead/Cycle time; the problem with this is that you will always be 50% off, so instead of calculating the average, prefer the 90% percentile (e.g. 90% of chance to finish the work under X amount of days) to be able to say: the change of my team finishing this by X days is 90%. Also, make sure you use support indicators to avoid impact on other areas (e.g. a faster team can generate more defects) (Interested Roles: Product Owner + Product Manager + Requestors)

Incidents / Expedited Work: this is what disrupts the teams' focus and may diverge them from the PI Objectives. These need to be well understood to either address quickly or engage the right teams for real root cause analysis, so they don't repeat and doesn't impact the team capacity every PI. (Interested Roles: Release Train Engineer + Product Owner + Scrum Master)

Backlog Age: keeping a recent backlog can directly help with the speed of delivery. The older the item, the more likely it is going to take longer to resolve as people will not be as available and the problem will not be as fresh to trigger the action. Also, old problems may not be high enough priority so you need to think about whether you're really going to bring this to execution. (Interested Roles: Product Owner + Requestor)

Throughput: what is the rate you're pushing value to your customer? This will help you to understand your predictability and see if there are any estimation or skills management issues. Some quality indicators can be used to support this. (Interested Roles: Product Manager + Product Owner)

Capacity/Availability vs Velocity: How does your team deliver in the function of the team's availability? How vacations, days off, training, etc. impact your results? This understanding will help to give a lot more flexibility to the team and the impacts to the throughput as early as possible. (Interested Roles: Delivery team + Scrum Master)

Impediments Age: moving fast does not mean not having impediments but clearing them effectively is key. Having a proper impediment management process tied to the metrics is key to keep the flow of work; also, having the right contacts and schedule alignment is important to untangle the team if any doubts or questions arise. An old impediment may mean you are letting things get behind, and worst case, delay your value capture. (Interested Roles: Scrum Master + Release Train Engineer)

Benefits/Value: before we even start talking about delivering value, we need to talk about identifying the benefits. Where these benefits will be realized? Is it time saved in a process? Are we expecting workforce reduction? Does it lower support cost? Is it different per site? Or is this a global outcome? These questions are key to understand the correct priority that should be given to each work item and ensure we are working on the things that bring these benefits as early as possible, thus reducing the cost of delay. (Interested Roles: Product Management)

Lost Seat Time: are you accounting for system availability? End from which perspective? Technical? Usage? Pure incident? How about looking at the user perspective and how its unavailability affects the daily activities? For every incident we receive, we start the assessment on whether it is disruptive to the end-user. If that's the case, try to understand how many people are getting impacted and when the problem is solved, we account for all the hours that these users haven't been able to do their jobs effectively. Then, these are revised with our Program Manager and BPEs to ensure we are all aligned with the impact, both on severity and duration of the incident. This helps us to better understand whether the service is up to expectation and/or when escalations are required. (Interested Roles: Requestor + Product Manager)

How about you?

• What do you measure? What did you change when you start measuring it?
• What did you stop measuring because there was no apparent value on your environment?
• What did we get wrong?

Share your thoughts and let's get better together!

Also, check our previous articles:

https://www.dhirubhai.net/pulse/journey-why-magic-happening-rafael-barbosa/

https://www.dhirubhai.net/pulse/journey-why-magic-happening-chapter-xii-part-1-rafael-barbosa/