I believe Kanban and REAL DevOps are a match made in heaven. I really do. I know I’m not the only one. Leading into Agile India 2015 InfoQ interviewed me about this. This was also one of the main themes of my talk in the conference and the DevOps Flow workshop I gave before the conference. (Contact me if you’re interested to hear about the next opportunity to participate in such a workshop).
While we’re waiting for the video from my talk to be processed, here’s a trailer…
And an older variant of this talk from DevOpsDays Israel:
One of the repeating themes in my work the last couple of years is applying Kanban thinking towards running your change initiative. I talked about this at Lean Kanban France 2014 and the video is now up on infoq. In addition Ben Linders and I had a chat about it which is also available on infoq.
I frequently get contacted by people who like Kanban in general but are worried that it might not be a good fit for their context. In some cases the concern is legit but in many others it is just a result of basic misunderstanding of Kanban. We need to figure out why this happens so often but in the meantime here is a short FAQ:
Q: Is Kanban just for ongoing maintenance or also complex product development?
A: Short answer – No. Kanban is applicable in complex product development as well as most other knowledge work contexts.
Longer answer – This myth/misconception is based both on the roots of kanban in the IT world as well as the fact that early on kanban was quite popular in teams that did ongoing maintenance/support where scrum sprint-based planning wasn’t a good fit. It was so popular that a lot of people made the association that kanban should be limited to this use case. (Scrum people who tried to protect their turf didn’t mind so much and probably helped this misconception propagate). As a coach actually most of the teams/organizations I work with use Kanban for complex enterprise-level product development involving SW and sometimes even embedded/HW development.
Q: We heard estimates are not used in Kanban? How is it possible to plan and predict then? (also asked as “We heard it is forbidden to estimate in Kanban?”)
A: Short answer – you can use estimates with Kanban and many teams do that.
Longer answer – Actually Kanban says to start with what you’re currently doing and evolve over time so many teams/organizations continue with their legacy estimation approaches initially. The source of this legitimate question is the understanding in the kanban community that estimates only reflect the work part of the overall delivery time and don’t take into account the delay/queuing time which we learned has a major impact on the overall delivery time. When using SLA-based predictability approaches therefore an accurate effort estimate is not that useful. It is sufficient to ensure the work going into the system is granular. the exact size is not that important.
Having said that, Many kanban teams/programs use a more classic bigger-batch planning approach like “Agile Release Planning” and in those cases some sort of estimate is useful in order to have a prediction of the Time/Scope/Capacity required to deliver the Release/Project. These teams typically use classic agile estimation approaches like Story Points, Ideal Days etc.
Q: How do we deal with dependencies in Kanban?
A: The answer is not Kanban-specific but more of a “Feature Driven Development” question. The answer is that when moving to a Feature-driven-development approach using good independent stories/features most dependencies go into the specific cards themselves. The remaining dependencies are typically “This story must be finished before that one” and reflecting those cases in the priority order can be enough. Some teams block cards that are dependent to give better visibility to the situation. And some tools even provide a dependency mapping capability. I have to admit though that while I hear this question often from people coming over from the waterfall task-based gantt-based world, once they go into feature-driven/story-driven world most of them just understand they don’t need anything special.
Q: Are same sized stories really a must in Kanban?
A: Short answer: NO.
Longer answer: Kanban actually lives quite well with variable-sized work items. Most teams I worked with have not reached the nirvana where their stories are the same size and even those teams that have are working on features that vary in size. Kanban cares more about making sure the work is granular so it can flow effectively than having same-sized work items. The main advantage of same-sized work items is that it simplifies prediction, analytics etc. But most tools and teams deal fine with variability in the work size by taking size into account when making their prediction (e.g. in their CFD) or their analytics (e.g. in a size-based cycle time control chart)
A concern that comes up frequently when you start talking about applying a WIP limit is:
“So, what I understand from you is that at some point you will block incoming work requests if the WIP limit is reached, yes? Well, we cannot do that. We cannot tell people we will not work on their items. That will not fly around here”.
In my view both the waiting hall and the treatment area are WIP since they both affect the overall service time.
You can apply a limit in at least two ways. The first can be to apply a limit to the overall WIP. Once this limit is reached you will indeed turn away patients. Fans of ER themed TV series will recall episodes where the ER closes shop and turns ambulances and walk-ins to other hospitals. This happens very infrequently though. Their WIP is set to a high level and it is understood that the waiting area might have a very high occupancy leading to very long service times before the situation is so dire that you start blocking people. (A client that attended Don’s workshop with me commented that you might want to invest in stronger security if this happens often as it typically leads to some violence towards staff…)
The second way is to limit “Treatments in Process” to make sure that once patients are in treatment they go through as fast as possible and staff don’t multi-task too much and the treatment area is not too crowded. You will notice this style of WIP limit DOESN’T turn away patients. It accepts them and queues them. Yes the service time might be high if there is a long waiting queue but you will still be serviced. I don’t know what ERs actually do since my personal experience with them is quite limited but I think they either explicitly or implicitly do a mix of both.
To return to our knowledge work environment I advocate using this approach as well.
Yes you should have some WIP limit on your incoming queue. That WIP limit might be high if you want to minimize blocking and prefer to provide long service times. That is probably what the evolutionary resistance-minimizing approach would be.
More importantly I would start with a limit on the actual work in processing. This will achieve a more sustainable and effective processing both for the work as well as for the people doing it. This will also have the effect of reducing the average waiting times and overall service level of your system.
Now, in your environment you might also have a better chance of shaping demand and occasionally blocking work in a way that is acceptable to your clients. But that is a higher maturity level of Kanban. (Klaus would call it a higher flight level) Don’t give up on starting with WIP limits just because you cannot do it early on in your journey or if you think you will not be able to do it even later on.
I recently pointed a customer to a discussion around motivation when using Kanban compared to Scrum and other timebox-driven approaches. This blog post is a slightly edited version of my comments on that discussion, since I find myself getting into similar discussions quite frequently.
The question/context originally posed by Victor on kanbandev was: “We kind of dropped our previous Scrum process (or rather we decided to pay less attention to it because it was becoming less relevant once Kanban was in the picture. But one thing good about Scrum was that developers knew their story was due in 2 weeks so they paced themselves. With our Kanban system their isn’t an end date, so that motivator is gone. Can anyone suggest a replacement or remedy (other than Scrum, I really don’t want to go back)”
Here is my original response more or less verbatim:
When I was starting to advocate Kanban at AgileSparks, we were mostly a group of hard core scrum coaches/trainers, so we saw the sprint deadline and commitment as THE way to ensure high energies and self-organization within constraints and get rid of Parkinson’s law (work fits the container it is given). Over time, we saw that it is A way, and not necessary always the BEST way (due to the reasons quoted below, also see http://yuvalyeretblog.wpengine.com/2011/10/13/scrum-sprint-commitment-rant/)
What we saw through experience with different client environments were that there were some alternative ways:
A frequent delivery cadence on its own is typically enough to drive the right level of energies, even without a commitment to finish everything based on a sprint commitment. You can see this described in the FiftyOne.com case study in the Beyond Agile book.
A frequent DEMO cadence can be enough as well, believe it or not! not even delivery… It is sometimes enough to create too much pressure and technical debt, even WITHOUT any commitment to finish a certain package of work. People are motivated to show they are done if there is some opportunity to show and boast it.
Continuous Delivery seems to be even a higher motivator. I’m not working with enough people doing this, but those that do report a kind of rush that creates great motivation to complete things just to see how they perform in real life…
Working with small units of value (e.g. Stories), Visualizing and managing flow is many times enough. But only if not, you can consider visualizing and managing “lagging/stale” cards more explicitly. I like for example the “Zombie Cycle Time” approach and talk about it and some of the other issues here in my Lean Kanban Benelux 2011 talk
Purpose – clearly understood real external reason to deliver on a certain time. Whether it is a big deliverable built of many small things – where it is important to see whether you are on track towards that delivery using something like a CFD with release forecasting (trend lines/montecarlo/whatever), or a single value item that has a special delivery requirement. If people are aware of the deadline, realize the cost of delay, and ideally believe in the plan to deliver to that deadline, they will be highly energized.
Since you are coming from a Scrum environment, what seems to work for many teams as a starting point is to keep the cadence only relax the commitment to clear the table as well as to plan ahead exactly what will be the contents of the sprint. This is many times enough. You should look at the actual flow of work and determine whether there is a problem or not.
Regarding talking to the team – I would first try to go to the gemba and see what is going on, before bothering the team with it. If there isn’t a problem, even talking to them might create a Hawthorne effect affecting how they work, and not necessarily in a good way. Depends on the team. Only you know…