Tag Archives: Slack

The Agile Lowest Common Denominator – Avoiding a slowdown due to the weakest link

Estimated Reading Time: 4 minutes

One of the concerns often raised when people hear about kanban is that the weakest/slowest link will slow down the whole chain.

For example if testing is a bottleneck what will happen is that the whole chain will accommodate its pace.
Similarly in scrum a team that actually does realistic planning will commit to a goal that stretches the bottleneck leaving other resources some serious slack.

In both approaches this is indeed a valid concern.

The worst thing that can happen is if the bottleneck causes the rest of the links to adjust their pace, and worse than that their “pace memory”. I’ve been thinking about this for a while and am also asked about this quite frequently whenever I introduce kanban to Managers with some experience…

In an old but wise article about the “Four Roles of Agile Management” David Anderson refers to it as “The team can forget how to run fast – when there is a bottleneck/drum”. I recently had a twitter chat with David on the subject. David sees this problem as an optimization problem for high maturity organizations. Based on the discussions I’m having, I think the optimization might indeed by a high maturity tweak, but even the concern about this happening is a roadblock to accepting the concept of Kanban Limited WIP or Scrum Whole Team Commitment.

I think we need to have a better answer for this question as part of the kanban “sales pitch”. At least I need it…

So what do we say? Based on the discussion with David and some more thoughts some of them fueled by recently reading The Principles of Product Development Flow: Second Generation Lean Product Development, I would recommend the following.

Basically, what we want to do is solve a conflict. On one hand we don’t want to create inventory and increase the gap between faster stations and the bottleneck as we know that creates slow feedback, lower quality, and we will have to close the gap at some point. On the other hand we don’t want to slow down the other stations as we know its both lost capacity, as well as can lead to lower capabilities over time if they “forget how to run fast”.

How can we solve the conflict? By looking at the assumption that the other stations always work on flows that must involve the bottleneck. Can we break this assumption? YES we can…

There might be work types that don’t need to go thru the bottleneck. Not all work is created equal. For example, if Server guys are the bottleneck, choose work that is not as Server-Heavy. If Testing is the bottleneck, choose work that is not Testing-heavy, or even items that can be tested without the involvement of the testing bottleneck.

Now the purists will say that the priority always needs to be the business priority. But now we’re pulling and prioritizing work based on our capabilities. Yes we are. Prioritizing purely based on the business priority will lead to lower business outcome overall. Our aim is throughput of business value. We achieve that through the right mix of Business Priority and right exploitation of our resources.

Having said that, if we see that we keep skipping priorities due to our capabilities, its time to go to the next step. Create a work item / class of service that serves to realign the business needs and the factory/machine capabilities. For example, in the world of testing this can be test automation done by developers in case testing is a bottleneck. If Server are the bottleneck, we can define a backlog of items that reduce the workload on Server (e.g. Refactoring and returning Technical Debt), or cross-train UI people to gain Server capabilities.

There are more ways to do this, but the bottom line is to always have items in the backlog that the non-bottlenecks can pull and run as fast as they can on. Preferably some of them are aimed at helping balance the line, driven by a process of ongoing improvement.

Since I started talking about this with Management, I see much more traction for the various ways to limit WIP, whether Scrum Sprint Commitment or the more explicit Kanban WIP Limit. I think the idea of “Too much slack” is currently a truth the mainstream is simply not ready for. Beyond that, I think its not fair to ask people/teams to solve this conflict on their own. Help them by discussing the various ways to address the problem, by helping them create backlogs of improvement ideas they should pull in those situations, and by setting the right classes of service / work types that create the alternative routes around the bottlenecks. I think this IS a management role in an agile environment.

PS None of this is really new. The innovation is in setting up the right classes of service and the right risk profiling to effectively manage the line. Elements like choosing items with low cost of delay so they can be used to “Fill Slack” and not pulled as part of the normal priorities. And risk profiling so we re-route or skip the bottleneck on the items where the risk of doing that is minimal. Add to that measuring local cycle times (e.g. with tools like LeanKitKanban ) so each Capability can focus on its own performance as well as the overall cycle time, and you get quite an elaborate system. Sounds advanced? It is. I intend to cover this in Advanced Kanban Workshops we will be starting to run, since we know have quite a community of Kanban Practitioners around Israel. Hopefully we can extend that community to the region soon.

Why I think slack is highly important during an Agile/Kanban transition

Estimated Reading Time: 4 minutes

(Note, this post is about slack the concept not Slack the collaboration platform. Though Slack the platform is great as well. We use it at AgileSparks and love it, although it eats up some of our slack time…)

Actually, the title is wrong. I think slack is highly important during any change initiative where you expect continuous improvement of the process and practices. The importance of slack is not new. Not in manufacturing, and not in the Software Engineering world. One of my favorite books is Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom Demarco. Actually anything by Tom is a gem worth reading if you’re serious about managing Product Development organizations… But today I had an epiphany. One of the biggest challenges we face as consultants trying to challenge organizations to be more effective/agile/lean, is that the people simply don’t have enough slack. They don’t have enough time to meet with us. They don’t have enough time to meet and retrospect. They don’t have enough time to experiment. Experimentation takes time – you need to think about what to try, if you take a risk, there is a chance you will fail and lose time. Its very frustrating as a consultant/coach. You have so much to give, you see so many opportunities for improvement, you know that if the team will just sit in a room for an hour they will come up with ideas that can help. You know that if that Developer from the team has some slack time on his hands, he will think of a way to make that build run faster. That test automation suite easier to update.

My pledge to managers leading Agile/Kanban transitions
Please Please Please consider how to add slack to your system. Especially during a change initiative it will help you get the most out of it. People will be more engaged, you will get much more out of your efforts and budget. I pledge to try and convince my clients to do this…
Now that you’re convinced, lets discuss how to actually do it in practice. If you’re not convinced or think you have other ways to better drive this point, I’m all ears… and the post is open for comments…

To effectively use slack I think you need to do two main things:

  1. Account for slack in your resource planning.
  2. Have effective mechanisms to use the slack for the best possible purposes.

Accounting for slack in the plans This is quite straight-forward as soon as you convinced your stakeholders it is a worthwhile investment. Pointing them towards Google (20% time…), Atlassian (20% time and FedEx Day) and other companies using slack as a core part of their system, might help you. Technically, just reduce the resource capacity % in whatever method you are using to manage your projects/commitments. Another great way is to use the slack that is inherent to the plan/development process. What do I mean? For example – in a Kanban/TOC/Flow system the bottleneck doesn’t have any inherent slack. But upstream and downstream from it, if you work in Pull mode, you will find slack. This is because they can process faster than the bottleneck, so obviously there will be times they cannot process because they are bound by a WIP Limit (Or TOC Rope). In Iteration-based Agile this slack takes the form of some free time on the last few days of the iteration if you’re not the tester. In both these scenarios when you have slack, you can either throw it at the bottleneck’s current work, or use it in other ways.

Effectively using the slack
Now that you have some slack time, what do you do with it?
One flow/continuous oriented approach is the Google 20%. People simply have the slack to work on other things in parallel to the ongoing core work.
Another approach is to setup special events, like Atlassian FedEx Day. These events are a time where the entire team/organization is focused on slack kind of work, and it is probably a good idea to use those especially when starting, to kickoff the mindset that slack is a good thing, and show some examples of what can be achieved.
What do you actually do on slack time?
One type of activity is pushing the product forward in some innovative small ways that are off-road from the main track of the project/release. You need to be careful here – messing around with the core behavior of the product is probably not a good idea without the blessing of the Product organization…
I would imagine the google engineers don’t mess around with the homepage too much. They introduce their innovations via Google Labs, plugins, etc. Some ideas make their way into the mainstream product, some become mainstream products (e.g. GMail)
I wanted to talk about a second kind of activity – the one that pushes the capability of the organization forward. Here, your aim is to identify areas where improving can have an effect on the bottom line performance of your organization, and then find ways to improve there.
I discussed before some scenarios like this, but to reiterate the important point – you want to use slack to help Exploit your current system Bottleneck. Now, as I said earlier, one way to simply throw the slack capacity at the current work of the bottleneck. This will help tactically, but will not improve the capacity of the Bottleneck in any long-term fashion. You should balance the tactic solution with finding ways to spend slack capacity on things that will really make the Bottleneck more efficient.
What this means is that a lot of times, the resources working to improve the capabilities of a function, don’t even belong to that function. This is why cross-functional teams and a holistic end-to-end view of the Value Stream is so important… without it you can improve things locally but have zero (or even negative) effect on the bottom line.