Lean - An Agile Management Process

In Three Critical Enablers for Agile, the second critical enabler is use of a management process consistent with the Agile engineering practices that continually produce software. For this, I use Lean, a manufacturing process borne in Toyota and responsible (IMO) for the current dual dominance of Japanese companies in both automotive production and quality.

Think Production, Not Building

I cannot over-emphasize how radical project management is when shifting to Lean. Of all the Agile roles, the role of project manager changes most in Agile. It dwarfs the impact Agile has on the development, testing, and analysis roles. But to gain the benefits Agile promises, changing the thinking around project management is critical.

Agile focuses on continually producing working software. Traditional phased software development (aka waterfall) focuses on moving the project steadily forward one phase at a time, doing its best to ensure everything is right before building upon that phase in the next.

Traditional project management is based on traditional engineering; civil engineering is my favorite analogy. Software is like building a bridge. You need to know what is needed (a bridge). You need architecture (suspension bridge). You need design (number and spacing of struts). You need to build it in a specific order (base before pillars; pillars before road surface). You need to test it (weight bearing tests, plus inspections). Waterfall software processes follow this model. The prevalent tool for traditional project manager is the Gantt chart, a schedule of activities and dependencies that can track progress.

Before disparaging waterfall too much, it is worth saying waterfall works. In my years at IBM, I participated in many waterfall projects that delivered quality software on time and on budget. Indeed, I have been a part of a thousand programmer project spanning three years and delivering. So don't count me among those who say waterfall is bad. I remember the true chaos before waterfall.

But as I believe Agile is a better process than waterfall (and I have tons of experience with each), I believe that Lean is a better management process for Agile than foisting traditional project management onto an Agile project.

Lean management practices focus on production; this factor alone makes it a good fit for the constant production of software characteristic of Agile. But Lean management differs significantly:

• No useful information can be captured in Gantt charts
• It is not important what someone will be working on next week
• Individual assignments are subsumed by team efforts

Basically for the traditionally trained project manager, it is bizarro-land. Round is square; down is up; when means why; and who means when.

But all is not lost. Lean brings powerful new tools to the project manager, tools that give insight into the project success throughout the project. At this point, I feel completely naked on a project without these tools. They are my new security blanket. These Lean processes and tools:

• Track production, giving you new insight into the real progress
• Show skill imbalances with clear direction on actions
• Remove much guesswork out of the question, "Are we going to ship on time?"
• Provide superior techniques for productive feedback to individuals
• Support dynamic adjustments to schedule, content, and resource

Sound too good to be true? Consider that we will be stealing most of these techniques from manufacturing management practices that are at least as old as the engineering practices we use today. We are not inventing new things here, but rather borrowing from a different source, manufacturing instead of civil engineering.

No Management Alternative

I have seen many (and heard of many more) Agile projects that recognize the uselessness of most of the traditional project management practices. There solution: abandon the practices altogether, but substitute nothing else. Everyone is a professional, after all, and they will be doing their best.

For a short time, this seems to work well. But for a longer project, someone will start to count the cost at some point, and ask the question about when it will be done, how much more will it cost, and do you really need all that staff that is working on it now.

All these are valid questions. A matching management process should be able to answer these questions without over-burdening the team. I believe the Lean management processes do just that.

Key Manufacturing Practices That Are Borrowed

I focus on three key things to borrow from Lean to aid in managing Agile software development:

• Feedback is the source of quality,
• Identification and elimination of waste, and
• Reduction in the number of specialists.

Each of these will be the subject of future posts.

Are you using non-traditional management practices in your Agile team?