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.)
But I digress. Back to the three-legged stool of Lean,
1. Reduce overburden
2. Eliminate unevenness in the workload
3. Eliminate waste
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.
“Efficient utilization of resources” drives context switching, when people are assigned to multiple teams to achieve 100 % allocation. “Matrix teams” (which aren’t really teams, in my experience) look efficient, but impose communication and coordination overhead. When slack is gone people cannot respond to unexpected events and things fall apart. Task-switching makes everything take longer.
So hoping to do good, managers make the situation worse.
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.)
The "efficient" workflow with reality thrown in.
Why so slow?
Interdependent work, non-fungible people, steep learning curves and multi-networked queues.
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.
I appreciate this article!
A focus on efficiency is appropriate in manufacturing, as the destination is well known.
Creating new software is really new product development though, where the game is knowledge creation. Keith Sawyer (psychologist and author of Group Genius) and Google CIO have said that innovation is inefficient. I don’t know whether efficiency of innovation can even be measured, but I have seen an excess focus on efficiency kill off innovation. To innovate, we have to try and fail a lot, and this will look like “waste” to a naive manager.
–mj
http://ScrumReferenceCard.com
Yep. Efficiency can kill a company.
This is really good. I would take it a bit further, because Lean DOES work for services and “knowledge workers.”
The problem is not starting at the beginning, at the true focus of Lean, which is “How do we learn about and then deliver what the customer needs or wants?”
For Lean, staff alignment has to be around this fundamental: “our learning organization thrives when and because we give the customer what they need on time and to high quality.” Pull, flow and kaizen are deeply rooted in this idea. And, there is no “one way.”
Without that understanding maybe it’s just change for change’s sake (or the appearance thereof). I don’t think you can just pluck out facets of Lean and expect people to get it right. The LEI definitely promotes the idea that Lean often results in a significant organizational re-orientation.
I’ve seen lots on instances where someone pulls one idea, technique, or tool out of context. And you’re right, it seldom works.
But people keep doing it, hoping for a magical fix.
I’m not sure it’s change for changes sake–perhaps more for the appearance of taking decisive action.
Thanks for stopping by.
Hi Esther,
I love this post.
I also agree with R Mullen. In my understanding the ‘true’ Lean has respect for people as one of the pillars.
Thanks for writing this.
Peter
Hi, Peter –
Yes, respect for people is a tenet of Lean. And some people would say that Lean drives standardization to an extent that can feel oppressive, and feels like command and control.
I think perhaps it’s best not to cling to closely to any school. Better perhaps to understand principles of complex systems, understand the work, observe, learn, look through different lenses and find options to improve fit for function.
Thanks for stopping by.
e
Hi, Bob –
“Waste, overburden, & workload unevenness are more readily measured and tweaked in the context of machines — not so easily with people.” Absolutely true. I do think its an interesting, though, to ponder why so many manager grok that you can’t overload, overstuff. or feed lumpy workloads into machines and expect good results–yet don’t consider these dynamics where people and knowledge work are concerned.
And thinking about people as people seems a better tack than trying to equate them to manufacturing plant.
e
Hi Esther,
I haven’t seen this example myself but I am sure it happens. Another example that I recently saw was a company doing Lean in each department, with the objective to lean out the processes in each dept. and while doing it cut 20% of cost. The six sigma consultants had rebranded themselves as lean consultant. They made some process changes then gave cost cutting recommendations. This was not Lean how we would think of it, however it did cause most staff in the company to fear being “leaned out.” it also gave Lean a very bad reputation with the staff.
Understanding how work gets done in your business is the first step before applying lean tools. Value stream mapping is a good approach however it needs to be created by the people who do the work. Also needed is a safe environment so the actual process comes out, not the one imagined by upper management. These sessions are often revelations of visibility. People discover things they never knew were happening. However the enthusiasm for fixing things needs a plan that will be followed by both staff and management. The map is the easy part. Fixing the problems and measuring the improvements is what is challenging.
Regards,
Robin Dymond
I find it useful to look thru several lenses, visible and invisible structures, system structures, policies, procedures, culture. Value stream mapping is just one tool, and doesn’t always reveal the complexities that will make change difficult or impossible.
I think it’s a great step forward that we’re criticizing the application of manufacturing methods to software development.
I think we’ll take an even greater step when we recognize that Lean Product Development (Lean Software Development) isn’t Lean Manufacturing.
The application of Lean Manufacturing to software development is worthy of criticism. So are critiques of Lean Software Development made through the presumption that it’s Lean Manufacturing.
We have a responsibility to understand the spectrum of Lean applications, and to understand how they differ and how they’re tuned to the domain.
Lean Manufacturing would as well be troubled if it were practiced as Lean Logistics, Lean Healthcare, or other Lean disciplines. Many of the guiding principles are applicable to a great range of domains, but the actual applications are domain-specific.
I’m looking forward to dialogs about Lean Software Development that are informed by more than presumptions of Lean Manufacturing.
“Eliminate waste” can lead to “reduce quality” because “obviously” time spent reviewing code, testing, or pairing is wasted time, right?