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