The Power of Systems Thinking

August 31, 2012 — Posted by Al Shalloway

At Net Objectives we’ve trained tens of thousands in Scrum and Kanban.  We don’t really play sides in which method we use.  Our own experience is that hybrid methods are typically needed in large scale transitions – which is our specialty.  Regardless of which method our clients employ, we always suggest a system-thinking approach within the context of Lean-thinking.

Lean-thinking is actually a kind of systems thinking.  It suggests that most of the problems that are encountered are due to faults in the system.  That we should not blame people for errors, but rather look to see how the system they are in is working. 

A variant of this would be to look how a systems thinker would approach the problem of Scrum-but and Kanban-but. As an aside, I want to point out the Kanban community discourages the use of the term Kanban-but since it focuses on the people aspect of not doing Kanban. Systems thinkers would also  discourage the use of Scrum-but as a derogatory term for the people not doing Scrum properly.   He wouldn’t suggest that people are doing Scrum-but because they aren’t motivated enough, he would ask “why are they not doing Scrum properly?”  Is it they don’t understand the benefit of the Scrum practice they are not doing?  Is it that it would be too difficult to do it? What is it about Scrum itself that contributes to these challenges? 

By focusing on the system, we avoid putting the blame on the people.  Now it may be that the people aren’t motivated enough.  But as soon as you draw that conclusion, you have lost all power in helping them.  It is one reason the Fundamental Attribution Error is so deadly and being aware of it can be so powerful.  Regardless of whether the judgment is true, once it has been made there is little that can be done.

Instead of finding what is wrong with someone that is not doing what they are supposed to, systems thinkers look for what the people experiencing challenges are looking at (or not looking at) that has them make poor choices. We assume they are a good, intelligent, motivated person looking at the wrong things and therefore making bad decisions.  Not that there is something wrong in their character such as a lack of motivation or persistence or courage.

In software development, the “system” is often the workflow they find themselves in.  In other words, if we’re talking about a developer, when do they get the opportunity to talk to customers, to testers?  Do they get requirements and the validation for these requirements at the same time via Acceptance Test-Driven Development or not?  These are choices often outside of their control.

My suggestion is that if you are using a method that has a common set of challenges, that perhaps one should look at modifying the method to avoid the challenges instead of trying to motivate your people into putting more effort into overcoming them.  I’m not suggesting motivation isn’t important – it is. And sometimes working harder and having more courage is the only route to success available.  But my experience is that people in this field are very motivated.  The question is, how can we best take advantage of that motivation?

 

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