One Size Doesn't Fit All, But Perhaps One Mindset Does

January 27, 2013 — Posted by Al Shalloway

I keep hearing people discussing whether they should do Kanban or do Scrum as if one might be inherently better than the other.  While, I do believe comparing and contrasting the mindsets of the two promotes good learning, the question is often asked in comparing the practices of the two.  Comparing practices without understanding the differences in mindset is not necessarily going to lead to great results.  Two of the common mindsets in the Agile space today are classic Scrum and Lean (Kanban fits within the Lean mindset). It is worth considering the differences between these.

Classic Scrum Mindset. Set teams up in a functional structure (cross functional teams with a product owner and Scrummaster) and let them figure out how to be effective. Anything in their way is an impediment to be removed. Keep doing this until the entire organization is effective.  Scale by considering the organization to be comprised of teams of teams.

Lean. Take a scientific approach to learning with an aim towards continuous improvement.  This requires attending to the workflow, explicit policies, visibility of work (including the vision of what is to be happening).  Improvement is based on improving the delivery of the highest business value.  This is achieved by removing delays in the workflow which is achieved by smoothing out the work load.  Options include using Kanban to manage WIP and managing backlogs to get the right people working on the right thing at the right time - but the focus is on flow. One must also take a systems thinking approach (in particular, avoid the fundamental attribution error http://en.wikipedia.org/wiki/Fundamental_attribution_error).  It is critical to attend to the human psychology of change to determine how much change the organization can bear at the start.  If this is little, use the Kanban method to manage the transition. If more is possible, do what you can. Decide to use iterations and cross-functional teams if it makes sense.  One of the motivations to do so may be that they will force discipline and visibility on what is happening (i.e., this mindset may suggest doing Scrum).  Achieve agility at Scale by including the entire value stream (i.e., the workflow from the point of origin of the idea until its consumption), i.e., taking a holistic approach.

The Essential difference. In classic Scrum the idea is to expose impediments by having teams work in a manner that makes them readily apparent.  You put people between a rock and a hard place where they have to solve the problem.  Unfortunately, many opt out by doing "Scrum but" (i.e., we do Scrum but we don't do this).  This, of course, isn't doing Scrum.  In Lean, you are given a model of what you need to do - deliver value without delays in the workflow.  You can start where you are or you can do some initial change at the start if that's desired. Improvement is made by removing delays in the workflow of achieving value delivered.  Scrum follows this model as well, but implicitly, Lean says to follow it explicitly.

One thing to note is that the Lean mindset has you attend to more things.  It is not a simple framework. I believe this is why Scrum is often more popular - it is easier to do (although not necessarily easier to be successful with).  When you get off track with it, it tends to continue getting more off-track (the infamous Scrum-but).  Lean affords a way to look at and solve your problems.  It does not demand a certain structure as much as a certain result. Focusing on the result (faster delivery of business value) provides clearer insights into achieving it.  It is interesting to note that the Lean mindset will suggest Scrum at times (although always within the Lean model) while classic Scrum will never suggest Kanban (no iterations) or gradual change if don't already have cross-functional teams.

To be clear. I'll admit to getting tired a little of being accused of bashing Scrum because I say it won't work everywhere. At Net Objectives we've been doing Scrum for 14+ years. We still introduce it at companies and help organizations having troubles making it work or scale for them. However, we don't take a 'one size fits all' approach with it that we see all too often.  We suggest it when it makes sense. We suggest Kanban when it makes sense.  We suggest hybrid methods when it makes sense.  What I do bash is assuming one approach works everywhere - that tends to result in simplistic thinking.

In conclusion. Software development has many facets - human psychology, dealing with organizational change, different motivations of the business stakeholders, management and the teams, technical issues (architecture, design, code, test), the laws which effect development (e.g., delays increase work) and more.  To assume a simple framework will solve a complex problem tends to put a severe burden on all but the most simplest of development problems (e.g., one, co-located team).  Doing Scrum within a Lean mindset can be quite powerful because enough attention is being played to the more complex organizational issues while Scrum works well at the team.  The point is one must look at one's mindset and see what cases it can handle well.  If it is skewed towards are particular solution space you will find patterns of challenge. This is an indication that you might want to expand your mindset. I believe one of the reasons we see patterns of challenge in our industry is that the classic Scrum mindset is insufficient for complex organizational problems yet is being applied indiscriminately.  Fortunately, one can do Scrum within the Lean mindset - so if you don't want to abandon your Scrum efforts but need to improve them, you can do so by adopting a Lean mindset.  Don't worry about what one calls what you do, worry about if you have the proper mindset and if the practices it inspires actually solve your challenges.

Al ShallowayCEO, 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.



        

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