The Real Reason the “Agile Wars” Are Destructive – It’s Not What You Think

This was originally published in June, 2014

I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Buckminster Fuller

I’ll admit, in the last few years the community has gotten somewhat divisive and I dislike the personal attacks that have been made. I have no problem with the attacks on people’s approaches – I like disparity in thinking – it is how one learns. Many in the community dislike even this, however, asserting that “we should all get along” as if we are in this together.  I do not think we are. People in the Agile community do not have the same goals, are not in the same roles and, more importantly, have considerably different beliefs, mindsets and, I’d venture values.  I do not agree with the assertion of those that say the Agile community is defined by the Agile Manifesto.  If it’s not absurd enough to say that 17 people could define a community that must number millions by now, I believe it’s absurd to keep referring to a 13 year old document that defines a community that believes in adaptation and not looking too far out in the future.

I’ve been in the agile space for over 15 years.  I’ve seen ideas come and go.  The idea of agility predates the Agile Manifesto by many years (e.g., Lean-50+ years, OODA 25 years).  Agile is far from homogeneous and to many of us, as originally defined in the Agile Manifesto, not a target. We at Net Objectives have long said that “Agile is about the incremental delivery of business value not team iterations.”

This business focus is necessary to achieve Agile at scale (a considerably different attempt than scaling Agility).  Agile at scale requires looking at several things.  Unfortunately, the two most popular methods (Scrum and LKU’s Kanban Method) are insufficient for a variety of reasons. Many have noticed that neither are sufficient in themselves so we hear talk about creating hybrids and considering them different tools in a toolbox.  However, this focus has us look to how we can combine Scrum and the Kanban Method.  It creates a focus on practices and approaches and takes us away from what we should be looking at.

What we should be looking at is the principles on which these approaches are based.  Actually, more than principles, they are based on what I call laws of software development.  These “laws” affect software development in the same way gravity affects bridge design.   Some of these are:

  • Working on too many things causes delays
  • Delays in workflow and feedback creates extra work
  • Cross-functional teams improve collaboration and make it easier to manage delays in workflow and feedback
  • A focus on local optimizations will not result in a global optimization
  • Too much change results in fear and resistance
  • The system one works in has a significant effect on one’s effectiveness

Scrum is a partial and implicit manifestation of Lean.  The Kanban Method is based mostly on the Theory of Constraints, using pull as a control mechanism.  Both approaches tend to ignore significant aspects of human psychology and organizational development .   My point is, the damage of the “Agile wars” is not that they are divisive, but that they have people focus on the practices of the approaches and not the principles on which they are based.  Furthermore, we tend not to look at principles which both approaches ignore.

At Net Objectives we’ve long recognized that practices only apply in particular contexts.  Scrum is great in many places (although it always benefits from a deeper understanding of Lean by incorporating work in process – WIP – management and explicit policies).  Kanban Method also is a great “last resort” when change can’t be readily made.  But in reality, the initial focus should be on “where am I and what approach will work better to get the results we want.”  This is a result based approach, where we look at what we are trying to achieve by looking at our current workflow, culture, abilities, available skill sets, work to be done, and more.

We have been elaborating this in our Lean-Agile Team courses for some time now.  The following table is an example:

Outcome to Achieve Scrum Kanban Method What to Do
Coordination with other teams Time-boxes Uses cadence Use time-boxes or cadence
Collaboration within team Cross-functional teams Ignores/insufficient Create teams to the extent possible
Team in synch Daily standup Visual Control, daily standup Visual control, daily standup
Reality check Things must be done at end of the sprint Cycle time

Insufficient

Manage explicitly
Developer / tester relationship Skills, but not roles

End of sprint checkpoint

insufficient Time-boxing OR discipline with small stories

ATDD highly recommended

Predictability of work done Estimation and velocity

insufficient

Insufficient Estimation and velocity, Manage interruptions, Reduce technical debt
Smooth transition insufficient Can control rate of transition Use MBIs, sequence work, create teams when possible, use ATDD
Reduce Technical Debt Use XP style technical practices Ignores Use test-first methods (ATDD/TDD), Continuous integration, Emergent Design
Finish stories quickly Time boxes, small stories Insufficient Time boxes OR discipline to complete stories quickly
Minimal delays in workflow Cross-functional Teams

Use small stories

Manage WIP Cross-functional teams, Manage WIP

Use small stories

Short feedback cycles Use small stories

Product owner and cross-functional teams

Manage WIP

Insufficient – requires discipline

Use small stories, Manage WIP

Product owner and cross-functional teams

Balanced workload Pull work based on velocity Manage WIP Pull work based on velocity

Manage WIP

One could use the table above to create a “hybrid” that works for them.  But it’s not really a hybrid because most of the suggestions do not come from either method, but from the principles of Lean.

We should stop looking at solutions that solve certain problems and start looking at understanding why they work.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.