Tag Archives: lean

I’ve seen lots of managers struggle to help teams. Often, they are driven by deadlines and goals set by their managers. They do what they think will help, acting out of their current view of how things work.

Sometimes they look for new ideas on how to manage. One of the ideas that’s been popular in the circles I travel is Lean. Lean suggests three things a manager should do.

1. Reduce overburden.

In manufacturing, overburdened machines break down. In knowledge work, overburdened people make mistakes, fall ill, or burn out. So help the team hold to a sustainable pace by managing the amount of work flowing into the team.

2. Eliminate unevenness in the work load.

The aim here is to create a steady flow. One way to do this is by using team velocity to allocate work (velocity is a measure of the completed work a team can finish within a specific time period). Create an even pace by allocating work in timeboxes based on measured ability to complete work. Over time, as the team matures, velocity may naturally increase. Even flow of work means predictable delivery.

3. Eliminate waste.

Anything that does not directly add value to a product is considered waste. Extra processes, task switching, and partially completed work are examples of waste.

These three things—reducing overburden, eliminating unevenness, and eliminating waste—work synergistically to increase the capacity of the system.

I don’t have a problem with focusing on these three areas. Many managers push too much work onto developers or demand overtime without understanding how that actually reduces the work completed (or completed to some quality standard). Many managers don’t understand how pushing to much work actually makes the work take longer–and paying attention to how work flows through the system is more important than looking at the speed of individual task completion. Many manager don’t understand the dynamics of work in process, the cost of multi-tasking or context-switching.

These things aren’t much taught in CS classes and barely touched on in many business schools. So it’s not surprising that they many managers don’t know about them. (I do wish people–managers and developers– would continue to study their chosen professions after they leave school, though. By that I mean study, not skimming a few articles. Though if they’re my articles, keep reading.)

And any tool (or piece of advice) can and will be misapplied. This is especially true when a tool is plucked from one context and applied in another and when the use of the tool is divorced from the thinking and philosophy behind the tool. (John Seddon has some comments on Lean and Tool Heads.)

Sadly, to many managers start at the bottom of the stack, and never get past #3. And they start on #3 without a deep understanding of how the work works.

That’s where managers get into trouble. When managers focus on eliminating waste without attending to reducing overburden and eliminating unevenness–or understanding how the work works, they do enormous damage.

I hear about managers who approach this out of a cost-control mindset–and start looking for ways eliminate wasted money by making sure they are getting the most out of every employee.

On paper, , “efficient utilization of resources,” seems a like a Good Thing (assuming that you are not disturbed by referring to people as “resources”). After all, if you are paying someone for 40 hours a week, its waste if they aren’t on task for each of those 40 hours, right? That’s the thinking.

One manager devised this workflow in the name of efficiency, eliminating waste:

This manager devised an "efficient" workflow.

It did look quite neat and efficient on paper.

But the team wasn’t performing as he hoped and he wanted to “fix” the team. He was upset that they weren’t achieving the improvements inherent in his work design.

It turned out that the product had dozens of code modules, and each developer specialized in a handful, but knew next do nothing about the others. Under the managers design, as soon as a developer finished one piece of work, he should take the next item in the prioritized queue.

If he knew about that code module, the process worked okay. But chances were pretty high that he’d pull a module he didn’t know anything about. Plus, they got calls from the support desk, from the product owner team, and the production support team, all of which were considered as priority interrupts (by everyone, including the manager–which he some how forgot when he designed the work flow).

It looked more like this. The arrows show communication flows related to an unfamiliar code module. This picture only shows work for one person…it would be really messy if it showed more. (I also found it quite interesting that testing was a sort of mysterious cloud in this organization.)

There were a bunch of ways to improve effectiveness at this company. But the fantasy workflow wasn’t one of them.

Rather than start with a slogan (“eliminate waste”), start by understanding how the work works. And that means understanding structures, behavior over time, communication flows. That’s management work. When managers take action without understanding the work or the theory, the result is seldom pretty.

Hank Roark, Gerry Kirk and I have been having a chat about “non-value added but necessary” tasks over on Twitter.

It started with an assertion that any thing that doesn’t add value to the customer or delays delivery of customer value is waste.

That sets up a binary decision: tasks are either provide value to the customer, or they are waste. I’ve noticed that when people first start mapping the value stream for software development, they tend to assert that management is all non-value added work.

In addition to value-added and non-value added work, I think there’s another category, “non-value added, but necessary.”

Non-value added, but necessary are tasks that don’t directly add value to the customer, but enable delivering value to the customer. Sometimes these are the tasks and functions that enable the business to stay in business–like accounting, or payroll, or management.

That’s not to say that there isn’t waste within those functions, there certainly is.

But no one likes to hear that they are adding no value. When people hear that, they tend to feel defensive, and people who are feeling defensive are less like to be able to take an clear-eyed look at how they can best improve the system.

Having a category of “non-value added by necessary” gives a way for people to examine the work that isn’t directly on the software development value stream without focusing so much on justify their existence. Then the are more likely to see where they are doing tasks that don’t enable creation of value and shift their focus to work that does.

We need to look at “value” from the customer perspective, certainly. We also need to look at value from the viability of the overall organization, and at work that isn’t directly related to the product but creates the conditions for creating value.