Day 13 of 100 Systems Thinking From Individual to Organization

May 14, 2013 — Posted by Al Shalloway

Hi everyone.  To pick the pace back up I'm going to write either shorter blogs or, as in today, I will take some previous work and mold it into this work.  I appreciate your patience and will get things going again.

Continuing with the 100 Things You Must Know to Be Effective In Software Development

I believe that one of the essential components of successful Agile adoption across teams is systems thinking. “Systems thinking” is the process of understanding how things, regarded as systems, influence one another within a whole. In software development, this means looking at: product selection, product prioritization, requirements, architecture, design, code, test, quality assurance, delivery, integration, management, HR, and more. In other words, it means looking at the development workflow as a whole. Optimizing one part of the workflow may have no impact overall and can even be harmful to the whole.

Lean offers a particular way to look at the system: the value stream. The value stream is the flow of work from when an idea is first conceived through implementation, deployment and eventual use or consumption. The time from start to finish is called “cycle time.” Lean thinking says that actions that lower cycle time are usually good and those that lengthen cycle time are probably not. Lean thinking looks for ways to remove delays which results in eliminating unnecessary work. This leads to improved quality and lowers costs.

When multiple teams and products are involved, this holistic approach extends to the entire set of projects being worked on. For example, it may be that delaying one project is worthwhile if another project can deliver more value, more than the cost of delaying the first project. This gives us helpful questions for deciding whether to start a new project: “Will this new project add to the value being delivered?” and “Will adding this project slow down or negatively impact the ability of existing projects to deliver value?” 

While systems thinking is essential for scale, it is also useful in the adoption of Agile at the team.  Here's a blog from August of last year that discusses how systems thinking can be useful when difficulties in adopting an Agile method arise:

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?

For more on systems thinking, I highly recommend The Systems Bible by John Gall.

Al Shalloway
CEO, Net Objectives

If you liked this blog please tweet about it by clicking the icon below.

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