I’m often so focused on trying to do things right, that it feels like I’m driving a car at 200 km/h. Sure, things go fast and I’m really paying attention to the road ahead, but I’m missing out on all the landscapes and events next to the road.
You see this happening in a lot of Agile & Kanban adoptions. Enthusiastic people drive change and try to set up a new way of delivering software, based on the so-called new ‘best practices’. Short feedback cycles, adaptive planning, close communication, built-in quality, … are introduced and tuned to perfection. Teams are focused to learn and get accustomed to the new process.
This focus prevents them from seeing the whole picture.
Why are they adopting Agile or Kanban?
Well, in most cases, because IT projects have a horrible track record when it comes to delivering on time and within budget. And at this moment, Agile methods offer a better chance of successfully delivery. Sadly, projects are not delivered on their own island. They are part of a bigger system, which can be a department, a network or an organisation. Within that bigger structure, there are rules too. Rules we tend to feel late in the project’s life-cycle.
This is why I’m such a big believer of minimizing work in progress through a flow system. The sooner we go from customer demand to delivery, the sooner we get valuable information of the interaction points with the rest of the organization. At that moment we will experience the Theory of Constraints hands-on! Where does the work queue? What is the bottleneck? Why do we experience a hick-up in the flow?
Finding these organisational bottlenecks early is extremely important! The later you spot them, the more dramatic the consequences. Let’s look at a common example:
The Scrum project team has been quite succesful.
They managed to plan and deliver iteratively without much variation and grew in efficiency at a steady pace.
Each iteration, they delivered working software on a staging environment and showed it to their stakeholders and power-users.
After 16 iterations, the team prepared a production release which was sent to the operations department.
Everybody was excited about the new application that would be delivered within time to the end users.
But, unfortunately, the release did not conform all the production requirements of the operations department.
They had to change some files and get back in line for an installation in production, which came down to 4 weeks extra.
In this example, the handover between development and operations was the first bottleneck.
Many Agile teams work in a semi-isolated environment. They are creating a new product, from scratch, with the latest tools. The constraints they run into are mostly lying in these domains:
- Collaboration with product management
- Acceptance and installation in production
Most other constraints are within their own power.
In most Agile projects I’ve been part of, we were able to bypass these constraints by putting enormous amounts of effort into them. But what happens after your first release is in production? In many cases, teams switch to a continuous flow model. Because defects need to be fixed, extra features need to be released, usability has to be perfected,…
If you’re into lean product development, you first release will be fast, with limited features. Minimize the cost to the amount necessary to get quick feedback from the market.
The next months you will hit the same constraints again, but only this time you will hit them harder. While we were able to compensate them at first, by putting in the extra effort, it gets a lot harder when having to do this continuously.
These are the times when the new process gets questioned, when it gets tempting to let things slip and revert to the old ways of working. When instead, the journey has only just begun!
I find it extremely helpful to keep the theory of constraints in mind when evaluating your Agile or Kanban adoption.