You Can Better Manage What You Can See

‘Those people in IT, I don’t know why we have them around.” Richard, a department head for a major healthcare firm, stared at me across the table. “They have projects that are six months late! Projects they told us would take only a few months to do! We’d be better off if we just outsourced the whole department.” He shook his head. “It can’t be fixed. We tried.”

There were more than 200 people in this company’s application development group. You needed a small theater to get them all in the same room. Why couldn’t they seem to complete simple tasks—simple by even their own definition?

Finding the gemba

The first place to visit was the gemba. Go talk to the programmers, see their space, and gain an understanding of what predictable impediments might be slowing them down. When visiting any shop floor, we usually find, first and foremost, physical manifestations of undue constraints or poor management. Unfortunately, software developers are engaged in knowledge work that is invisible. There is no gemba, merely people staring back at you from behind their keyboards.

This was not a 5S issue; keeping things clean and in their proper places was not going to solve anything. This was, however, a straight-up lean problem.

The first task: Create an observable gemba.

Teams of knowledge workers face a major challenge in that it is possible for them to be productive and effective for weeks at a time and have no idea what their co-workers are doing—even if they are working on the same project or even task. The work is simply invisible. Their main tools for production are their brains.

This invisibility of work means that simple acts of collaboration on the shop floor such as, “Help me lift this,” or, “Hey, you’re doing that OK, but here’s how you might improve,” or, “There’s too much inventory here; slow down production so the others can catch up,” become incredibly difficult to carry out.

Simply put, we can better manage what we can see.

These teams had created personal kanban boards that tracked the work of each individual coding team. These were on huge rolling whiteboards that tracked the flow of programming work through a simple, but illuminating, value stream.

The board also limited the work in process for individual contributors, so no one person would be overloaded, and the team as a whole could focus. They had created an observable gemba by building a proxy for work in progress, flow, and bottlenecks.

Visualizing for real

This all appeared to work on the surface, yet on-time performance did not improve. Projects were still mired down, and customers were becoming increasingly angry.

The second task: Be honest about work in process.

Every morning, each team would huddle for five minutes to talk about what work they were going to take on that day. These meetings were effective at getting everyone on the same page for that project. All team members left knowing what was on their plates for that day.

Then they’d work for awhile and then go to another huddle. Then another. Then another.

It turns out that people in the application development group were going to four to six huddles every day and accepting work in every huddle. The average worker was involved in four to six projects simultaneously. This would be comparable to working at Toyota and simultaneously assembling doors for Camrys, engines for Pathfinders, suspensions for Corollas, battery harnesses for Priuses, and dashboards for Tacomas. It would be utter insanity anywhere with visible work, but it’s routinely accepted as status quo for software developers, civil engineers, graphic designers, and accountants.

There was simply too much distraction and too much work in process for anyone to focus effectively and complete.

In order to get the teams on schedule, most of the projects they were on would need to be put on hold. Roughly 80 percent of the active projects would need to wait while the IT group focused solely on the remaining 20 percent.

This was not a popular idea.

When confronted with an 80-percent reduction in active projects, managers became unhinged. “Do you have any idea of the number of people waiting for those projects?” one midlevel manager screamed. The other midlevels nodded. It was simply too politically painful to stop any project.

Developers, presumably the beneficiaries of lower work in process, were likewise upset. “Those projects are important!” they protested. “We need to get them out as soon as possible! We can’t put them on hold!” Even those who were in charge of production didn’t believe anything would be completed on time.

This famous graphic from Gerry Weinberg made everyone nod, but still they were stuck. Political and emotional fear kept them working with so many projects that completion was either greatly delayed or impossible.

There was nothing wrong with Gerry’s graphic, but its inability to get people to act is telling. It was theory. It was possibility. But there was no direct impetus to act. People tend to act when they see something is amiss. The personal kanban boards they were using were showing them neat, orderly projects. Gerry’s graphic was showing them potential, but their own visualization was lying to them.

The teams then took butcher paper and hung it along the bottom of their rolling whiteboards. On that paper the people on the teams put a sticky note for everything they were doing on other projects. This created a view of real work in process for every team. That looked like the image below. At the very bottom, notes were so plentiful, they were stacked on top of each other.

The result was so ugly, so offensive, that no one could stand looking at it. We had succeeded in making the problem explicit.

Results

The explicitness of the problem with the “hula skirt” compelled the group to greatly curtail the number of projects in process. A smaller number of projects allowed a given team to focus on one project at a time and realize the savings pointed out in Weinberg’s chart. Teams went from mostly context switching and politics to actually working.

The newfound focus on completion had immediate payoffs. Releases went from being an average of six months late to happening every week. Defects also fell because the reduction in projects in process directly reduced the delay between coding and testing. This led to shorter feedback cycles and more effective programming.

Relationships with the customers became more collaborative, also due to shorter feedback cycles. Prior to the reduction in work in process, the team would ask a customer a question and then get back to them weeks or months later. Now the turnaround time was days or even hours. Customers felt listened to, and it’s no wonder, now they really were.

Moral

The moral of this tale is simple. Most knowledge workers (not just software or IT) suffer under mountains of work in process. This largely happens because knowledge work is invisible. Although no change is easy, immediate improvements to team throughput and effectiveness can be seen by simply visualizing the work and limiting the work in process.

Visualize the work to understand it. Limit the work in process to complete it.

About The Author