The Decline and Fall of Agile SCM—and the Rise of Lean SCM

assume that all SCM is agile).

The Rise of Lean

An issue for us is that Agile development has its scope specifically targeted on software development, and extending it beyond that to other disciplines (systems development, whole enterprises) is less obvious, and perhaps less applicable. In contrast, Lean applies to the whole enterprise/organization and its attitude toward management (including the perceived attitude toward CM) is different. Brad discussed this in his blog entry Agile Self-organization versus Lean Leadership :

The key difference between business-agility and software-agility is the extra emphasis of the latter on "the people factor" and on the notion of dynamic self-organization of knowledge-workers as empowered, self-organizing teams. This difference between agility at the business-level versus software-level is also the key difference between Lean-vs-Agile:

That is not to say that Lean (or business-agility) doesn''t emphasize trusting and empowering workers and teams (they do). But they don't have the underlying inherent attitude of "just trust us and stay out of the way." The "trust" often doesn't seem to extend as far in the other direction with Agile development (e.g. not trusting management direction to the same extent that management is asked to trust the team)

    • Lean focuses more on  flow whereas  Agility focuses more on adapting to change (this is true of both software agility  andbusiness-agility). As it turns out, focusing on flow requires being able to adapt to change; and focusing on adaptiveness and responsiveness requires a focus on flow. So here, the end-results may be quite similar
    • Agile software development emphasizes a very  hands-off management style of not just trusting and empowering the team(s), but often to the extreme of basically saying "leave us alone and don't interfere" to management (and in return promising extreme transparency and frequent tangible end-results)
    • Much of this is due to the fact that the scope of  Agile development is  limited to software projects and teams , whereas  Lean is targeted at enterprise-wide scale across the whole value-stream .

I think this stems from the fact that software agility started more at the grass-roots level, with developers and teams struggling to create good, quality software in the face of what was all too often a fundamentally broken management framework for the governance, visibility, and lifecycle of software development projects. Because they were working and trying to get support from the bottom-up, they needed to be shielded from and unshackled by all the dilbert-esque "pointy haired managers" and their big, bad governance framework with its "evil" waterfall lifecycle.

And in that context, the advice of "just get out of the way and trust us and we promise to deliver working software every 2-4 weeks" is actually a very effective strategy to employ. When management doesn't "get it", their attempts to steer, direct and intervene are often the equivalent of "friendly fire" (which, despite well intentions, still yields calamitous results.)

But Lean comes from a history of a much more enterprise-wide scope, often even using a top-down deployment strategy. So when it asks management to trust and empower workers and teams it expects the corresponding change in its leaders and their leadership-style, and for them to still play a strong, active and participative role with their projects and teams.
Agile teams often get a "bad rap" for having this isolationist attitude toward management. And sometimes that "rap" is warranted. But when the leadership "gets it" and understands and values the "new" paradigm of why+how agile works, and why+how the "old way" didn't, then it probably is time for the leadership to play a different, more active role while still trusting and empowering teams

About the author

Brad Appleton's picture
Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Steve Berczuk's picture
Steve Berczuk

Steve Berczuk is an engineer and ScrumMaster at Humedica where he's helping to build next-generation SaaS-based clinical informatics applications. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

About the author

Robert Cowham's picture
Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.