Each organization has a different root cause for this constriction of throughput, but the situation can be generalized: dysfunction of a larger organization is generally stable enough to seek and successfully to return to its original—via compensation elsewhere or direct counteraction—any time a team increases it locally.

There are benefits to applying good process to individual teams, or even one team, but the benefits neither extend to organizations’ profit or customers’ return on investment; they’re limited to the well-being of the teams.

There isn’t a good solution to this—good in the sense of being usable by the same people who’d start to implement high-throughput processes on the line—rather, recognize that localized success in mediocre company cannot, sustainably, reach the customer and if we want to, we have to find a way to go beyond the line to increase companies’ tolerance for throughput.

More bluntly; the Scrum Master that doesn’t remove impediments is an impediment to be removed.

Festering Sores

An impediment creates waste until removed – identified or not. That should make you very nervous; what you don’t know is out there killing your value stream.

Eventually, a big enough impediment, or enough small ones, will overwhelm a team, bringing it to a total standstill – flat-lined on the burn down. It can even start to take the team backwards, burning up without new work – a sight as pleasant as watching a two-hundred kilo man eat two burgers at once.

Go and See For Yourself

Randomly sampling activities around your value stream is a great way to start finding impediments. When you walk the line and see what people are up to, focus on people not working: they’re probably waiting on an impediment.

1. Never assume teams can see impediments themselves.
2. Never assume that they will tell you about those they can see.
3. Impediments that you don’t seek out will simultaneously get more wasteful and harder to see. Rather than becoming more pronounced, big, old impediments seem to settle into the background, becoming the reality that people operate in rather than on.

Identification

Here are a few questions to ask yourself about an activity:

• Would this seem odd to a person new to the team, without some explanation?
• Would I consider this OK at another company? At a great company?
• If I were to explain this activity to an outsider, would I feel an urge to excuse it?
• Is value added throughout the activity’s duration?

It’s tempting to use the five why’s to decide if something is an impediment, but this leads to a common failing: reasoning that the cause of something helps determine whether it is an impediment. No matter how justifiable an impediment, it is still an impediment and its brethren pave the road to hell.

Getting Organised

Big visible lists, issue trackers, and wikis are good ways to track and prioritise impediments. Whatever you use, it should always be highly visible, up-to-date, and prioritised or ranked.

Commit to yourself to take some action on each known impediment every day. I use the comment log in an issue tracker to keep myself honest on this one, because keeping up is as hard as it sounds.

Unfortunately, a team can step through the motions of the best methodologies and still be devoid of creativity, innovation, and learning. Lack of mutual support, homogeneous expertise, distrust, and disinterest are some possible culprits.

In the field of enterprise software development the most likely cause is insufficient intrinsic motivation. It is a field saturated with high salaries, material perks, but devoid of strong intrinsic motivators such as altruism, conviction, or moral urgency. So we rally around structures. Processes. Practises. We’re Agile; so we put people before all else. But, even that is a process.

Wisdom would say we should first focus on the basis of creativity and secondly on frameworks for harnessing it; we must bring personal value to what we do. The bad news is that this may not be possible in some software fields. The good news is that the competition is probably just as bored.

I view stopping the line as illusive because, while it is ostensibly a manifestation of zero-tolerance thinking, it is actually an autonomic behaviour that drives an organisation to engage in practical learning. Moreover, it interconnects with many lean principles; in my opinion, a real understanding of the practice is not possible without some knowledge of Kanban and Jidoka (see Ohno Taiichi and Jeffrey Liker respectively.)

The illusive nature, combined with the intentionally disruptive character of a stop, sets the stage for teams to revert to basic practice – those already part of the team culture. A young team may lean towards energetic chaos without result. One new to agile or lean may reach for their old waterfall tools, such as omniscient inspection. Teams without a culture of relentless improvement may not engage, believing that such problems are acceptable if corrected. Those that are not rewarded for failure may seek only to ascribe blame or excuse the problem as inescapable. And so on.

There are two subjects to consider when looking at utilising line stops as a tool. The first, a culture of organisational learning, is outside my ability to cover here. The second, and less important aspect, is the mechanics of performing the stop, which I will look at here.

Stopping the line to consists of:

1. Determining that a stop is warranted
2. Performing the stop
3. Understanding the problem
4. Planning preventative measures
5. Fixing the problem
6. Restarting
7. Putting the preventative plan in action

One can further reduce this to be simply “stop, understand and adapt, go.” For an alternate view on this, see Kevin Rutherford’s very helpful perspective.

In the initial stop, there are two areas of difficulty. The first is the detector of the problem realising that a stop would be beneficial – as opposed to fixing it or noting it for future correction. The second is performing the stop in a manner that both clearly communicates the problem at hand and helps others smoothly transition from their current work – as opposed to just dropping everything in a mess that will make restarting difficult. To do that, people will need to understand the mechanics before calling a stop.

In understanding and adapting, it is focusing on the superficial problem and on improving quality control that leads the team astray. I believe that drilling down to the essence of both the problem and the solutions by asking why is very helpful here. Aggressively mix the ideas of leading with questions and of asking why five times. The goal is to shift the focus onto improving those fundamentals directly related to the problem’s root cause.

When starting back up, the most significant concern is the easiest to avoid, that of the team returning to a partially forgotten mess. This will quickly overwhelm the practice of stopping to fix problems with a slew of new problems. The obvious way to avoid this is to execute the initial stop well, with the impending restart in mind.

What was not obvious to me, until it was far too late, is the amount of leadership that these simple steps require. Given that they constitute the deliberate disruption of running processes, such as authority-on-demand and self-organising teams, it seems blatantly obvious with hindsight that some form of additional leadership will be in demand.

To summarize, the core factors to keep one’s eye on are:

1. The illusive, ostensibly simplistic nature can give one a few nasty surprises.
2. Without all of lean, especially Kanban and Jidoka, the value of a stop is questionable. At the very least one has to be sure that some achievable goals are in place; stopping will not magically make an organization lean.
3. Make sure everyone has a basic understanding of the goals and principles well before the first time someone uses it.
4. Provide decisive leadership at the outset, if it makes sense to reduce it later on, do so.

It is important to realise that, like so many lean activities, parroting the motions of stopping the line is wasteful – if it is without a foundation of lean principle. Still, I believe that stopping the line, if done well, can be a lightweight practice that both helps instil lean principles and provides immediate learning opportunities. Whether I can turn that speculation into fact is yet to be determined.