Incongruities of Agile

February 9, 2018 — Posted by Al Shalloway

Words are important. It's how we frame our thinking. Being careless with them has adverse consequences. As I continue to write up FLEX I continue to see things in the Agile space that are incongrous, some flagrantly so, some to a lesser extent. Many of these apply because of Agile's beginnings as a method to be used for a team working on a project. I am writing this because there is so much dogma in the Agile community now that I am hoping people will start to question what they are being told.

I believe these quotes set the stage for what I am attempting to accomplish:

  • Dogma - persistently working towards a goal without ever questioning the methods being used.
  • Persistence - dogmatically working towards a goal without ever being committed to which method being used.
  • Whatever we don't challenge will become an impediment eventually
  • The task is, not so much to see that which no one has yet seen; but to think what nobody has yet thought, about that which everybody sees. Shopenhauer
  • It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so. Mark Twain
  • 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. Our brains deal exclusively with special-case experiences. Only our minds are able to discover the generalized principles operating without exception in each and every special-experience case which if detected and mastered will give knowledgeable advantage in all instances. Because our spontaneous initiative has been frustrated, too often inadvertently, in earliest childhood we do not tend, customarily, to dare to think competently regarding our potentials. We find it socially easier to go on with our narrow, shortsighted specialization's and leave it to others primarily to the politicians to find some way of resolving our common dilemmas. Buckminster Fuller.

I am going to start just listing them out and add more detail on request or as I have time.

No role for business analysts in Scrum.

Calling managers pigs in Scrum. The implication that managers are not committed to the project is absurd and disrespectful, as is the label itself. The attendees for the daily standup should be defined as for those doing the work, not to those committed to the work.

Adding Lean as an adjective to what is being proposed but then not taking a systems thinking point of view. The two most fundamental tenets of Lean are leadership (including via management) and systems-thinking.

Saying the Product Owner is the "one wringable neck." We need to be striving for safety.

Having the title "ScrumMaster" applied to a person whose role is really being a coach.

Saying "Scrum is simple, follow it as is." Agile is about thinking for oneself, not to be following some pre-defined method.

Using The New New Product Development Game by Hirotaka Takeuchi Ikujiro Nonaka as the basis for Scrum and to some extent Agile, while not just ignoring the article Toward Middle Up Down Management: Accelerating Information Creation, written only 2 years later by one of its co-authors (Nonaka), but by taking a contradictory view of it.

Thinking any approach designed for a particular context (e.g., the team level) will naturally apply to higher levels in an organization. This is incongruous because team dynamics are different from inter-team dynamics which is different from management dynamics. Taking a one-size fits all approach strikes at the heart of Agile where one should attend to what works and not preconcieved ideas.

Requiring people to change the titles of their current roles in order to use the approach being espoused. This is a lack of respect for people. Many organizations have a career path for their existing roles and changing role titles can be scary for people without a clear path forward. Taking the attitude that specific Agile roles should be created is also somewhat arrogant as there is no one size fits all so requiring specific roles to be adopted by HR to get around the first issue is akin to saying people must follow the approach provided.

Not specifying where an approach fits. There is no one-size fits all.

Not trying to pick on Scrum it's just those are the ones that have come to mind. I can't remember, at the moment, the other dozen or so that have flashed through my mind over the last weeks. I'll write them down as they come back to me.

Al Shalloway

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.


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