Allen Holub

Dr. Dobb's Bloggers

You Can't Impose An Agile Process

February 10, 2014

To be effective, select your tools and develop your own processes

I've always been uncomfortable with the notion of formal training in specific methodologies. It's certainly valuable to have a palate of practices to choose from, and formal training is a great way to develop that palate.

I get nervous, however, when the trainers come in to teach a specific process and then management expects everybody to follow that process. The certified-SCRUM movement is the worst offender in this department. A company understands that they need to be more agile, so they contract with some certified training outfit that teaches everybody a uniform process, and then everybody's expected to follow that process. This sort of formal training tends to instill a "this is the right way to do things" mentality.

That approach never works.

So, why is that?

There are lots of reasons (many of which I'll talk about in future blogs), but let's focus on one.

I've recently been rereading Mary and Tom Poppendieck's Lean Software Development, which is essential reading for anybody who expects to successfully introduce agile into a phased-development organization. I reread the book every few years to remind myself why I'm doing what I do every day.

The Poppendiecks provide a telling example from the manufacturing world. In 1982, GM shut down what was probably the least effective auto manufacturing plant on the planet (a few miles down the road from me in Fremont California). Quality was miserable, which cost GM a fortune in warranty work. The plant employed 20% more line workers than necessary just to get a full complement of workers on the line on a given day. There were something like 5,000 unresolved union grievances on file.

A couple years later, the same plant was resurrected as New United Motor Manufacturing (NUMMI) — in theory a joint venture between GM and Toyota, but Toyota was running the show using Lean principles. Under Toyota, absenteeism dropped down to 3%, quality shot up, and by 1991, there were only 900 grievances on file. The plant became the most productive auto manufacturing plant in the U.S.

So, what was different?

To my mind, the most important change was transferring responsibility from managers to the people who did the actual work. It used to be that managers would walk around with stopwatches, figure out how to improve productivity, and then tell everybody to do whatever they came up with. The whole assembly line was treated as a single system, with a lot of centralized planning controlling how things were done in the trenches.

Toyota turned all that around. They gave the line workers the stopwatches and told them to figure out how to improve their own efficiency. And the workers did that with enthusiasm. Instead of looking at the line as a single organism, the organizing principle became small groups working to do a single task, and each group coordinated with adjacent groups who were doing different tasks. Each group was responsible for creating their own processes, and they created very effective processes. More to the point, everybody who wasn't working on the line focused solely on helping the line workers. Nobody was telling anybody what to do.

Of course, GM wanted to duplicate that success at it's other plants, so it sent people around to closely observe and document all the practices that the individual groups had invented, and then introduced those same practices at their other plants.

It didn't work.

None of those other plants were as effective as the NUMMI plant.

Why?

The underlying principles at NUMMI were trust and autonomy. Toyota trusted the workers to know how to do their job, and expected them to develop their own processes. Those principles spawned a bunch of explicit practices. GM then tried to move those practices to other factories, but it didn't instill the new principles into those factories. That is, practices that were successful in one plant were much less successful when moved to another plant. To get that success, you need to move the principles, and let the new group develop its own practices.

I strongly believe that the same principle applies to software-development process. Agile principles are not at all fuzzy. They're spelled out in detail here. Ultimately, all agile processes reify those principles into a set of specific practices.

If you try to move those practices without understanding the principles, though, you'll be in the same position as GM. You can't impose practices and expect any real success. Rather, you need to instill the principles, show people a bunch of existing practices that realize those principles, and then let the workers come up with a process that will work for them.

The core Agile principle at work is: individuals and interactions over processes and tools. The individuals need to develop their own processes and select their own tools to be effective.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!