As a change agent, you constantly need to reassure people that the path we follow is worthwhile traveling. This need is often expressed in the form of critique and difficult questions. When I coach Agile teams, this is often the case. The same thing happens when introducing Kanban. However, I noticed that Kanban raises much harder questions on a management and leadership level, once people are introduced to the basics and start to explore the subject on their own. For instance: “How can we plan if we measure instead of estimate?”
The type of questions Kanban raises, seem to be hard to answer without lapsing into an hour-long discussion. I guess this is normal because Kanban is much less prescriptive than Scrum, for instance. In order to provide reassurance, as a coach, you need to trace the questions all the way back to the principles of Kanban, which are grounded in Lean thinking.
That’s why I wrote a free e-book that lists the 5 most common arguments against Kanban and my response to them.
It will take longer
One popular argument against Kanban is that it will take longer to create the product. This reasoning is deeply entrenched in our everyday life. It is related to our education and how businesses have been managed for centuries. We’ve seen that Kanban focuses on using real data to make decisions. By measuring flow we manage our people and product.
This is completely opposite to what we’re used to. Managers have learned to control their workers by assigning work and monitoring their performance. You get a task and get it finished on time or you have to justify why you didn’t make it on time. The same approach is taught in schools. Students get an assignment with a deadline, which needs to be finished on time or they’ll feel the consequences through punishment in the form of lower grades. How many times did you get an assignment without a deadline? “This is what I’d like you to do, don’t worry about the timing, we’ll measure afterwards.”
Let's find out how Kanban uses measurements as a core management tool without losing focus.
Parkinson’s law
“The amount of time which one has to perform a task is the amount of time it will take to complete the task.”
Many people act by this simple definition. If we don’t set any deadlines, a worker will take much more time to complete the task. He will relax and start working whenever he feels like it. Time is money, so we can’t allow this, right?
It has been done like this for decades in the world of project management. A project plan is created by the project manager and senior developer. Based on estimates, a schedule and timing is created which becomes the target for a development team, whether realistic or not. The reasoning is quite simple, the team needs a deadline to keep focused. The project manager will add some buffer in his own plan, just in case the team doesn’t make it. But then at least they will make it for 90 percent. Without this focus they might not even reach 50 percent...
Simply from a cost perspective, this is a good approach. From a value perspective, this is a bad approach. Because what happens when people get stressed? They cut corners, try to do more in less time and introduce malfunctions by sloppy work.
From an HR perspective this is also a bad approach. People get overworked, stressed out and leave the company if the external pressure is too high.
You realize that there needs to be a balance between freedom and control. A first step in project management was to include the team in estimating the project plan. This gave them a first voice in the management side of the project and resulted in an increase in intrinsic motivation. Later with agile development, a next step was taken by measuring what a team could deliver in an iteration and using those numbers to plan instead of pushing for an initial estimate. This led to a significant increase in value creation and quality.
How does Kanban deal with keeping a healthy focus between control and freedom?
A healthy balance in Kanban
In a Kanban flow, team members pull new features from an ordered input queue. In many cases these features are not estimated up front. At most they are sized on a scale. Measuring flow is the main management tool that is used to control efficiency. By continuously monitoring lead and cycle time, we get a good idea about the progress of the team. These numbers become a target for each contributor to the flow. If the average cycle time is 5 days at a certain point in time, the team will indirectly focus on this number when starting on a new feature.
The beauty in this approach is that it’s founded on real data, not wishful thinking. If it takes 5 days to deliver a new feature, chances are high that it will take approximately 5 days for another feature. The focus is not created externally by management, but it has evolved from within the team. Therefore they will be more intrinsically motivated to pursue it. People will have to cut less corners and will deliver more valuable and high quality features.
From a management point of view, the style changes from command and control to helping the team to improve. Accepting that the system can deliver a new feature in 5 days is accepting reality. From that point all involved in the Kanban flow can start the process of continuous improvement. Everybody is responsible to think about how we can improve flow, reduce bottlenecks and variation. Soon your average lead & cycle times will change, along with the focus of the team. Their new focus will be a realistic one since it is based on real measurements on an improved flow.
I found it very useful to keep the theory of constraints in mind when trying to improve your Kanban flow.
Theory of constraints for process improvement
The theory of constraints (TOC) is a management philosophy introduced by Eliyahu Goldratt in his 1984 book titled “The Goal”. It is based on the idea that “A chain is no stronger than its weakest link”. If we project this to Kanban, this means that the weakest stage in the flow will determine the rate of value creation of the entire system.
For instance, if we notice that the user acceptance testing stage can’t keep up with the preceding stages, it will slow down output of the entire Kanban flow to it’s own capability.
(Click on the image to enlarge it)
/filters:no_upscale()/articles/kanban-for-skeptics/en/resources/fig1large.jpg)
By visualizing work on a Kanban board, the TOC will become visible in the form of bottlenecks that block the system. During the course of their work the team will also feel the TOC trough the use of Work In Progress (WIP) limits. These are numbers set at each stage of the flow, indicating the maximum amount of work items that can be present.
For instance if we’ve decide to start with a WIP limit of 3 on the UAT column, this means that no more features can be started in the preceding stages if the UAT column if full. You can imagine that this can become quite frustrating. Most of us are eager to start a new task, especially when we’re trying to get a release out of the door! People feel uncomfortable doing nothing, because we think it gives a bad impression. We must be busy all the time! It won’t take long before a situation like this is escalated. But that’s a good thing! We want to find bottlenecks as soon as possible.
This is usually the moment when an improvement session is triggered. How can we prevent this from happening again? Are our WIP limits not set accordingly? What is the root cause of this bottleneck, how can we unclog it? This session resembles a retrospective, but with a wider focus. Most retrospectives are held within the development team, with an occasional participation from a product owner. In Kanban, improvement sessions typically include many more different roles of the organization because of the focus on the entire flow, from idea till installation on production. This causes business analysts, system engineers and sometimes even sales people to be included.
The continuous improvement focus of all the different roles from the organization creates a healthy peer pressure and more opportunities to share knowledge. WIP limits will reveal bottlenecks quickly and create momentum to help others and start the continuous improvement cycle. The power of continuous improvement in Kanban will help you improve flow, which will tilt the perception that it will take longer into a feeling of greater efficiency. And you will have the measurements to prove it!
Flow
Kanban is based on the principles of a pull system, pioneered in Lean manufacturing. The goal is to get as close a possible to a single piece flow, where the organization is only working on products that are ordered by a customer. Why is this, and what does this have to do with software development?
The reason we only want to be working on customer requests is because we want to eliminate waste, which are actions that don’t bring any value to the customer. Forget about innovation for a moment, because there's no customer order is triggering the pull system. Working not only on customer requests means you’re guessing what the customer will order in the future, and therefore you are building up inventory, a stock of products waiting to be purchased. This is waste because of two reasons. It is capital spent on items that are not bringing in revenue and therefore costing us money. Also, these items contain a big risk of not being sold or not complying to customer’s wishes, leading to costing us money. In software development the same issues apply. Features waiting months to be released are costing money and contain a risk.
WIP limits reduce inventory and create a pull system upstream. If you have finished a task, you pull a new one from the preceding stage, freeing up capacity there, giving an opportunity for the preceding stage to pull on its own. This keeps going all the way up to the input queue.
(Click on the image to enlarge it)
/filters:no_upscale()/articles/kanban-for-skeptics/en/resources/fig2large.jpg)
The most common critique on WIP limits is that it will cause a drop in efficiency. Off course, people will be idle once in a while because of WIP limits that are reached. What would happen if they would ignore the WIP limits? The organization would gradually start building up inventory, more than the flow can handle. People can't be 100% busy. The perception that they should can be traced all the way back to the start of industrial times when factories started to grow and expensive machines were introduced to increase capacity. Off course these machines were so expensive that they had to run continuously in order to keep the unit cost low. This led to large unevenness in the production line and a growth of inventories. In those times, a product was not customized to the user, so the risk of not complying to it’s wishes was none existing simply because they had no choice. The company just had to make sure they sold the inventory. Today, for many organizations products are customized by the end users, causing inventory to be a major risk. This applies for IT as well, since the majority of systems are customized for a client, a customer segment, …
One continuous sprint
Kanban being a continuous flow leads to the perception that teams get no more chance to pause and reflect. It is a never-ending sprint where team members are pushed to deliver faster and faster. As we all know, a sustainable pace is important for the quality of the end product and the health of the team. Some slack is needed to get your senses together or reflect on the future of the product, which allows the team to take better decisions during the course of delivery.
Measuring flow makes it easy to fall into the trap of micromanagement. Pushing the team to work harder, feature by feature. This is where a coach has an important role to play. He must help all team members to understand that in order to go faster, they must take the time to reflect on the process, not on the speed of development. Kanban focuses on the end-to-end flow. Pushing one step in the flow to go faster will often cause problems for the rest of the flow in the form of defects, bottlenecks and swift decisions. This is again the Theory of Constraints, which tells us that problems will appear downstream if we push one step in the process to go faster.
A new Kanban team starts with their current efficiency and continuously inspects its collaboration in order to perform. Not by working faster, but by optimizing the flow. This makes it easier to guarantee a continuous flow, since we all agree that the system is more important than the individual, and we can achieve more by improving together.
Summary
It is a strange idea that by measuring flow instead of setting deadlines, work will be done efficiently. Kanban creates awareness on the importance of every phase in the process. Instead of pushing each individual phase to go faster, we optimize the whole. Again, because this is what matters to the end users. They don’t care how well our developers are meeting their deadlines, they need the order to be delivered. As soon as the process is under control, the team can start trying to improve their efficiency. Not locally, but end to end. Not by pushing individuals to work harder, but by reducing bottlenecks and optimizing the flow. The circumstances in which people work are tuned to better suit everyone's needs. A sustainable pace for the employees, a reliable relationship for the client and a profitable business for the owners.
Free e-book
You can read about the other 4 arguments against Kanban by downloading the e-book for free at leanpub.com/kanbanforskeptics and automatically get next versions in the future.
About the Author
Nick Oostvogels is an independent Belgian consultant who has worked at different companies in various industries. He helps organizations to deliver successful projects in whatever role necessary, often as a project manager or coach. He is a proud father of a daughter and twin boys, and enjoys outdoor sports such as mountain bike, running, soccer and drinking a Duvel afterwards. Nick is a regular blogger at skycoach.be and enjoys speaking and learning at conferences.
Community comments
One continuous sprint
by Leonardo Campos,
Is software development really just assembly and supply chain?
by David Marsh,
Re: Is software development really just assembly and supply chain?
by David Marsh,
Re: Is software development really just assembly and supply chain?
by Nick Oostvogels,
Re: Is software development really just assembly and supply chain?
by David Marsh,
Re: Is software development really just assembly and supply chain?
by David Marsh,
Re: Is software development really just assembly and supply chain?
by Nick Oostvogels,
Re: Is software development really just assembly and supply chain?
by Anna Majowska,
Re: Is software development really just assembly and supply chain?
by Edwin McConnel,
Re: Is software development really just assembly and supply chain?
by David Marsh,
Re: Is software development really just assembly and supply chain?
by David Marsh,
Re: Is software development really just assembly and supply chain?
by Nick Oostvogels,
Learning from Failures and Creating Repeatable Best Practices
by Beth Medina,
One continuous sprint
by Leonardo Campos,
Your message is awaiting moderation. Thank you for participating in the discussion.
Nick, this is a very good piece of work.
I'd just like to add on the subtopic of "One continuous sprint" that in Kanban it is possible and desirable to set Cadences. It means that you don't have a timebox (Sprint), but you can still have cadences in which you set your cerimonies. Let's say, for instance, that the retrospectives are set to happen every two weeks, and an Operations Review every month (or whatever periodicity suits your organization better).
Those working with Agile and about to adopt Kanban shouldn't feel jumpy, Kanban does not change everything overnight.
Is software development really just assembly and supply chain?
by David Marsh,
Your message is awaiting moderation. Thank you for participating in the discussion.
The problem I have with this is that there has been much study of software development for years, and many of the conclusions from different studies and eras seem downright contradictory, not just the management concerns or poor management behaviour you outline.
I believe that software development is not manufacturing / assembly in many cases, it is the entire process from conception, design, prototyping, testing, R&D etc.
If we take a ford car as an example, extensive design and research is undertaken upfront, its just not classed as manufacturing. And in terms of architecture, how complex is a modern car manufacturing plant, how many years does it take to build the factory and program the robots ?
"The reason we only want to be working on customer requests is because we want to eliminate waste, which are actions that don’t bring any value to the customer."
When is 'Big Design' or 'Architecture' acceptable ?
If at all in such a system ? If we are concerned with the minutiae of a task will we miss the big picture ?
Some of the best innovations in software development come from developers scratching their own itches, and 'Necessity is the mother of invention', how does this happen if developers are prohibited from doing this ?
If we believe that software development is just assembly, how do we pick our parts ? This comes back to architecture, we are making architectural and design decisions even by the frameworks, languages, middleware and tools we choose. Often these choices are largely traditional, like we will use Java and an RDBMS be cause we always have.
Some projects that succeed are the ones that seemingly make more radical choices from a technology standpoint. How does this fit with the blindly completing simple customer requests model ?
Re: Is software development really just assembly and supply chain?
by David Marsh,
Your message is awaiting moderation. Thank you for participating in the discussion.
Basically what I have seen in my career is three phases :-
1. Software is cabinet making, undertaken by artisans meticulously crafting stuff in small groups.
2. Software is bridge building, undertaken by larger teams of engineers working to a strict plan and process.
3. Software is manufacturing, undertaken by small-medium sized teams, consuming and assembling parts, tweaking and optimising the process and minimising waste.
In each case the analogies and resulting practices have largely been found wanting, they had some benefits but also many disadvantages.
Re: Is software development really just assembly and supply chain?
by Nick Oostvogels,
Your message is awaiting moderation. Thank you for participating in the discussion.
David,
Only working on a customer request, can be percieved in many ways. For instance:
For a live system, these would typically be feature requests, enhancements and bugfixes.
For a system in development, these would typically be features that are 'ordered' by your stakeholders.
Frankly, the concept remains the same. The customer request enters the flow at some point in time, where it needs to go through different stages, respecting the WIP limits, before it can be delivered to the customer. Of course you can't just blindly jump in and some preparation needs to be done upfront. But only when it is linked to a need (aka customer request). And even then you can argue that a minimal design can be sufficient to start with.
Either way, my point in this article was not to claim that software development is similar to manufacturing, but that the lean ideas that originated there, are extremely relevant to our trade.
How many teams are spending years of their time building stuff nobody is waiting for?
Re: Is software development really just assembly and supply chain?
by David Marsh,
Your message is awaiting moderation. Thank you for participating in the discussion.
My points are that there still seem many nuances to software development and Agile Practices don't directly address them any more than any previous methodology.
When if ever is it ok for a developer to encourage altering of requiremnts, generate new requirements, add design features or initiate a project ?
How do we get to stuff like the google personal projects, EC2 and countless other largely developer started initiatives...
There are also many teams building stuff nobody is waiting for but a company representative asked for, in fact I would say this is a far bigger problem ;)
Re: Is software development really just assembly and supply chain?
by David Marsh,
Your message is awaiting moderation. Thank you for participating in the discussion.
"Either way, my point in this article was not to claim that software development is similar to manufacturing, but that the lean ideas that originated there, are extremely relevant to our trade."
How can we possibly know this ? If there is no correlation between the two systems and the way the systems function ?
The best software developers are much closer to engineers, inventors and scientists than factory workers. And the processes of R&D departments, which most likely do not involve Kanban, as R&D departments are not always 'production systems' in the sense of a factory floor.
Process improvement is important, but the type of process improvement you need in say a highly creative design department and at a coffee shop might be different.
Re: Is software development really just assembly and supply chain?
by Nick Oostvogels,
Your message is awaiting moderation. Thank you for participating in the discussion.
"How can we possibly know this ? If there is no correlation between the two systems and the way the systems function ?"
Off course I can't provide any evidence since I'm not a researcher, I can only speak from my own experience.
If I take just one aspect, limit WIP, this has significantly increased the success rate of my projects. Some benefits I've experienced are:
1. It makes a project easier to overview and manage (both from a management & team perspective)
2. It reduces the amount of half finished tasks and therefore makes it easier to release.
3. It forces everybody to constantly monitor and review the 'todo pile'
4. As a project responsible, it allowed me to get an realistic status update at any time.
5. It enables the team to get feedback on a regular basis.
... and many more
If I think about it, it feels like I found a new argument against Kanban: "Software development is not manufacturing" :-)
I will write down my thoughts about this one in a new article soon, so we can discuss further. Thanks for sharing!
Learning from Failures and Creating Repeatable Best Practices
by Beth Medina,
Your message is awaiting moderation. Thank you for participating in the discussion.
If you have good repeatable processes that you continuously monitor and improve upon, you are building upon your successes and learning from your mistakes. This would seem to be a recipe for success regardless of whether you are a developer or cabinet maker so I don't see a disconnect with using a process that started in manufacturing.
I found a white paper (www.netobjectives.com/files/resources/articles/...) that has, on page 7, some bullet points for how you know you are successfully doing Kanban. Turns out that I led a development team that met all these measures of success without using Kanban. Our work was visible; we addressed bottlenecks and had collaborative continuous process improvement. It took us a number of years to achieve without Kanban. I hope to find that Kanban provides a foundation to get there faster as I recently changed companies and am in the process of implementing Kanban with my new team.
Re: Is software development really just assembly and supply chain?
by Edwin McConnel,
Your message is awaiting moderation. Thank you for participating in the discussion.
One thing to keep in mind is that whatever workflow you create is always malleable. If you are starting from square one on a project, then you'll come up with some baseline workflow to support the production of some set of features (there are features/outcomes desired for the project, else why would you be starting it in the first place?)
Typically the first couple of features will take longer to deliver, because of all the R&D that may be required. But over time the workflow will change shape and the inefficiencies will distribute away from R&D to the other stages in the workflow.
So, to state another way, the workflow for any project is not static but dynamic, and there is a beginning, middle and end (as with all things), with varying characteristics throughout.
Re: Is software development really just assembly and supply chain?
by David Marsh,
Your message is awaiting moderation. Thank you for participating in the discussion.
Im well aware of the dynamic nature, it was obvious even in waterfall and iterative days that projects ramp-up and ramp down and go through various phases.
Beth, you miss my point, continuous improvement may apply to repeatable processes or tasks, but kanban as described is more about that because it allows the business stakeholder alone to define 'waste' etc.
If we are doing something truly unique or innovative are we really so sure what 'waste' is ?
When they discovered penicillin was it waste ? It wasn't part of the official process.
When executives go to meetings they aren't generally defined as 'waste'.
If doing science, R&R or a creative process, you may have some underlying principles, like the scientific method etc, but in order to do something new you maybe need more freeform processes ?
Also can short sprints also encourage a type of myopia ?
These are my thoughts, my understanding is Kanban was developed as a simple system to iron out supply chain inefficiencies in manufacturing. That is not to say it has no other uses, but after seeing many processes each hailed as the next 'silver bullet', I'm somewhat skeptical that a 'process' is the answer. I think the real answer is skilled, experienced individuals thinking about the problems and working to resolve them.
Re: Is software development really just assembly and supply chain?
by David Marsh,
Your message is awaiting moderation. Thank you for participating in the discussion.
I the Kanban system is so good and universally applicable, then we should see it various forms at NASA, Big Pharma labs, Advertising Agencies, Civil Engineering / Architect firms, Electronics R&D etc.
An experienced manager on this very forum described getting burnt by his naive adoption of agile to a project requiring programme management on a fixed price contract. Clearly there are drivers to when certain practices make more sense than others and we should identify them.
I guess you could argue that kanbans core is a 'meta process' so avoids many of these issues, but I'm not convinced.
Re: Is software development really just assembly and supply chain?
by Nick Oostvogels,
Your message is awaiting moderation. Thank you for participating in the discussion.
David, Beth,
I wrote a blogpost about this, sharing my view on the argument 'Software development is not manufacturing'.
skycoach.be/2012/10/01/software-development-is-...
Feel free to comment!
Re: Is software development really just assembly and supply chain?
by Anna Majowska,
Your message is awaiting moderation. Thank you for participating in the discussion.
Nick,
I completely agree with this. Although there's not much similarity between product manufacturing and software development, this is not a reason to dismiss Kanban as a valid method for developing software. As nicely said in this article: kanbantool.com/blog/problems-with-kanban, all it asks from the developers is to keep the process as closely resembling their process as possible. If this is done, and the board is regularly checked for any possible improvements, adding extra stages, whatever that is needed to make it present the real process - it will definitely work.
It simply needs a little looking after, that's all.