Friday, June 12, 2009

Agile Self-Organization versus Lean Leadership

Getting back to the agility cycle ... recall that I started with the business agility cycle and used that to derive the software agility cycle. There isn't a great deal of difference between the first two steps of the business-agility cycle and the software-agility cycle, other than the fact that much of the former takes place at a higher-level of organizational management and strategy.

The biggest difference between the two cycles happens after those first two steps. In the business agility cycle we then decide-communicate-act, suggesting that it is the higher-ups who make and communicate the decisions and the lower-end of the organizational food chain (the "worker bees") that execute the organization's strategic solution.

If that seems a bit command-and-control, its because it is (a bit). It's also likely necessary in larger organizations where it is virtually impossible to avoid having 2 or more layers of management. There, the "communicate & act" steps are really the process of providing focus, and communicating objectives and constraints to the knowledge workers, and letting them apply principles of collaboration and self-organization to solve the problem (like in the software-agility cycle).

So 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:
  1. Lean focuses more on flow whereas Agility focuses more on adapting to change (this is true of both software agility and business-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

  2. 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).

  3. 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.

That is not to say that Lean (or business-agility) don'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).

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 (and still enabling self-organization). This is the view that Lean takes toward management, and is a big part of why it is better received by management and is more broadly applicable for scaling agility "up" and "out" in larger enterprises.


Anonymous said...

This stuff links into personality types and organizational types. Eg look-up "adhocracy". Very different from "bureaucracy". Agile fits adhocracy. Toyota blends organizational types into a common modern Japanese form. Many/most Western outfits are "hierarchical" and "bureaucractic".

Another example is China. I'm in China and had to use to reach your blog. 'blog' is filtered here. Very "hierarchical". Yet the chaos on Chinese streets is 'adhoc'.


Willem said...

Often, we assume that the Agile team will work if only management will give it a chance. I think, a key factor of success is an understanding (from the team) of managemment's expectations. If expectations are understood, the transparency you mention would follow naturally. If however, management is not clear in communicating expectations, or the team and management disagree on what these expectations should be, you end up with a management team that is not "getting it".

Ilja Preuß said...

I have the gut feel that the next step in the evolution starts when we stop thinking of self-organization being restricted to teams, when we start thinking about what it means for an organization to be self-organized.

Brad Appleton said...

Regarding adhocracy! Interesting comment. I was thinking more in terms of sociocracy or holocracy, but I see your point.

Willem, I like the way you flip the perspective of the team not "getting it" from the perspective of the mgr (instead of the other way around).

Over on the lean-agile YahooGroup a few people felt I didnt emphasize strongly enough the point that Lean is not just manufacturing/productin these days and takes an enterprise-level view, whereas Agile is still viewed as focusing on the single-software-project (tho Agile is breaking out of that "box" - which is why such comparisons w/Lean are becoming more common)

Ilja, your comment was brilliant! I'll actually be spending several subsequent blog-posts describing some more about the theoretical benefits and attributes of self-organization, such as collective intelligence (a.k.a. "collective mind"), swarm behavior (a.k.a. "swarm intelligence"), social creativity, and group coherence. It will be interesting to see if those shed any light upon the question you asked.

Dave Nicolette said...

Hi Brad,

I think the comparison between lean and agile is a synecdoche. Lean applies to a value stream in its entirety. Agile applies only to the portions of the value stream that involve software development.

In the context of the decide-communicate-act sequence you mentioned, agile software development occurs only in the "act" part of the cycle. This perspective supports Willem's comment about the necessity for a development team to understand management's expectations. That falls into the "communicate" part of the cycle.

There is no "choice" to make between lean and agile. They are fully compatible and they are good for different things. Let's apply them in the areas for which they were intended and for which they work best, respectively.

Agile was always meant for software development specifically, and not as a cure-all for the whole enterprise. If you don't believe me, just ask any of the signatories to the Manifesto. Trying to break it out of that "box" and apply it at the enterprise level seems to me to be just another example of the Golden Hammer fallacy.


Brad Appleton said...

Hi David!

I'm not sure where you got the impression that my blog-post is suggesting taking all of Lean versus all of Agile as some kind of either/or decision or even suggesting Agility as some cure-all at enterprise scale.

Also, the notions of "enterprise agility" and business agility actually pre-date the agile manifesto, so applying agility to the enterprise-level actually pre-dates the general application of agility to the specific context of software development.

Understanding the differences between Agile development and Lean is vital in any attempt to leverage both of them together, particularly if there are any elements of one that seem to conflict with elements of the other (and vice-versa)

The fact of the matter is that it is common to encounter numerous organizational barriers and obstacles to adopting agile, even if only for software development. In any large organization and/or project there are many existing non-software teams and disciplines (both managerial and technical) that will become bottlenecks to achieving software development agility. Putting up "facades" to manage those interfaces may isolate development from them somewhat, but fails to remove the bottleneck or barrier/impediment.

So in order to succeed with Agile software development it is often necessary to resolve these other issues and impediments that fall outside the limited bounds "software development only." This is when we have to look somewhere else for further assistance, and where I'm suggesting Lean has a lot to offer.

Understanding the differences between the two means understanding the limits of the context and boundaries of each to learn where each is most applicable and where they can complement or supplement each other.

Ilja Preuß said...

"applying agility to the enterprise-level actually pre-dates the general application of agility to the specific context of software development."

I wouldn't say that Agile Software Development is just agility applied to software development. It's a name for a much more specific set of values and principles. See

Brad Appleton said...

Ilja! You are absolutely correct. Although software agility did spring out from the general application of business agility to software, it is definitely much more than that. It has fleshed out a lot more "meat" on those bones and has since incorporated many other influences. As such it deserves its own "branch" and is capable of standing alone outside from under the umbrella of business agility.