In my recent Kanban workshop with Procamban.org, titled “APK: Applying Professional Kanban,” I had the opportunity to delve deep into the strategic underpinnings of DevOps. Over the course of 16 hours, we explored how Kanban serves as a meta-process that can be applied to any existing workflow, regardless of its nature. Whether your team is using Scrum, a homegrown process, or even something like SSADM, Kanban provides a framework to observe and enhance your current practices.
Understanding Kanban as a Strategy
At its core, Kanban is about monitoring the flow of work through your system. This means you can effectively track how ideas transition from conception to production, ultimately delivering value to your customers. Here are some key takeaways from my experience:
Universal Applicability: Kanban can model any system, allowing you to observe and record processes at various levels. For instance, a team might focus on the cycle time from when a product owner hands over a feature to when it reaches the operations team. Conversely, an organisation might look at the overall throughput of multiple teams.
Optimising Flow: By monitoring the flow of work, you can make informed tweaks to your processes. This is crucial for improving delivery speed and ensuring that value flows smoothly through your system.
Avoiding the Death Spiral: In professional services, it’s easy to fall into a trap where an increase in gigs necessitates hiring more people, which can lead to a decline in quality. Kanban helps you manage this by providing visibility into your capacity and workload.
The Power of Data Analysis
One of the most exciting aspects of applying Kanban is the ability to leverage data for continuous improvement. By analysing historical data, you can forecast future performance with a degree of probability. This is akin to how meteorologists predict the weather. They use complex models and historical data to simulate outcomes, providing a percentage likelihood of events occurring.
Probabilistic Forecasting: Imagine being able to say, “Based on our past performance, there’s an 85% chance we’ll deliver this work in six days or less.” This kind of insight transforms conversations with stakeholders from mere speculation to informed discussions about likelihoods and outcomes.
Monte Carlo Simulations: To achieve this, we often employ Monte Carlo simulations. By running thousands of simulations based on historical data, we can assess the probability of delivering a certain number of items in the next sprint. This allows for more realistic planning and expectation management.
Engaging with Stakeholders
The shift from deterministic to probabilistic thinking is a game-changer in how we communicate with stakeholders. Instead of making absolute promises, we can discuss the likelihood of various outcomes. This not only sets realistic expectations but also fosters a culture of transparency and trust.
- Communicating Probabilities: It’s essential to convey that while we can be highly confident in our forecasts, we can never reach 100% certainty. This understanding is crucial for effective stakeholder engagement and helps teams navigate the inherent uncertainties of software development.
Conclusion
The “APK: Applying Professional Kanban” workshop reinforced my belief in the power of Kanban as a strategic tool for enhancing workflows across various systems. Whether you’re a team aiming to improve engineering excellence or a leadership group overseeing multiple projects, Kanban provides the insights needed to optimise your processes and deliver value more effectively.
If you’re interested in exploring how Kanban can transform your organisation, I encourage you to reach out. Let’s have a chat over coffee—book a session with me through Naked Agility. Your journey towards improved agility and efficiency starts with understanding your processes, and I’m here to help you every step of the way.
So, uh, the Kanban workshop is from uh procamban.org. It’s called the APK applying professional Kanban. Um, and it’s, uh, really it’s 16 hours of a deep exploration of the strategy that is DevOps.
So there are other things out there that are actual software processes, right? Um, but the core of Kanban is this strategy that allows you to, um, or meta process that allows you to monitor any existing process. Doesn’t matter what it is, right? Your existing process could be Scrum, your existing process could be we’ve made it up as we go along, or your existing process could be, uh, Maurice or SSADM or whatever thing your organisation’s doing.
The Kanban strategy would allow you to observe and record what’s going on in that process. You’re effectively monitoring the flow of work through that system. Thus, then you’re looking at the data, right, enabling you, uh, to continually make tweaks and changes to the system in order to optimise that flow of value, right? So that’s, that’s, that’s really about that delivery piece. How quickly are we able to take an idea that we get and get it all the way into, or all the way into production potentially so that our customers can use it?
But it will model any system. I think that’s the key piece for me, um, is that it models any system and any part of any system, right? So even if you had a team that’s just looking at, you know, their view or their area of control is, uh, from when the product owner gives them a feature of the business, gives them a feature to, to, to when they’ve sent it off to the operations team, right? That could be one view. So you’re looking at the cycle time across these two points, doing the report item aging, controlling your whip in it at that level.
But your business could be looking at a much higher level, right? Instead of individual pieces of value that a team’s working on going through the system, your business could look at all of the endeavours that are underway and what is there from when they come up to it, from when it’s actually delivered and what is their throughput, what is their cycle time, what’s their current whip, what’s the capability of the organisation?
And this is especially true in things like professional services, right, where you get gigs coming through and you’re trying to service them with the people that you’ve got. And you don’t want to end up in that death spiral of, you know, we’ve got more people so we need more gigs, and then we’ve got more gigs so we need more people, and you end up in a spiral of reduction in quality because you’ve got to hire people because you need them, not because they’re the right people to hire.
Um, and that’s true for big organisations as well. So, this allows you to model the flow of value through any two points, um, and really improve the way you work because you’re able to monitor what’s going on. And that’s, that’s what the APK applying professional Kanban is all about.
So whether you’re a team, right, and you’re looking to improve your engineering excellence and shorten the cycle time, get value through your system quicker, or you’re doing Scrum, you want to improve throughput in your system, or you’re a leadership team and you’re looking at the work that’s underway across multiple teams, it really doesn’t matter what the system is. This is the tool that you need, uh, to monitor the data analysis that you need to monitor not just the flow of value through the system, but then look forward into the future and do probabilistic forecasting on what’s coming up next.
How long do we think things are going to take and how likely is that to happen, right? If we’re thinking in bets and really looking at the data from what we’ve delivered in the past, if we have a stable system, right? You need a stable system first, then we can start looking out into the future using effectively some of the same tools that when you see them talking about the weather on TV, right?
Um, there they say that on Thursday at three o’clock it’s going to rain, right? That’s their prediction, and then it’ll have a percentage likelihood of that to happen. And let’s say it’s 85% sure that’s going to happen. What they’ve done, and for them it’s much more complicated than what we were talking about, much more complicated. They’ve got these really complex models that model the weather in whatever area you’re in, right?
And they feed the data from all of history that they’ve got, plus what’s currently happening in the weather, and they feed it into this model, and then they run the simulation thousands and thousands and thousands of times. And what percentage of those simulations does it rain at three o’clock on Thursday? Well, 68% of the simulations it rains at three o’clock on Thursday. Well, it might rain at three o’clock on Thursday, right? It’s 65%. If that’s the number of simulations, 65% sure it will rain at three o’clock on Thursday.
And that’s the same thing that we can do with our engineering processes, right? We can look at, um, what are historical delivery, um, on average, for example, um, 85% of the time, that’s on average, that’s the wrong Edward, but 85% of the time, uh, we deliver work in our team, uh, let’s say six days or less. So I’m 85% sure that any piece of work we take on will be delivered in eight days or less, right?
So we can make that a forecast looking into the future and put it into a simulation. And for that, we normally use a Monte Carlo. Feed some data in, run it 10,000 times. What’s the chances of you delivering 10 things in the next Sprint, 20 things, 30 things? What’s the percentage likelihood that’s going to happen? And then you can have real conversations with your stakeholders, not about what you will and what you won’t do, but what is the likelihood of certain outcomes happening.
With the clear understanding that there is also, no matter how, um, high in the percentiles you go, right, you never get to a hundred percent. You can get to the 99th percentile, right? But you can never get to 100. So there’s always a chance that something wouldn’t happen, and that’s a key learning outcome for engaging with stakeholders, for the stakeholders and the teams communicating with them that we want to be talking in percentages. We want to be talking about probabilities, um, with our stakeholders for whatever it is we’re doing. How likely are things to be successful, just like businesses have always done?
Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else Agile, Scrum, or DevOps, then please book a coffee with me through Naked Agility.
