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.
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.
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!
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.
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!
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.
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.
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.
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.
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.
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.
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
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?
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.
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.
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.
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.
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.
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!
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.Â
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.