Using Dissent to Challenge Our Own Assumptions

March 4, 2014 — Posted by Al Shalloway

There has been a fair amount of discussion regarding Ron’s thoughtful blog on SAFeTM. I want to shift the discussion from what Ron said to what we can learn.  I do not intend to respond to Ron's entries directly.  What I will say is that Ron is very intelligent, very experienced and truly wanting to make a positive difference in the community. He is one of my most respected thought leaders, even though I often disagree with him.  But it is perhaps because I can disagree with him and yet continue the conversation that I regard him so highly.  I have never seen him act in a manner that put himself before the community in the 15+ years I've known him. Not to say that he never got under my skin a few times in years past ;)

Anyway, I think the real issue on SAFe’s applicability lies with some deep assumptions many Agilist’s have.  BTW: From this point on, I am talking in general, not about Ron in particular.   There are four assumptions I find seem to pervade Agile thinking:

  1. Management’s role is one of removing impediments from the teams
  2. One should start with effective teams, then learn how they can coordinate better
  3. Estimation is bad because it will be abused by management and doesn’t provide much information anyway due to uncertainty
  4. While smaller batches are good, these can best be achieved by the team having the ability to pull only what they can work on

While there is evidence for all of these beliefs, I do not believe any of them are inherently true.  BTW: There are several others, I just don’t have the time to consider them all now.

Management’s role is one of removing impediments from the teams.  In 15 years of Agile experience I believe it is just as likely that management will be pro-Agile as teams are.  However, since management often has more power than teams, when they are not pro-Agile, they are a serious impediment to its adoption.  In my mind, management’s role should be one of leadership and guidance.  While we want management to remove impediments, we must not think of their being an impediment.

While “Chicken and Pigs”  as a story has fortunately been abandoned, it was pressured out more due to cultural pushback of people being called pigs, which in many faiths are considered unhealthy.  The root of having that story in the first place is still present amongst many agilists, unfortunately.

Question: How would we act if management led Agile adoption?

Where to start?  Starting at the team level is often not only not really possible, it is often detrimental.  The impediments to Agile may lie elsewhere and their solutions are therefore elsewhere.  We must take a holistic, systems-thinking approach.  We must consider the entire value stream and any impact a pilot has on the remaining organization.  Agile often fails not so much because it is rejected by management, as much as it exacerbates challenges in other parts of the organization without providing any insights for a solution.

Question: Shouldn't where to start have something to do with what our challenges are?

Estimation is bad and useless anyway.  Many argue against estimation because missed estimates are often used to abuse teams.  But that implies management will behave inappropriately.  What if management used poor estimates as a way of getting to the root cause of our unpredictability?  In any event, I believe the biggest challenge with estimation is not the unpredictability of the work, but the unpredictability of the workload the teams making the estimates have.  Working on too many projects has people spend a lot of their time on wasteful work - work we did not estimate for.  They do not have a steady rate of production.  Taking a Lean approach and managing WIP can remove much of this unpredictability.

What’s left then is often due to technical debt.  Tech debt is a serious problem.  And it adversely impacts something business folks want – predictability of rate of delivery.  Hence, high-lighting the challenge to unpredictable estimates can get business stakeholders understanding why tech debt has to be paid down.

Question: Why is estimation bad and what can we learn from that?

Create smaller batches by having teams work in short iterations. While this is a good approach, it is not always the most effective.  Also, if management has not aligned with the teams, it often is not really achievable. Management will often not let the teams work in a real pull mode (e.g., Scrum's pulling a sprint's worth of work) because they are getting too much pressure from the business stakeholders.  Using concepts like Minimal Viable Products and teaching Lean-Flow to business executives and management can take off much of this pressure. Agile often fails because of it.

We can point to the failure of Agile in these cases by saying management didn’t let teams work the right way, but the reality is management didn’t get enrolled in the importance of small batch size.  Eli Goldratt, creator of Theory of Constraints, once said “Often reducing batch size is all it takes to bring a system back into control."  I have seen that managing the program level by creating smaller batches being pulled by the teams to be a much more effective, realistic approach to achieving Agile.

Question: If our teams are overworked, what is the most effective, realistic way of getting their workloads to be more sane?


While debating who is right or wrong is often fun, and often seems important, it is often better to see what the assumptions are behind our arguments and look at them.  Our mindsets create the context for our thoughts.  I suspect many of the assumptions we’ve made in the Agile community are not correct.  At least not all of the time.

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.


Hi Al,

A great post. All of the assumptions you raise are right and also wrong depending on context. Knowing why they are right and why they are wrong is key... To know this is to understand how each assumption was formed and whether each applies....

Human beings are fond of abstracting.... From specific instances we derive generalities... In time those generalities become truths in themselves independent of the concrete instances from which they were derived... This is a common thinking trap.

The map is not the territory... We always need to keep an eye on the actual territory and update our map as appropriate :)


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