Myths I Do Not Believe In

August 10, 2014 — Posted by Al Shalloway

One of my frustrations in the industry is that so many people continue to propagate ideas for which I do not to believe to be true.  Much of the time there is vast evidence to the contrary, but these ideas are rarely talked about on discussion groups.  I’ve even seen their discussion to be discouraged by many. I am sure people’s intentions are noble, but it is poor science to not examine one’s belief systems.  Here are some ideas that I do not believe are true, but which underlie many of our common approaches.  Note, this is not a complete list.  I just stopped after going past 20 myths.  I suspect I could find quite a few more.

Related to Scaling

  1. That just because something works well at the team level it is ok to assume it will work at the team of teams level. Different dynamics and motivations are taking place here – and this assumption is usually wrong.
  2. That a collection of good local changes will result in a good global change.  It is almost certain that several local changes will need to be less than optimal for those involved in order to be optimal globally.
  3. That having an approach that can handle large teams means you are endorsing having large teams. Many organizations have overly large projects.  However, if that’s where they are, that’s often where you need to start.  Merely kicking off a large project does not mean you endorse them, it just may be that with all the complicatedness of the organization’s current solution, there is no other option – and that it is better to start where they are and lean things out than to try to decompose things right from the start.

Systems Thinking

  1. That saying something is orthogonal to an approach is OK.  If it truly is not orthogonal, one will often get poor results.  Unfortunately framework tunnel vision will often not have practitioners of the approach notice what they need to.
  2. That you can attend to only some aspects of project management and expect to get good results. Software development is complex.  This means we must take an holistic approach.  While we don’t need to work on everything, we need to make an initial consideration of those factors that are of primary importance (e.g., workload, work flow order, team structure).
  3. Taking a broad view does not mean you are taking a heavy view.  The scope of your process/method/framework is orthogonal to the heaviness of it.
  4. That complexity means you must start with a subset of your system. Complex systems cannot be decomposed. It is the relationship between aspects of the system that often cause unintended behavior.  Attending to only some aspects of your organization when making changes will like cause additional challenges. Complexity, in fact, means just the opposite – a simplistic approach to organizational development is fraught with risk.

Management Related

  1. Management decisions regarding how to do Agile will always be counter-productive.  Not at all my experience. Unfortunately, anti-management sentiment still runs rampant in the Agile space.
  2. Management’s main role is to remove impediments for teams. While this is definitely one of their roles, management must be proactive and take a bigger picture view and improve the structure within which teams work.
  3. That saying one should not take a bottom up approach means one is endorsing a top-down approach. There are many ways to make organizational transition than bottom-up or top top-down.
  4. That teams must self-organize and learn to work together to create the proper structure for the organization.  A higher view is usually necessary to achieve this.

Resistance to Change and Change Management

  1. That you should always start with evolutionary change.  While you should always see where you are, there are often opportunities to make a significant improvement that most everyone will accept as being a good place to start.  Not doing so runs the risk of motivation running out due to the improvements not working against the structure of the organization.
  2. That you should always start by managing flow and feedback loops.  There is no one-size fits all.
  3. That people resist change.  Resistance Is Not to Change.  Assuming that all change will be resisted is simplistic.
  4. That one approach is best in all situations. While I know everybody says that “one-size does not fit all” look at how many consultants promote only one approach.
  5. That one must get teams in an Agile manner before attempting to get them to work together.  Creating the structure within which teams can work together in an Agile manner often helps them learn Agile faster.  See Challenging the Assumption That One Must Get Teams to Work First.

Technical Issues

  1. That doing it right the first time takes more effort.  The right approach is often faster than hacking things in.  Admittedly, one needs to know how to use design patterns and test-first to achieve this

Lean Related

  1. That adding Lean practices into a non-system thinking approach makes the approach any more lean. Lean is a mindset based on systems-thinking.  While you can add lean-practices (e.g., managing WIP) that does not make the approach you are using Lean unless you have a Lean mindset to begin with.
  2. That if you are not focusing on people then you are not valuing them.  Sometimes the best way to manage something is to attend to the factors that affect it.  One can often best demonstrate a respect for people by making the environment within which they work better.  Creating an environment for trust is better than merely having conversations about it.  In the same way that focusing on cost reductions often results in high costs, focusing on people directly often is less effective that attending to other issues.

Team Related

  1. That you should always have cross-functional teams. While cross-functional teams are good they often are not economically viable. When subject-matter-experts (SMEs), architects, those knowledgeable of legacy code, or just otherwise smart folks are scarce, it is often too expensive to train others or acquire them.  In any event, it is often not needed to have a special skill on a team for the life of a project.  This is especially true for projects that have UX and database issues.
  2. That self-organization is what makes Scrum work. Scrum works because it manages flow implicitly through cross-functional teams and time-boxing.  See Why Scrum Works and How This Tells Us When It Won’t.

If you are looking for help and agree with me that these are myths, let me see if we at Net Objectives can help.  We have proven approaches that does not buy into any of these.  The challenge with adopting approaches that have these embedded in them is that the damage done by these underlying assumptions is usually not noticed.  What happens is that progress is just not made and you are often accused of just not doing things right.

On the other hand, if you don't agree with these, then please discuss them with me on the Lean-Systems Society Linkedin Discussion Group.

Al Shalloway
CEO, Net Objectives


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?

I find these sentences confusing:

"Management will not always make bad decisions. Unfortunately, anti-management sentiment still runs rampant in the Agile space."

By saying this, are you stating that first sentence is a myth and the truth is that management *will* always make bad decisions?

thanks. meant to say the myth is that management will always make bad decisions. fixed it.

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