Enough With Defending Approaches

September 20, 2014 — Posted by Al Shalloway

My banter on twitter about being unhappy with Scrum and the Kanban Method leaving things out is reasonably well known.  I very often exclaim that Scrum should be done within the context of lean (a 10+ year old rant) and that the Kanban Method must attend to teams (which it’s been deemed to be orthogonal too).  When I make my claims I usually hear that “these approaches are designed this way”.  Yet, what I wonder is “why are we concerned about whether something is designed that way or not, shouldn’t we be concerned with what we need to attend to?” In other words why is it designed that way and is that really a good idea?

In other words, instead of defending Scrum when it leaves something out by saying it is designed to be minimal, we should be discussing to what extent we can leave things out and not become simplistic.  Instead of defending the Kanban method by flippantly saying it is orthogonal to whether teams exist we should be asking what happens if we don't attend to teams? Merely saying there’s nothing wrong because it’s designed that way ignores the fact that the design may be faulty.

My own view is that Scrum, Kanban, Kanban Method, eXtreme Programming or any number of team approaches are only point solutions in a larger space of issues.  Instead of arguing for or against a somewhat arbitrary selection (typically chosen based on the belief system of the approach’s creator), I think we’d be better off by looking at principles of software development and seeing how to apply them in our situation. Willfully ignoring a set of principles seems particularly arrogant and risky and likely to cause problems in the future.  Given that we can see patterns of challenges when particular principles are ignored provides evidence that we should consider what we need to consider prior to starting on our transition for improvement.  Always assuming one set of practices applies seems problematic to me.  It’s perhaps unfortunate, but you still have to think. 

I trust people can (think).  I trust that one won’t overload them by providing them with a set of principles which will apply to differing degrees in different situations.  I trust that they can see which ones are relevant and which ones aren’t in their situation.  However, I don't trust them to be aware of all of the issues that are relevant to them or the patterns that emerge from them.  This is because most people haven't seen the scores a Agile, or Lean or Kanban Method adoptions I have. This is not intelligence, this is merely having seen a lot.  That's the beauty of it.  Once the patterns are pointed out, most folks can identify them because they make sense.  When one has only been working at 2-4 companies in the last 10 years, these patterns may not be relevant.  Our approaches should not be reinforcing the myopia that is somewhat put on us by the limited number of companies most people have worked at. Any approach that reinforces myopia has risks that can be readily seen when a cross section of companies doing Agile and Kanban are observed.

Becoming aware of a larger number of issues does not make a process more complex or heavy.  One does not need to do anything if the issue isn't relevant.  But if one doesn't look to see if it is, aberrant behavior may result.  Justifying it with the comment "Agile is simple but hard to implement" may just be a cover for "we're not looking at enough issues." If you’re a consultant who favors a particular approach, I suggest you ask yourself – “truly, why is this set of practices the best in all situations?”  If you are a practitioner talking to such a consultant, I suggest you ask them the same question.

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 over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

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