“That is, while there is value in the items on the right, we value the items on the left more.”
A number of reviewers suggested (in good faith) that I use “Lean”
instead of “Agile” in the title of my book (Agile IT Organization Design) in order to improve its marketability.
Apparently, Lean is in whereas Agile is jaded. However, the strong people-orientation
credentials of Agile are core to the solutions I propose. I’d like to expand on
this and some other reasons in this post which is also meant as a defense of
Agile over Lean when it comes to organizational transformation in digital and tech organizations.
Lean is great. Lean techniques emphasize waste avoidance,
limiting work-in-progress, continuous improvement and caring about whole value stream optimization. I advocate
these things in various chapters in my book. However, organizational agility needs
more than process optimization.
People Orientation
When taken beyond development teams to organizational levels, the Agile principle of “individuals and interactions over processes and tools” actually has a bearing on the org chart, and the metrics and tooling regime. This may not be evident at first but I go to great lengths in the book to bring it out. For example, a matrixed IT organization demands more process in order to co-ordinate between the arms of the matrix than a product or capability centric org structure. Similarly, the Agile principle of “adapting to change over following a plan” has a bearing on how governance teams function, not just Scrum masters. Agile thus provides a sound base of attitudes upon which Lean techniques can be exploited.
People orientation is an aspect of an organization’s
culture. In his excellent Agile Survival Guide,
Sahota examines Lean and Agile through the lens of Schneider’s culture model. This model
classifies an organization’s culture on two axes—content (what-is vs.
what-might-be) and process (people-first vs. company/policy-first), and names
the four possible combinations as competence, control, collaboration and cultivation.
Sahota argues that collaboration and cultivation cultures are Agile-friendly
whereas control and competence cultures are Lean/Kanban-friendly. I find Sahota’s
argument convincing and from this perspective, the overall approach is my book
is clearly Agile.
Software Development isn’t Production
This is another reason why I think Agile has to be the foundation rather than Lean. Software development is a design process rather than a production process whereas Lean has its roots in the Toyota production system. If we are to draw parallels to manufactured goods, software development resembles the product development phase more than the manufacturing or production phase. Chapter three of Agile IT Org Design explains further.
Applying Lean manufacturing principles wholesale to software
development runs the risk of planting false metaphors of production in the
minds of IT managers. In the book, I argue that the average IT manager’s
fixation over predictability and relative disregard for actual benefits (value)
partly stems from this false metaphor. Metaphors are powerful because they can
be generative and
therefore it is important to get them right.
Data-Driven Illusions
Advocacy for data-driven decision making is at an all-time high following the success of the Lean Startup book and its numerous offspring. However, it is somewhat naïve to believe that a culture of HiPPO (Highest Paid Person’s Opinion) decision making can be overcome by prescribing new formulae like cost-of-delay, for example. Prioritization is a political exercise in any organization of more than say, ten people. Students of history, geopolitics and current affairs will agree that politics trumps data.
Formulaic,
data-driven solutions for better decisions operate on the wrong side of “individuals
and interactions over processes and tools”. In the chapters on accountability
and metrics in Agile IT Org Design, I describe solutions that acknowledge politics, that
continue to stand by “individuals and interactions”, and that are data-informed
rather than data-driven.
Label Abuse
Some claim that “Agile” is a much maligned label and therefore it makes sense to move on to less discredited labels like “Lean”. But Lean has its own share of misinterpretations and misapplications. This post, for example, argues well that “Lean” has become synonymous with efficiency and layoffs. People tend to think of Lean as being the opposite of fat. It isn’t widely understood that capital-A Agile and capital-L Lean have only a limited semantic overlap with their common English counterparts “agile” and “lean”. Otherwise interesting debates have been framed poorly as “Lean vs. Fat”.
There will always be cases where people blame their wrong
extrapolations on the book. The Lean Startup devotes less than three pages to describe
product/market fit. However, this doesn’t stop people from claiming that they failed to achieve
product/market fit despite following the book’s advice. Label abuse is no reason to jump ship.