An Arbitrary Review and Reflection on 2023 Blogging

Brighton Pavillion reflected in water, with 2024 subly overlaod over the top.  Representing a review and reflection of 2023 and looking forward to 2024.
Photo by Robb Banks

I’m not a big fan of New Year’s Resolutions. Mostly because they assume a degree of certainty and predictability about the future that rarely plays out. But also, it seems like an arbitrary and infrequent time to review and reflect! Having said that, at the start of 2023, I did decide to make an intentional effort to blog more.

Reflections

In a review of 2022, I realised that I had only published 5 posts, and that was part of a longer trend. I wanted to get back into the habit of writing more. Therefore, I decided to make sure I scheduled 1-2 hours every week for writing. The idea was to try and get something publishable in that timebox. In general that proved to be successful. While it often took longer than that to make final edits and SEO updates, the timebox was enough of an enabling constraint to focus on getting a core idea out.

By the end of the year, I had published 23 posts – my most productive 12 months in 10 years! I’m aware that is a bit of a vanity metric, but I hope the quality was also good enough at least a few people found them useful! (My most productive year was 2009 with a massive 45 posts!). The strategy seems to have worked so while I still find it hard to get started, I need to keep going in 2024.

Top Posts Published in 2023

These are the top 5 posts I published last year. The #1 in particular struck a chord and was a runaway winner. I’m also surprised that #5 was so popular, but that’s the beauty of blogging regularly. You never know what will resonate and what will fall flat.

  1. The Only Useful Icebreaker Activity Anyone May Ever Need
  2. Strategy Deployment and Flight Levels
  3. Strategy Deployment and Estuarine Mapping
  4. The Evidence To Look For In A Successful Agile Transformation
  5. The Best Agile Accounting Approach To CapEx and OpEx

Top Posts Viewed in 2023

There are the top 10 posts overall last year, regardless of when they were published. It’s interesting to see the mix of newer posts from this year with much older posts from over 10 years ago. Having said that #3 will have been boosed by my recent presentations on the subject.

  1. The Only Useful Icebreaker Activity Anyone May Ever Need
  2. What is Backbriefing?
  3. Fidelity – The Lost Dimension of the Iron Triangle
  4. Strategy Deployment and Flight Levels
  5. Running the Ball Flow Game
  6. How to Measure the Predictability of Agile
  7. What is an X-Matrix?
  8. Portfolio Kanban
  9. Strategy Deployment and Estuarine Mapping
  10. Strategy Deployment, the X-Matrix and Kanban Thinking

There are also a couple of game pages which are still proving to be popular and would have been mixed into this top 10.

So that’s my review and reflection on 2023. It also makes the first post of 2024. That feels like a bit of a cheat, but the important thing for me was to get back into the rhythm and discipline as soon as possible. Hopefully next weeks the content will be more challenging!

A Simple Resolution to the Agile Transformation Conundrum

F22-Raptor accelerating up through the clouds as a metahof for strategic agility as an alternative to agile transformation.

I have been chatting with colleagues recently about our recent shift from offering Agile Transformation services to Strategic Agility services. Many years ago I posted about the Agile Transformation Conundrum, and this is a natural evolution of that thinking.

Agile Transformation

There is a lot of pushback against the word transformation, with many seeing it as a linear, one-off event, that can be completed. A bit like a caterpillar goes through a transformation into a butterfly. It’s a valid point, although alternative words, such as transition, or journey, have the same problem.

However, that’s not why I have a dilemma over the phrase. After all, when an Agile Transformation is successful, there is a significant change that happens. The issue I have is that it places the emphasis on the word Agile as the goal. In other words, the perception is that an Agile transformation is one which has a focus on doing Agile. This brings with it the risk of imposing and inflicting Agile on people.

Transformational Agile

When I talk about Transformation, I prefer to qualify it as Outcome-Oriented and Continuous Transformation. The perception now is that the transformation is one which is never done, and is always moving towards “uncovering better ways” rather than simply implementing new ways.

Thus, I prefer to place the emphasis on the word Transformation rather than Agile. The phrase Transformational Agile might be a better alternative. It suggests that Agile is a means to an end, rather than the end in itself. Even better still, Transformational Agility shifts the focus onto being agile in order to transform.

Strategic Agility

However, even Transformation is not an end goal. Rather, the transformation is required for an organisation to be competitive and adaptive. That leads to the idea of Strategic Agility. In other words, Agility is a strategy and Agile is a tactic. Thus Strategic Agility shifts the focus further to having Agility both as an organisational strategy itself and to enable Strategy Deployment. This brings with it the opportunity to invite and engage with people on how to do that.

This switch from talking about Agile Transformations to talking about Strategic Agility changes the conversation from just how to implement Agile practices, to how to get the many benefits that Agility promises. If you have gone through an Agile Transformation, but are not getting the benefits you had anticipated, then Strategic Agility might be the answer.

Teaming the Push and Pull of People and Projects

Four people gathered around a fifth person at a computer, representing teaming.

The Agile movement popularised a shift to teams which could pull their work, rather than having work pushed onto them. Practices such as Sprint Planning, or WIP Limits enable this. However, I’ve recently been thinking that rather than the people pulling the work, the work should be pulling the people. This seems counter-intuitive, and equivalent to going back to the traditional project-based approach of the past. To differentiate the different approaches, I will describe three basic teaming models.

Pushing People to the Work

This is the typical project teaming model. First, a central group (e.g. a PMO) defines the work up front as a project. Then they form teams and people are pushed to the work by allocating them to the projects. The diagram below visualises this, with the work at the centre, and people being pushed onto it. Apologies for the terrible artwork. I have tweaked the graphics from slides I used for Kanban presentations over 10 years ago!

A represention of teaming which pushes people to the work. Work is in the middle, surrounded by people being pushed towards it.

In reality, people are often pushed onto multiple projects, making things even worse. In the next diagram, notice the unlucky person in the middle who has been allocated across (pushed to) three projects. At the same time, once people have been pushed onto projects, the actual work is often pushed back onto them. Time, scope and cost are fixed, with no allowance for their actual capacity or capability to do the work.

A represention of teaming which pushes people to the work, with multiple projects. Some people are surrounding and being pushed to multiple projects.

People Pull the Work

This is the typical Agile teaming model. First, long-lived and stable teams are formed to align to some product or value stream. Then the work is defined as backlog items (or options) and the teams pull that work as their capacity and capability allow in order to deliver value.

A represention of teaming where people pull the work. Value is in the middle, surrounded by people, and those people are pulling work from a backlog.  There are two teams with two backlogs.

While this model is typically used with single agile teams, it can also be applied at scale with teams of teams. SAFe’s Agile Release Train structure usually consists of pre-formed and fixed teams that have a backlog of work to pull. As a result, PI Planning is often an exercise in managing dependencies between teams by adjusting the backlog and scheduling items into iterations.

Work Pulls the People

This is more of a Dynamic Reteaming model. First, a value stream is identified, and work is defined as backlog items (or options) to flow through the value stream. At the same time, a pool of people is also identified as part of that value stream. Then the people self-organise themselves into teams as necessary to deliver the highest value work, to the best quality, with the fastest flow. Thus, while the work is pulled into the value stream as capacity allows, it then pulls the people required to enable the flow. As new work is pulled in, the teams may reform to better match the skills and experience required by the changes in demand.

What this looks like in practice is a regular cadence where people can come together to review the current work and anticipate future work. In doing so they can re-organise themselves to deliver the highest value work, at the earliest date, to the best quality. A more general quarterly “Big Room Planning” (as opposed to SAFe’s PI Planning format) can be a good way of doing this.

A represention of teaming where the work is pulling the people. Work is in the middle, surrounded by people, with the work pulling those people. The work is part of a backlog with is being pulled to deliver value.

Also, notice that in the above diagram, not everyone is on a team. Sometimes, it makes sense for people to float between teams to enable them to get better. Or they may form an enabling team of their own as per Team Topologies. Similarly, there will realistically be some constraints around who should be on each team. This may be with respect to experience and continuity to maintain consistency and quality of what is being built. Effectively, this dynamic reteaming model shifts team formation away from governing constraints which are independent of the work context. Instead, it shifts towards enabling constraints which allow for the context of the work.

Three Agile Strategies That Will Make A Strong Impact

The impact of something dropping into water, with splashes and ripples, representing agile strategies making an impact on a business
Impact by Walter-Wilhelm

Much of my recent writing about Strategy Deployment has been driven by the idea that Agility is a strategy while Agile is a Tactic. However, Agility is a very broad topic, and can easily slip into being a buzzword or platitude. In other words Bad Agile. This suggests that there are some more useful Good Agile strategies.

When I blogged about deploying strategies as choices I suggested that the Agile Manifesto could be interpreted as a set of strategies. They looked like this.

  • Enabling individuals and interactions even over common processes and tools
  • Developing working software even over providing comprehensive documentation
  • Collaborating with customers even over sticking to contractual obligations
  • Responding to change even over keeping to planned commitments

More recently, I’ve been wondering whether there is a better way of describing agile strategies in order to emphasise the core challenges that agile is addressing. That took me back to the Kanban Thinking Impacts that I described as part of the Kanban Thinking model I created. Those impacts are Flow, Value and Potential.

Flow

A “Flow” strategy is one which focuses on “doing the work right”. This involves organising people into cross-functional teams who can collaborate to deliver work quickly. In other words, work flows through teams rather than people being allocated to work. Further, this can mean a shift from an annual planning cycle where people juggle multiple short-lived initiatives. Instead, there are more frequent and dynamic investments in long-lived value streams. As a result, the business is able to respond to unforeseen challenges and take advantage of unanticipated opportunities.

Using the even-over format, I would describe this as a choice to “Organise for fast flow of change even over long-term certainty of plans“.

Value

A “Value” strategy is one which focuses on “doing the right work”. This involves structuring the work to be able to continuously understand and meet customer needs. As a result, there is usually a shift from projects to products. Projects often try to optimise the cost of work through separate technical or architectural solutions. Conversely, products try to optimise the benefits of the work by collectively prioritising collaborative solutions. As a result, products can be continuously validated and evolved to deliver what is most important to customers. After all, increasing value is infinite while reducing cost is zero-bounded.

Using the even-over format, I would describe this as a choice to “Maximise the value of products even over minimising the cost of projects“.

Potential

A “Potential” strategy is one which focuses on “doing the work sustainably”. This involves working in a way which enables long-term adaptability and learning. As a result, there is a shift from cutting corners and short-term solutions to building quality in and long-term investments. By creating fast feedback cycles, teams can learn more about their products and services and how they are being used. Further, that feedback enables people to have autonomy, mastery and purpose in their work which creates more potential in them. To paraphrase an expression used by Toyota, build people in order to build products.

Using the even-over format, I would describe this as a choice to “Create feedback for long-term potential even over making short-term gains“.

It should be obvious that these three strategies work together. Achieving flow requires organising around value, and delivering value requires achieving flow. Both require building long-term potential. However, they each emphasise something different and important in terms of organising for flow, delivering products of value, and creating potential through feedback.

These three strategies are just the way I think about the core challenges that Agile is addressing. Let me know if you have different strategies and what they leverage.

Agile Advice, Like Youth, Probably Just Wasted On The Young

Agile Advice via Everyboyd's Free (To Wear Sunscreen).
Everybody’s Free (To Wear Sunscreen)

Background

In June 1997, Mary Schmich published an essay in the Chicago Tribune titled “Advice, like youth, probably just wasted on the young“. It was a hypothetical graduation speech as a “Guide to Life for Graduates”. She also encourages readers to try it themselves, which begs the question of what agile advice might be.

The speech is probably best known through its use as lyrics for the song Wear Sunscreen by Baz Luhrmann. There’s an interesting Switched on Pop podcast episode that describes the history and references a BBC documentary.

When I listened to that podcast, I wondered what a parody version might look like which gave advice about Agilem and put the idea on my backlog where it stayed. However, I never felt inspired or creative enough to do anything with it.

Then came the current chatGPT craze. Maybe that could help write the parody version for me. It turned out not to be as easy as that. In the end, I spent a lot of time tweaking the input prompt, to change the probabilities of the output from the stochastic parrot, to get something I was happy with!

However, while I couldn’t quite get chatGPT to match the structure and length of the lyrics in the way that I wanted, it came up with some good ideas I have used. So it did at least get me started and create something which I could finish. Maybe chatGPT is the new rubber duck debugger?

Hopefully, that sets the scene for this post. Maybe one day I’ll submit the version as a conference proposal and perform it live…

Everybody’s Free (To Limit WIP)

Ladies and gentlemen of the Agile class of 2023,
Limit work in progress.

If I could offer you only one tip for your agile teams, WIP would be it.
The benefits of limiting WIP have been proven by many teams,
Whereas the rest of my advice has no basis more reliable than my own meandering experience.
I will dispense this advice now

Enjoy the power and freedom of Agile, oh, never mind
You will not understand the power and beauty of Agile until you have gone through the agony of waterfall.
But trust me, in 20 years, you’ll look back at your old ways of working and recall in a way you can’t grasp now
How much possibility lay in the good old days of Agile.
You are not as experienced as you imagine.

Don’t worry about skills or certificates
Or worry, but know that worrying is as effective as trying to finish everything in your backlog by tomorrow
The real challenges in Agile are continually learning and growing,
So don’t hesitate to ask for help, collaborate and share knowledge.

Do one thing every day that you learn from

Automate

Don’t be reckless with other people’s code
Don’t put up with people who are reckless with yours

Refactor

Don’t waste your time on documentation
Sometimes it’s right, sometimes it’s wrong
The effort is large, and probably no one will read it anyway.
Remember the conversations you have, forget the arguments
If you succeed in doing this, tell me how
Keep your old test suites, throw away you old UML diagrams

Integrate, continuously

Don’t feel guilty if you don’t have everything figured out yet.
The best developers I know didn’t know at 22 how to solve every problem
Some of the best 40-year-old developers I know still don’t
Get plenty of rest
Be kind to your team
You’ll miss them when they’re gone

Maybe you’ll write clean code, maybe you won’t
Maybe you’ll release continuously, maybe you won’t
Maybe you’ll debug for hours, maybe you’ll do it pairing with a rubber duck
On your 75th wedding anniversary
Whatever you do, don’t congratulate yourself too much
Or berate yourself either
Your choices are half chance, so are everybody else’s
 
Enjoy your agile knowledge, use it every way you can
Don’t be afraid of it or what other people think of it
It’s the greatest concept you’ll ever know
Experiment, even if you have nowhere to do it but in your own cubicle
Read the man pages even if you don’t follow them
Do not read requirement documents, they will only make you feel depressed.
 
Get to know your customers, you never know when they’ll have new needs
Be nice to your colleagues, they have a wealth of experience from the past
And they’re the people most likely to help you in the future.
 
Understand that colleagues come and go
But for a precious few, you should hold on
Work hard to bridge the gaps in geography and time zone
For as the older you get
The more you need the people you wrote the code when you were young
Work in a big conglomerate once, but leave before it makes you hard
Work in a small startup once, but leave before it makes you soft
 
Learn
 
Accept certain inalienable truths
Backlogs will grow, Product owners will change their minds, you too, will get old
And when you do, you’ll remember that when you were young
Stories were small, Product Owners were noble, and team members respected their Agile coaches
 
Respect you coach
 
Don’t expect anyone else to fix your bugs
Maybe you’ll have a tester, maybe you’ll have a junior developer
But you’ll never know when either one might quit
 
Don’t be too hard on your ScrumMaster
Or by the time they are 40 they will look 85
 
Be careful with which frameworks you use but be patient with those who create them
Frameworks are a form of nostalgia, creating them is a way of fishing the past from the disposal,
wiping it off, painting over the ugly parts
And reselling it for more than it’s worth
 
But trust me on limiting work in progress

The Only Useful Icebreaker Activity Anyone May Ever Need

Jim Benson recently wrote a blog post on how Icebreakers Can Actually Be Useful. I have similar feelings to Jim about icebreaker activities that are contrived and awkward. Many seem to be tailored towards creativity and extroversion and rarely seem relevant to the work at hand.

Having said that, a good icebreaker can be useful, and I’ve recently found myself reusing the same basic format in different workshops. It’s very simple, and this is it.

… is like what?

The ellipsis at the start is replaced with something relevant to the workshop. For example, in a value stream mapping workshop, I might ask “Your current value stream is like what?” Or at the start of a portfolio workshop, I might ask “Your current portfolio is like what?”. Sometimes it becomes plural such as “Your current teams are like what?”. I’m sure you get the picture.

You might recognise this question from Clean Language. Its intent there is to be curious and explore metaphors. While it is really good at that, I also find that it works well for more literal thinkers who might want to describe something more factually. And there is a whole range of possibilities in between, so it generates some really valuable content to start a workshop with.

I like this question for 3 reasons.

Contribution

It gets people contributing to the work. I learned an early lesson as a trainer and facilitator, to “get people’s voices in the room”. The theory is that when people have spoken once, they are more likely to speak up again. Thus everybody can contribute an answer to the “… is like what?” question, without anybody having to feel pressured into being overly creative and original.

Connection

It gets people making a connection to the work to be done. In other words, that contribution is meaningful, and not something that will be discarded and forgotten. Training from the Back of the Room describes “4Cs” of Connections, Concepts, Concrete Practice and Conclusions. In that framework, a Connections activity is designed to connect learners to each other and to the topic. The way I use this icebreaker does exactly that.

Context

It creates a shared context for the group at the start of the workshop. The majority of times I have used the question, something comes out that becomes a recurring theme and thread throughout the rest of the workshop. At the very least it usually gets referred back to every now and again. Additionally, as a facilitator, I can start learning a huge amount about that shared context as well.

Do your icebreakers help create a meaningful contribution, participant connection, and shared context?

The Best Agile Accounting Approach To CapEx and OpEx

Agile Accounting

What is the best way of accounting for costs as different types of expenditure with agile development teams? This is a question that comes up every now and again, particularly during more significant transformations. I usually respond by explaining that I’m not an accountant. It’s also not a topic I particularly care about.

However, I heard Johanna Rothman make a comment which struck me during the recent Drunk Agile Holiday Special. At least I’m pretty sure it was Johanna! I now understand why I don’t care and can give a much better answer.

Value and Cost

Before I get to that though, it’s worth reiterating one of the underlying principles behind agile software development. That is a focus on value.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Agile Manifesto Principle #1

I often say at some point towards the beginning of a new transformation that increasing value is infinite while reducing cost is zero-bounded. This comes up when I get a sense that an organisation views Agile as a means to reduce costs. After all, it’s associated with being more Lean, isn’t it?

I explain that an agile approach might actually cost a little bit more. However, that should be a relatively small increase in cost compared to the potentially significant increase in value. In other words, it’s better to focus on being more effective than more efficient. Or to paraphrase Russell Ackoff, it’s better to focus on doing the right thing, rather than doing the thing right.

Revenue and Tax

Let’s go back to how to allocate costs to different types of expenditure for agile development teams. The usual reason for this is to minimise tax liabilities. After all, minimising tax will increase profit. As a result, organisations try to design their processes and practices to make it simpler to minimise tax. That’s fairly easy in a traditional, large batch, stage-gate process. Different stages can count as different expenditures. The challenge is that it’s not so easy with agile teams who focus more on collaboration and flow.

What Johanna said is that it’s better to focus on increasing revenue, than reducing tax. Just like value and cost, increasing revenue is infinite while reducing tax is zero-bounded. Thus increasing revenue is the thing which should drive decisions on ways of working, and not minimising tax.

In other words, don’t worry about it. That’s the best agile accounting approach to CapEx and OpEx. Instead, your real strategy and how you are going to deploy that strategy is what is going to have the maximum impact.

The Ultimate X-Matrix For Your Agile Transformation Is Here

Whenever I’ve described the X-Matrix I’ve always had to resort to trivial and made-up examples. This is because real examples are difficult to share due to some form of NDA, and the content means that they need to remain confidential.

However, I have recently finished working on a transformation where the X-Matrix was close to something I could publish. Thus with some simplification and anonymisation, I feel safe to be able to use it. That means that when I say it’s the ultimate one, I mean I’ve finally got around to creating it as an example 🙂

To re-iterate, this is still edited and is still somewhat generic. However, I hope it’s close enough to its original form to be helpful and demonstrate how the X-Matrix might be used. It is not intended to be an exemplar to be copied. In fact, I hope that people question the content, and even find fault with it. After all, as Thomas L Jackson says in Hoshin Kanri for the Lean Enterprise, “it’s the memory of what was said and felt that creates alignment, not the final piece of paper”.

The Example

Given those caveats, here it is, followed by some explanation.

An Example X-Matrix for an Agile Transformation
An X-Matrix Example

True North

“Instantaneous development and deployment”

The intent of this True North was to describe a future where development teams could implement and release a customer request as soon as it came in. This gave the teams a clear sense of direction and met my 3C’s of a good True North. It was challenging in that the teams were a long, long way from being able to achieve it. Next, it was compelling, in that it was something the teams wanted to be able to achieve. Finally, it was concrete, in that the teams knew what it would take to achieve.

Aspirations

  • More releases
  • Fewer defects
  • Less waste

These were existing measures the organisation was already using for their overall transformation, with defined metrics in place. In this case, waste was considered to be work that was an unnecessary overhead or burden. Using these existing measures as aspirations meant that we could connect what we were doing with the wider organisational effort.

Strategies

  • Prioritisation
  • Collaboration
  • Flow

There was much discussion and debate in coming up with these three strategies. The actual wording was more verbose and more explicitly described the choices we were making. We settled on them as the three main guiding policies that would help us focus. When deciding on any actual changes we were going to make, they should help to improve one or more of these areas in some way. Put another way, these three strategies represented the key challenges we were addressing after the initial diagnosis.

Tactics

  • Cross Skilling
  • Automation
  • Agile Fundamentals
  • Product Management

These tactics were the four main areas and workstreams we felt would help make a positive change. They are more specific that the strategies, while still enabling teams to explore different solutions and approaches. In fact, we ended up prioritising Agile Fundamentals, before moving on to Product Management. The other two were longer-term goals and linked to other work that was going on that the teams were able to contribute to.

Evidence

  • Productivity
  • Responsiveness
  • Predictability
  • Quality
  • Value

The first three of these used standard flow metrics, which we introduced to the teams. Building on this, quality and value both looked at the nature of the work flowing through the teams using simple demand analysis.

Correlations

Having come to an agreement on the different elements of the X-Matrix, the coaching and transformation team discussed the correlations. There was a rich discussion about how the various pieces contributed to and reinforced each other (or not). Inevitably, this led to multiple iterations and evolutions before we settled on this version. In fact, the whole X-Matrix was a result of multiple working sessions where we refined our understanding of what the current situation was, what our approach was going to be, and what we were going to do. Our understanding of the X-Matrix continued to change as we progressed with the work, and we did revisit it a number of times, although we never formally updated it.

Conclusion

I hope that gives a sense of how I use the X-Matrix in my work as part of an agile transformation. I’m also always interested in how other people use it, although I understand how difficult that can be. If you do have something you can share, please let me know. Maybe we can create a collection of examples and show a wider variety of approaches.

How to Measure the Predictability of Agile

This post follows up a Twitter thread I posted in November exploring ways of measuring the predictability of teams. I also discussed some this these ideas in a Drunk Agile episode.

Fortuneteller
Fortuneteller by Eric Minbiole

When I begin working with an organisation on the agile transformation, an early conversation is around successful outcomes. My work on Strategy Deployment is all about answering the question “how do I know if agile is working?“.

Sometimes the discussion is around delivering more quickly, (i.e. being more responsive to the business and customer needs). Other times it is about delivering more often (i.e. being more productive to deliver more functionality). Both of these are relatively easy to measure. Responsiveness can be tracked in terms of Lead Time, and productivity can be measured in terms of throughput.

However, the area that regularly gets mentioned that I’ve not found a good measure for yet is predictability. In other words, delivering work when it is expected to be delivered.

Say/Do

Before I get into a few ideas, let’s mention one option that I’m not a big fan of – the “say/do” metric. This is a measure of the ratio of planned work to delivered work in a time-box.

Firstly, this relies on time-boxed planning. This means it doesn’t work if you’re using more of a flow, or pull-based process.

Secondly, the ratio is usually one of made-up numbers. Either story point estimates for Scrum or business value scores for SAFe’s Flow Predictability. This makes it far too easy to game, by either adjusting the numbers used or adjusting the commitment made. All it takes is to over-estimate and under-commit to make it look like you’re more predictable without actually making any tangible improvement.

System Stability

Another approach to predictability is to say that a system is either predictable, or it is not. With this frame, the concept of improving predictability is not valid. The idea builds on the work of Donald J. Wheeler, Walter A. Shewhart and W. Edwards Deming. These three statisticians would treat a system – in this case, a product delivery system – as either stable or unstable. An unstable system, with special cause variation, is unpredictable. By understanding and removing the special-cause variation, we are left with common-cause variation, and the system is now predictable.

For example, we can look at Lead Time data over time. For a stable system, WIP will be managed and Little’s Law will be adhered to. In this scenario, we can predict how long individual items take, by looking at percentiles. Different percentiles will give us different degrees of confidence. For the 90th percentile (P90), we can say that 90% of the time we will complete work within a known number of days.

With this approach, the tangible improvement work of making a system predictable is that of making the system stable. By removing the noise of special cause variation, we are able to make predictions on how long work will take and when it will be done.

Meeting Expectations

An alternative approach is to think of predictability as meeting expectations. Let’s assume I know my P90 Lead Time as described above. I know that there is only a 10% chance of delivering later than that time. However, there is still a 90% chance of delivering earlier than that time. Similarly, I might know my 10th percentile Lead Time (P10). This tells me that there is a 90% chance of delivering later, but only a 10% chance of delivering sooner.

If the distribution of the data is very wide, then there will be a wide range of possibilities. It is still difficult to predict a date between the “unlikely before” P10 date and the “unlikely after” P90 date. Thus it is difficult to set realistic expectations. Saying you might deliver anytime between 1 and 100 days is not being predictable. Julia Wester describes this well in her blog post on the topic using this diagram.

Seeing predictability at a glance on a Cycle Time Scatterplot from ActionableAgile
Seeing predictability at a glance on a Lead Time Scatterplot

With this approach, the tangible improvement work is reducing the distribution of the data to remove the outliers.

Inequality

One way of measuring this variation of distribution is to simply look at the ratio of the P90 Lead Time to the P10 Lead Time. (Hat-tip to Todd Little for this suggestion). This is similar to how Income Inequality is measured. Thus if our P90 Lead Time is 100 days, and our P10 Lead Time is 5 days, was can say that our Lead Time Inequality is 20. However, if our P90 Lead Time is 50 and our P10 Lead Time is 25, our Lead Time Inequality is 2. We can say that the lower the Lead Time Inequality, the more predictable the system is.

Coefficient of Variation

Another way is to measure the coefficient of variation (CV), which gives a dimensionless measure of how close a distribution is to its central tendency (Hat-tip to Don Reinertsen for this suggestion). The coefficient of variation is the ratio of the standard deviation to the mean. A dataset with a wide variation would have a larger CV. A dataset of all equal values would have a CV of 0. Therefore, we can also say that the lower the Lead Time Coefficient of Variation, the more predictable the system is.

Consistency

There are probably other statistical ways of measuring the distribution, which cleverer people than me will hopefully suggest. What I think they have in common is that they are actually measuring consistency (Hat-tip to Troy Magennis for this suggestion). A wide distribution of Lead Times might be mathematically predictable, but they are not consistent with each other. A narrow distribution of Lead Times are more consistent with each other and thus allow for more reliable predictions.

Aging WIP

One risk with these measures of Lead Time consistency is that there are essentially two ways of narrowing the distribution. One is to look at lowering the upper bound and work to have fewer work items take a long time. This is almost certainly a good thing to do! The other is to look at increasing the lower bound and work to have more items take a short time. This is not necessarily a good thing to do! That raises a further question. How do we encourage more focus on decreasing long Lead Times and less focus on increasing short Lead Times?

The answer is to focus on Work in Process and the age of that WIP. We can measure how long work has been in the process (started but not yet finished). This allows us to identify which work is blocked or stalled and get it moving again. Thus we can get it finished before it becomes too old. Measuring Aging WIP encourages tangible improvements by actively dealing with the causes of aged work. This might be addressing dependencies instead of just accepting them. Or it could be encouraging breaking down large work items into smaller deliverables (right-sizing).

In summary, I believe that measuring Aging WIP and Blocked Time will lead to greater consistency of Lead Times with reduced Lead Time Inequality and Coefficient of Variation, which will, in turn, lead to better predictions of when work will be done.

Caveat

A couple of final warnings to wrap up. The first is that these are just ideas at this stage. I’m putting them out here for feedback and in the hope that others will try them as well as me. Secondly, I am not promoting removing all variation completely. The following quote and meme seem appropriate given the seasonal timing of this post!

Deviation from the norm will be punished unless it is exploitable.

OKRs and Kanban – Working Perfectly Together

I have previously posted separately about Strategy Deployment and OKRs and Kanban. This is a guest post by Matt Roberts on OKRs and Kanban that brings the two together.


With a degree of confidence, I am going to assume that you know what Objective and Key Results or OKRs are. As a goal-setting framework, it has become a favourite amongst agile engineering teams and becoming mainstream across all types of teams and industries now.

What is sometimes not appreciated is how OKRs are the perfect focal point of Kanban. Where Kanban optimises the execution, OKRs describe the future desirable end-state of the activity and via measurable outcomes.

If you were to take an example Product / Engineering OKR like:

  • Objective: Build a next generation banking application
  • Key Result: Get 200K users to deposit money weekly
  • Key Result:: Get 20% of users to set financial goals

What can sit alongside this is a Kanban where cards can be selected and completed based on their alignment. Progress against the OKR can be discussed at an agreed cadence and work continually optimised.

When working with OKRs and Kanban it is easy to overcomplicate things by arguing that cards link to multiple OKRs, which may sometimes be true. However complicated linking comes with a thought and time overhead and can slow us down. Where possible the “Keep It Simple” approach targeting a Kanban to a single OKR works really well. 

As with any framework, it’s so easy to over-think OKRs. What we want is simply a good measurable outcome for the work being done via sprints, epics etc. to target. A goal to focus productivity and enhance the learning loop/retrospective. 

OKRs and Kanban

Solving the activity based Key Result problem

One of the challenges that those that are new to goal setting and OKRs face is they are able to describe activities easily, but measurable outcomes are harder. What using Kanban and OKRs does is provide a place for work and a place for outcomes. Both being visible, part of conversations and both agile by their nature.

The other benefit of this is learning loops are optimised when an outcome is measured. We did this work, this epic, this sprint and this changed or didn’t as the case might be. If you do work and don’t get to see the outcomes you don’t know if it works and don’t get to learn what works and what doesn’t work.

Making goals and work visible across teams

Of course, having stakeholders from a range of different teams is a great way to focus on delivering customer value. OKRs have transparency as a core pillar in the same way Kanban and other agile ways of working have, so adopting both together makes sense. Not only is execution aligned but goals are as well.

More information, ideas and collaborative decision making

The final thing I’d want to share to reinforce the synergy between OKRs and Kanban is that to set OKRs teams have got to share information about opportunities and challenges, whether they are KPIs that are not where they should be, systems and processes that need to be improved or a project that needs to be delivered. 

From this pool of information, conversations about what should be focused on and what should be left on the backlog can happen. After which the conversations can continue to align execution. OKRs and agile working can, should and need to synchronise. The best ideas and the most important and valuable work will be done as a result.