Agustin Villena has a problem convincing management to accept kanban limits. He writes:
I'm currently acting as a consultant, and I'm stuck on managers that despite the fact that the kanbanboards show clearly the extreme work overload of their people, they don't realize the negative effect on throughput and stress...
The problem now is to limit the total amount of projects assigned to the team. But their manager is who we can't convince to filter incoming projects.And also there is the paradigm that slack is waste...
Why shouldn't we consider slack to be waste? According to Tom DeMarco, slack is "the degree of freedom required to effect change." When put that way, slack can be seen as a necessary lubricant within an organization that prevents its moving parts from seizing together.
According to Mary and Tom Poppendieck in their book Lean Software Development: An Agile Toolkit, slack serves an even more fundamental purpose when viewed from the perspective of queueing theory: "Just as a highway cannot provide acceptable service without some slack in capacity, so you probably are not providing your customers with the highest level of service if you have no slack in your organization."
Amir Kolsky offers this pithy rebuttal to the charge that slack is waste:
Slack does not mean people are lounging around.Slack means that people are not working to push stuff towards the bottleneck.
They can be kept busy doing other stuff.
So what might be causing the problem of resistance to kanban limits? Nader Talai suggests that perhaps the managers' resistance to kanban limits may be partly motivated by how their team's performance is being measured:
Do you know what it is that the managers(s) value or are measured on? Does the board show what they value?[...]
For example a manager may be measured on Development Complete as opposed to Released without defects. I worked for an organisation where the IT team was measured on delivering projects on time based on dates which were estimated 12 months in advance. In this organisation the focus was on delivering on time regardless of what was delivered or the quality.
According to Tomo Lennox, more education may be necessary:
When managers hold the simple concept that more work in gives you more work out, they are not going to change until you can teach them something.
But never underestimate the power of a joke to get your point across. "People listen better after a joke," writes Lennox:
A policeman sees a boy running next to his bicycle, so he pulls over to offer assistance. "Do you have a flat tire?", the policeman asks. "No", says the boy and he runs by with the bike. The policeman drives up to the boy and tries again. "Then what is wrong with your bike?" "Nothing", says the boy and runs off. The policeman drives up and tries one more time. "Then why aren't you riding your bike?" "I am so very late for school, that I don't have time to get on the bike." ... and he runs off.
Community comments
How teams are measured
by Dave Nicolette,
Like traffic queues, then
by Jonathan Woods,
Re: Like traffic queues, then
by Jose Puente,
Slack is not the issue
by Chris Matts,
Importance of slack
by XebiaLabs XebiaLabs,
How teams are measured
by Dave Nicolette,
Your message is awaiting moderation. Thank you for participating in the discussion.
Following up on Nader Talai's observation, it seems that many teams and individuals are measured mainly on how "busy" they are. This ties back to the old mentality about maximizing individual resource utilization. "Slack" looks like "not busy," so this sort of manager doesn't see the value in slack.
Like traffic queues, then
by Jonathan Woods,
Your message is awaiting moderation. Thank you for participating in the discussion.
Here in the UK, we're increasingly used to the idea that everyone's travel time can be improved by observing 50 mph speed limits on roads which are normally 70mph. Even for those without a doctorate in traffic management theory understand slower can sometimes be faster - perhaps this is a useful metaphor.
Re: Like traffic queues, then
by Jose Puente,
Your message is awaiting moderation. Thank you for participating in the discussion.
Time travel or perceived time travel ?
Slack is not the issue
by Chris Matts,
Your message is awaiting moderation. Thank you for participating in the discussion.
There are actually a couple of issues here that might be getting in the way of each other.
Issue 1 - WIP Limits
The WIP limit is really a solution to help focus on getting a single BVI (business value increment) to completion rather than having lots of BVI in process but nothing completed. Talking about WIP limits really focuses on a solution rather than the problem.
First, discuss the problem with management rather than the solution. The problems are two fold. One, we have lots of stuff in process but nothing in production. Second, task switching / context switching* reduces the effectiveness of developers. Get management to engage on the problem. Until they perceive and understand the problem, there is no real point in discussing the solution.
Second, discuss the potential solutions of which there are many. e.g.1. Limit the number of tasks a developer can work on to one to prevent context switching. e.g.2. Introduce WIP limits for the BVIs.
Issue 2 - Slack
I'm not keen on people sitting around doing nothing. I think it is a misunderstanding. The team should be 100% utilised on value creating activities at all time. The problem comes that most managers translate this to "100% commited to critical path activities at all times". In actual fact, the slack is that proportion of the team that is not committed to critical path activities. This means part of the team can be taken from the critical path activities to address other issues without blocking activity on the critical path.
In practice this means not allocating critical path tasks to your most effective developers. Instead, have them pair/coach less effective team members who can carry on with critical path tasks if the effective types are pulled off onto another task. This should mean your most effective team members are instantly available to address issues. I call this approach staff liquidity.
*read the excellent and much under discussed "PeopleWare" by DeMarco and Lister.
Importance of slack
by XebiaLabs XebiaLabs,
Your message is awaiting moderation. Thank you for participating in the discussion.
Great post, Dan – we especially appreciate the joke with the boy and the bicycle! It’s important to give employees slack to maintain sanity, but, as you mention, slack is also extremely beneficial to progress. One way to increase the amount of slack that employees have without decreasing the amount of work that is accomplished is by implementing deployment automation software, which can eliminate the large majority of hands-on work required for each deployment. With this software, employees are given the freedom and time to focus on improving the company and project – the ideal use of slack. Would you agree?