The 7th deadly sins in the use of the Kanban Strategy - part 3 of 3
Jose Coignard
ProKanban Trainer | Org Topologies Certified Pratictionner Agile Product Management Coach @ Caisse des Dép?ts
This article will dive into 2 new sins, the 2 last one actually, that you absolutely want to avoid so your Kanban strategy really optimize your flow.
You can recover the first 2 parts here in my first article on the subject :
and in my second article :
So let's dive into the 6th deadly sin ...
6) Over-optimism
You've certainly been confronted with unrealistic demands, like a project with an imposed scope, cost and deadline, while maintaining impeccable quality.
You cannot have your cake and eat it.
It can't work, and it's known as the golden triangle of project management.
In the Kanban strategy, there's a similar challenge with three crucial parameters :
If someone tells you that it's possible to maximize all three parameters simultaneously, they're either lying to you or being far too optimistic.
And they will have fallen into what I consider the 6th deadly sin: over-optimism.
To illustrate that maximizing all 3 parameters is beyond human ability, I'll give you a few brief examples:
?? Among firefighters (thanks for all they do! often not far from superhuman things): ????????Maximizing efficiency would mean having all firefighters on duty all the time. But in an emergency, you want firefighters available at the firehouse, ready to respond immediately (efficiency and predictability), even if it means having them idle at some point.
?? In order to optimize efficiency in hospitals, it would be conceivable to reduce the number of beds, doctors, nurses, etc., so as to have only what is necessary to accommodate, in general, patients : ????????Except that, the hospital would run the risk of not being able to accommodate a patient in need at the right time, with the right skills and equipment (effectiveness), or within a fairly precise forecast timeframe (predictability) that would not lead to complications.
?? In digital product development: ???? ???? Pushing developers to produce non-stop to maximize the use of their time, on the assumption that this will maximize efficiency, can lead to features unwanted by customers. This undermines effectiveness and the real value of the product
?? In logistics: ???? To ensure predictable delivery, a logistics company may choose not to fully fill its trucks, trains, planes, before sending them off, in order to best meet delivery deadlines. This practice ensures high predictability and effectiveness, but reduces efficiency (under-utilization of transport capacity).
The key will be to find the right balance ? in your context. Don't fall into over-optimism by thinking and forcing for everything to be maximized simultaneously.
You risk under-optimizing your system overall.
7) Siloing
I often see teams defining their workflow in ways that create silos.
They list all the activities that need to be done on a value item, then group these activities together and create stages where those activities serve as exit criteria (among other policies).
We have a discovery stage, then a solution implementation stage, followed by a testing stage, a release stage, and hopefully, a validation stage (where the change in customer behavior is confirmed).
Great... or maybe not.
Many approach this with a waterfall mindset, falling into the 7th deadly sin: Siloing.
Kanban is not an invitation to revert (or remain) in a waterfall approach. On the contrary, it’s an invitation to optimize the FLOW of value.
A proper way to optimize the flow of value is to have an item (of potential value) move through the entire process as quickly as possible, consuming the least resources along the way.
So, collaboration is key! Why wait to work on activities from the testing stage when you could already start even if you're still in the implementation stage? What about TDD and advanced collaboration techniques (swarming, mobing) ? What about dual-track agile ?
Even if you’ve defined a workflow with these kinds of stages and corresponding exit criteria, whenever possible, it's (often) better to start working on downstream activities rather than starting a new item. Doing so will help you control your WIP and should speed up the overall flow of value as well as getting more predictability.
A simple workflow like To Do > Doing > Done is valid. But when you break down "Doing" to collect useful data that could help identify constraints and optimize the flow of value, avoid creating or reinforcing silos. Instead, take the opportunity to establish policies around your workflow, such as:
- If we can work on downstream activities for an item in progress, we will prefer this as starting new items (in most cases).
- If we can’t work on downstream activities for an item in progress, we will check to ensure we won’t violate any of Little's Law assumptions by starting something new.
- No stage is "owned" by any specific team member(s); we can all contribute at any stages (within the limits of our competencies).
- We will use any idle time to improve our skills, so we can contribute to activities we’re currently less comfortable with.
Conclusion
That close that series on the 7th deadly sins in the use of the Kanban strategy.
I don't pretend to have covered all, actually I should have gone to a 8th deadly sins, which would be to pretend that there is only 7th deadly sins.
I am pretty sure that there are more, but that was the first 7 that came to my mind and that I wanted to share with you.
Hope you enjoyed to read those 3 articles and that you have learned some stuff.
Feel free to reach to me if you want to continue your learning journey, for example by coming to one of my public classes or if you want to create a private session in your company.