In a Kanban system you introduce WIP limits at each step of the value flow. This means, that if you get stuck at any one step in the flow and things are not moving forward, then all those who operate in earlier stages of the system enter a holding pattern. If you’re explaining Kanban to managers or executives, this is usually the point that makes them take a sharp turn off of the Lean highway! They mentally write off the whole concept of Kanban because “they don’t want anyone sitting idle.” What skeptics call “sitting idle” is often referred to as slack in the system.
These executives and managers may not realize it, but they are turning their backs on the very thing that could make their company and its products more innovative and stable. If you are working nose-to-the-grindstone 100% of your day on new initiatives then you have no time to think, to reflect. Therefore, you have no time to consider innovations or improvements to your products and services. These developers struggle just to keep your head above water, to survive. They often, if we’re lucky, have lists of things they notice that need to be improved or defects that need to be fixed. Many of those things will never get the attention they need. That doesn’t sound like a recipe for success, does it?
Much like a highway, slack is important to a smoothly-flowing, efficient system. What is the defining trait of a traffic jam? Its bumper-to-bumper cars with nowhere to go. During times of high traffic congestion, do you ever consider that it might be a good idea to put more cars in the road? Of course not. However, development managers often feel like its required to fill any perceived downtime in each developer’s day with a new task to begin. We re-create a traffic jam of new features or other work items. Eventually, the system becomes clogged with many things that are started, but do not finish. We’ve overloaded our development system.
Its very counter-intuitive and its hard to change mental habits that you’ve held for so long. Breaking out of the idea that every spare moment has to be filled with starting something new is a huge hurdle to overcome. I think the problem is that the word “slack” has a negative connotation and that management-think is that if you’re not working on a particular user story (or other logged issue), that you are not making a contribution to the company. Thought its difficult, it is crucial for that mindset to change if you want to support continual improvement.
Your next questions may be “So, if we’re not starting new work, what are we doing? Are we sitting on our thumbs?”. Well, you are absolutely not going to be sitting on your thumbs. There are a variety of ways to fill this time with things beneficial to the company:
Swarm
A key tenet of Kanban and Lean is to “Stop Starting and Start Finishing.” I believe that one of the first things people should do when they are prohibited from picking up new work is to swarm to the bottlenecks and try to provide assistance to get the system flowing again. There are times when you’re working as an individual, but unless you’re a one-man show, you are part of a team. So, be a productive member of the team and remember the overall goal of finishing things in progress. It matters little that the task isn’t assigned to you. If task A was already started by anyone, its likely its more important than the next thing you were about to pick up. It may be safe to assume that the higher business value is to have you spend time helping move task A out the door rather than starting that backlog item. It may be actual development, it may be becoming a sounding board, it may be acting as a coffee bearer… Regardless, swarming to the bottleneck and offering whatever assistance you can provide is one of the best ways to utilize slack.
Maintain
One of the huge mistakes of development teams is that they focus entirely on new features. New feature development is shiny and new and maintenance is boring and, well, less-than-sexy. When you buy a car you can’t spend all of your money throughout your years of ownership only doing upgrades and adding accessories. You have to maintain your car – get the oil changed, brake pads replaced, tire pressure and alignment checked, etc. Your car will break down if you don’t and you don’t get the return on investment you could have if you had just taken care of what you bought. Software is the same way. Unless you are perfect (don’t kid yourself, i know what you are thinking!), you will introduce bugs, you will make decisions you regret in your code, you will need to upgrade your code libraries or systems as time passes and technologies advance. This isn’t something that your business will be begging you to do. It just needs to be done. You can wait until the last minute and make an emergency project out of it or you can be a responsible development team and take care of your code-base frequently.
Think
Developers are thought workers. A large part of what we pay developers to do is think, to offer solutions to problems. I prefer my developers to think twice, code once. It saves a lot of time in the long run as you don’t spend as much time fixing bad architecture or realizing you didn’t think things all the way through. Sometimes you need to blow off steam, play some office foosball or ping-pong or the like. Its not rare to have great mental breakthroughs when you just take a break.
Innovate
I don’t know how many managers get the feedback that “we developers are always fully allocated so we have no time to innovate.” Ironically, this is rampant in companies in which developers are explicitly expected to offer innovative solutions. Some companies have policies like 20% time or other programs that build in time to innovate. However, just using slack time provided by adhering to your WIP limits is one way to combat the “no time to innovate” complaint. Adhering to WIP limits will over time, provide the downtime needed to think of an innovative solution or three. Take advantage of this and let your team contribute. Developers love to create and they don’t like to be just cranking out code for other people’s ideas all of the time. This is a huge retention tool. Use it!
So, now you know how slack can help you. It lets you swarm to bottlenecks to get things out to the end-users more quickly. It provides you the time to maintain your codebase and keep it current. Slack provides time to think about improvements that need to be made to your code and solutions to problems you have been experiencing. And last, but not least, slack gives you the opportunity to let your developers innovate. I challenge you to spread the word and begin to introduce WIP limits in your system so you can experience these benefits in your company.
August 1, 2012 at 12:40 am
As long as ‘busy’ is valued more highly than flow and ‘efficiency’ is valued over ”effective’, ‘slack’ will remain a dirty word. Well-reasoned arguments in favor of slack won’t change things. Tom Demarko’s 2002 book ‘Slack’ (http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficiency/dp/0767907698) is full of great reasons to increase slack but it fell on deaf ears.
While increasing slack is a necessary condition for increasing flow I fear we simply can’t market it that way. The word suffers from a fatally bad case of P.R. halitosis. The connotations are antithetical to the goals of leaders rewarded for creating ‘efficiencies’.
From a public relations perspective perhaps we need to use language that leaders are more likely to respond to? The word ‘capacity’ comes to mind. ‘Increasing capacity’ sounds a little more like a win to a cost accounting focused leader than ‘increasing slack’. While we typically need more slack, in the battle for hearts and minds – we probably need a better way to have the discussion with leaders.
August 1, 2012 at 9:00 am
I love this comment. You are directly on point here. The negative connotations of the word have a lot to do with the problem. I’m going to have to check out that book.
We also need to bring people around to the idea that activity does not always equal progress. Sometimes more activity inhibits progress.
August 6, 2013 at 11:35 am
Good suggestions.
At the end it’s all about being efficient. We need to be marathon runner not a sprint runner.