I ask “what process areas are covered” in your agile method. Technical Solution has pretty coverage, but the other three process groups have no coverage.

This usually ends the conversation with “well that CMMI stuff is just heavy weight waterfall.”

Great point. That’s the situation a lot of teams find themselves in. In Scrum, there is no concept of a project manager. The Scrum Master ensures the agile processes are followed and handles some of the PM responsibilities. The team itself is “self-managed” within certain constraints. These constraints are set by the Product Owner. Product Owners tend to think of themselves as responsible for marketing and prioritizing features/stories.

But there is a ton of work required between concept to delivery that isn’t about writing software. The PM items that include procurement, human resource management, most risk management, and coordination of most downstream activities, etc. are left to “self-organize”. Which means they just don’t get done very well.

This of course is not a problem, if someone IS managing the project. It becomes a problem if the agile development team thinks they’re managing the project.

I participated in your survey and agree with your personal judgment. I also agree that Lean is more than a collection of tools. I believe that most executives are understanding that implementing Lean results in/requires a change in the culture. This is consistent with the discussions at the Lean and Kanban conference in Miami that broad cultural change occurred as part of implementing Kanban. I have had the same experience with the Capabilities Analysis work I have done (which has a part of its roots in Value Stream Mapping). One executive, who we had found substantial savings for, said the most important result was that his employees were thinking about how they integrated into the business to create value instead of just how to make their job better.

Thanks for following me.

Nice post! A contributor to the debate is that many people view Lean as a collection of tools, and not as a culture of continuous improvement. To use the tools of Lean is not the same as being Lean. I comment more on Lean, IT, and Agile here: http://itbusinessalignment.wordpress.com/2009/02/02/lean-it-and-agile/

Nicely done. I agree that Agile teams have not won the trust of upper management – but overall I’d say they were set up to fail. They were given the autonomy to fail, but not the support to succeed.

Quite often, agile in organizations are agile overlays of a rigidly defined external process.

Now, is this a still a problem with the practitioners? Usually, yes. Because they know the mechanics of agile, but don’t adequately understand the principles.

Where Lean helps with better integration of agile teams is that it provides a set of principles understandable to both sides that serve as a cultural translation layer between them. This helps undo a lot of the combative rhetoric that was unfortunately part of agile.

I, personally, think that in the maturation of software development processes, the rebellious adolescent phase of agile was necessary. Now, can we mature without losing the benefits of agile? I sure hope so.