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

June 13, 2014 — Posted by Al Shalloway
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


Kanban Method

What to Do

Coordination with other teams


Uses cadence

Use time-boxes or cadence

Collaboration within team

Cross-functional teams


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


Manage explicitly

Developer / tester relationship

Skills, but not roles

End of sprint checkpoint


Time-boxing OR discipline with small stories

ATDD highly recommended

Predictability of work done

Estimation and velocity



Estimation and velocity, Manage interruptions, Reduce technical debt

Smooth transition


Can control rate of transition

Use MBIs, sequence work, create teams when possible, use ATDD

Reduce Technical Debt

Use XP style technical practices


Use test-first methods (ATDD/TDD), Continuous integration, Emergent Design

Finish stories quickly

Time boxes, small stories


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.

Related Blogs

Agile Manifesto

Kanban Method





Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



A couple things occur to me about your blog topic:

(1a) Of course, this blog won't make such wars go away. Too many agilists already believe in immutable processes oir details of those processes (which many other agilists - sometimes even the same ones - decry as an anti-agile pattern) already
(1b) Too many agilists don't include context in their defense of their particular take on details of agile processes - and often that makes ALL the difference

- AND [Changing gears here]

(2) Your declaration of "Laws of Software Development" are fine, but in essence the complexity underlying the agile implementation details to support these laws argues for the need of well trained and experienced Agile Coaches in any [major] agile implementation which is seeking to determine "best fit" for context in their particular needs.

That's also fine if a given company wants to go "All In" and try and get things right in a "Big Bang" approach so to speak, ASAP. But I still think there is a place for small, growing "spots of {a particular flavor of] agile" at the bottom of hierarchies, for those organizations with the right degree of "openness" to this kind of change and experimentation, whereby the ground floor workers learn on their own and craft and continue learning, spreading agile outwards and upwards.

I don't agree my statement on  complexity argues for the need of well trained and experienced agile coaches.  I think it argues that people have to be holistic.  People can see the truth of the laws i mentioned for themselves.  I think people following approaches (Scrum/Kanban Method) that provide incomplete sets of practices require more consultants as things are being left out.

Also, my mentioning laws of software has nothing to do with whether one goes all in or one starts small.  The laws exist regardless of what you chose to do.  The laws may tell you to go small in your situation. 

I would suggest you have tied attending to the reality of the complexity of software development and 'going big' together.  The fact that things may be complex does not argue in any way about how to approach things except that one must take a more holistic view in whatever they do.

I am not sure you are saying this, but it sounds like you are mirroring exactly the notion I am trying to stamp out - that complex systems are big and we can't understand them so we must start minimalistically.  Correct me if I am wrong here (about your thoughts).  I think complexity does not mean we should only look at part of a system.  It means we must look at the whole, or - because it is complex - we will miss relationships and even if we start small things won't work as intended.

Generally, I agree... there is a big wave of cargo-cult Agile going on, and a lot of arm-chair organizational change architects.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban