Agile Metrics and A3 report a good combination
In order to align expectations, I will not go into the history of the A3 model, nor the metrics here mentioned here but rather into how I’ve been using them. If you are not familiar with these subjects I recommend you to read the references quoted at the end of the article and then come back :D
Today I will talk about how I have used the A3 model, which was originally created in Toyota.
Context
Starting working within a team I realized there was a great will in starting to use data (Lead-time, throughput, age, CFD and other) to help in the decision making and improvement of the team. I also noticed that there was already a great amount of data, however, the team didn’t know what to do with it and how to interpret it.
At a certain point we were talking about continuous improvement and quality, I was reminded of the PDCA cycle (Plan, Do, Check and Act) and a display tool that is based on the PDCA called A3, as shown in the picture below:
Use
If you look through the internet you will find various A3 models. I recommend you to always adapt them to your own context. The picture above shows the template that I’ve adapted to my own context.
Let’s now go through the A3 fields, one by one, and explain their use.
1. Background (Plan)
On the first field, we set up the reason why we are using this report, or better yet, which are the questions we want to see answered.
2. Initial Condition and Problem Definition (Plan)
This is the moment we evaluate the current scenario and check in what state we find ourselves, so we look at some metrics such as:
Lead Time: Backlog to Done
Cycle Time: To Do until Done
Throughput: Weekly
Standard Deviation: Throughput Variation
These are the metrics inherent to the context I was working in. Nonetheless, you can use which other metrics and info you might find valid.
3. Analysis of causes and confirmation of root causes (Plan)
In this particular field, we intend to understand “the why” of the values mentioned above. This is why I like to use the CFD (Cumulative Flow Diagram) as there we can see the behavior of the flow throughout the time and have a clear vision of any bottlenecks. Depending on your context, you may also use other graphics like bug’s rate, the rate of tasks that we went out of scope, among others.
The important thing is to have graphics and a brief summary of each graphic to give context about what we are observing. As I usually say:
“Graphics and data without context are just numbers and drawings/doodles”
4. Target condition (Plan)
This is the moment to define the goals you mean to achieve, the moment when you think about what would be the ideal scenario.
Ideally, they should be tangible/measurable; for example:
- Decrease Bug Ratio from X to Y
- Decrease our standard deviation from X to Y
- Decrease Lead Time or Cycle Time from X to Y
- Decrease How long the task stays in Code Review from X to Y
5. Countermeasures (Do)
In this field, we will talk about what we are going to do to reach our objectives, what will be the measures taken.
Here you can create a table:
Or simply create a list of actions
6. Check
This field shows whether countermeasures have any effect or not. So as time passes this field should be updated with the current data. However, I have decided to update the entire A3 once a month to have snapshots of the progress.
This way my A3 is basically like a photograph of that specific moment in time and next month I will take a new photo. Then every month I open a new tab and update the data
Note below how the 2.Initial Condition and Problem Definition field now updated
As you can see in the example, the numbers can worsen or improve, So I update the field 3.Analysis of causes and confirmation of root causes accordingly, contextualizing on the new scenario where the team is.
It so happened that I ended up using the 6.Check field only to report how often we’ll be looking at the data and arguing over the results, which in this team’s case was every Friday — as per their decision.
7. Follow-up (Actions)
In this field the actions that need anything to be done or any kind of followthrough to ensure their sustainability.
Here I usually add graphics like Burn-up and Monte Carlo, and any actions that may derive from them.
Results
After a few months using the A3, we have gained more visibility into the impacts of actions and choices we make on a daily basis; what were once were once perceptions and guessing have become measurable and palpable data and knowledge source.
An example of this was being able to measure the impact of poor project planning on the team’s cycle time, which with the view the A3 brings it was very easy to show which explain to any level of the organization.
Another important point was to be able to identify which stages of the workflow were the real offenders for such a high cycle time. And in this way to be able to apply Kaizen at the right point and see the results over time over time, since A3 is taking a photograph at every X period of time.
The A3 report is simple to do and easy to understand when well assembled. For this reason, several of the company’s teams, in different parts of the world, have incorporated the A3 in their daily life, thus facilitating conversation and increasing understanding about team’s and the organization’s metrics.
