What is Systems Thinking and Why is it Important?

I’m an engineer at heart. I’ve been trained to analyze problems objectively and come up with well-thought-out solutions. That approach comes naturally to me but it is something that needs to be learned and reinforced. Here’s a dialog I had with my wife that illustrates this:

Wife: I will never buy another *Brand X* washing machine again!

Me: Why is that?

Wife: The clothes don’t smell fresh!

What’s wrong with that picture? People often rush to judgment like that without fully analyzing a situation and/or make a hasty assessment based on some kind of personal bias that’s not very objective. Think about it – in this situation, there are many things that might cause the clothes to not smell fresh so it’s probably premature to blame the washing machine and all models of washing machines built by *Brand X* so quickly but people do that all the time.

“Systems Thinking” is a framework for looking at something as a “system” and understanding how all the components of that system contribute to achieving whatever result it is supposed to accomplish. For example, the process of washing clothes in a washing machine depends on the type of detergent, type of fabric softener, the need to operate the washing machine properly, and the need to clean the washing machine drum periodically, etc. to achieve the desired result of having fresh-smelling clothes. For a more detailed definition of what “Systems Thinking” is, check out this blog post I wrote some time ago:

Systems Thinking

“Systems Thinking” is a powerful tool I learned a long time ago when I first read Peter Senge’s book: “The Fifth Discipline – The Art and Practice of the Learning Organization” in the 1990’s. That has been a very powerful tool for me that I’ve used over-and-over again in many situations.

The practice of systems thinking can be complex – you can use the phrase to refer to a set of tools – such as causal loop diagrams, stock and flow diagrams and simulation models – that help us map and explore dynamic complexity. “For example, systems thinkers often describe the world in terms of reinforcing and balancing processes, limits, delays, patterns of behavior over time, and so forth.” – Barry Richmond, isee systems, inc.

However, Without adding a lot of complexity, a lot can be gained from simply developing a unique perspective on reality – a perspective that sharpens our awareness of the whole and of how the parts within those wholes interrelate. The biggest obstacle to systems thinking; however, is our tendency to over-simplify something that is complex to force-fit it into binary, black-and-white terms rather than trying to understand the complexity of it at a deeper level. My wife’s emotional reaction to the washing machine is an example of that. Her instant reaction was that it must be that *@!# washing machine and I’ll never buy another washing machine like that again!

Here’s an example from a LinkedIn discussion I recently participated in that is more directly relevant to the subject of Agile Project Management:

“Ultimately Project Management is a type X/violent approach to delivery. Where Lean/Agile is a type Y/non-violent approach to delivery”

What’s wrong with that statement? It makes a very broad-based assessment of what “project management is based on some very biased opinions of what project management is and attempts to characterize the whole practice of project management that way. It’s equivalent to my wife’s statement that “I will never buy another *Brand X* washing machine again!”. Anyone who thinks that way will have a very difficult time adopting a true systems thinking approach just as my wife had to adjust her thinking to think about the problem with the washing machine in a broader and more objective perspective. There’s a saying that I think is very relevant to this that says:

“It’s easier to accept a simple myth and move on than it is to take the time to understand complex reality”

As long as people cling on to some of the simply myths and stereotypes that exist about what “project management” is, it will be difficult for them to see “Project Management” and, more specifically, “Agile Project Management” in a fresh new perspective. Another statement made by the same person in the LinkedIn discussion was:

“The term Agile PM is as disconcerting as a Scrum Project Manager”

People like to see things in binary, black-and-white terms and have difficulty seeing the possibility that all project managers might not fit into that stereotype.

I’ve just finished developing a new online training course on “Understanding Agile at a Deeper Level” that includes a module on “Systems Thinking” because I believe it is very important to Agile Project Management. The new course also has a lot of material on the principles and values behind both Agile and Scrum that I think will help people see things in a fresh new perspective based on a deeper understanding of Agile and Scrum beyond just the “mechanics” of basic Scrum practices. This new course will help people take a systems thinking approach to understand Agile and Scrum at a deeper level and see it in a broader perspective of how it fits within a business enterprise as a whole. This new course is in final review now and should be released within the next week. You can view a brief video summary of the course here:

Understanding Agile at a Deeper Level – Video Course Summary

I am offering this new course for a limited amount of time for only $10. You can find information on this offer at the following location:

http://managedagile.com/training-courses/

Advanced Agile Project Management Training

As many of you who have been following my blog post realize, I’m very passionate about closing the gap between the project management community and the Agile community and helping people see these two approaches as complementary rather than competitive. To that end, I’ve published three books on Agile Project Management and I’ve written over 60 articles in this blog site. However, I’m determined to go beyond that and develop an online training curriculum that condenses a lot of that knowledge into a well-organized set of training courses that are easy to follow and understand. There are several needs that I’m trying to satisfy with those courses:

  1. Project Managers – Many project managers are unsure about the impact of Agile on the project management profession as well as on their own career direction.

    [table id=5 /]

    A key objective of the training I’ve developed is to help project managers develop a more adaptive approach to project management that integrates Agile as well as traditional plan-driven project management principles and practices in the right proportions to fit any situation. I do not believe that traditional plan-driven project principles and practices are obsolete and no longer needed; however, I do believe that any project manager who only knows how to do traditional plan-driven project management will be very limited in the not-too-distant future.

  2. Business Managers – Many project managers are a product of the environment that they work in and their organization’s management approach is heavily rooted in a plan-driven approach to project management.
    • The organization expects project managers to take charge of projects and to do whatever is needed to manage and control a project to make it successful. If a project is in trouble or fails, the project manager is the one held responsible. Naturally, that would tend to lead a project manager to take a “command-and-control” approach to managing projects.
    • There is also typically a heavy emphasis on management of project costs and schedules and a project that goes significantly over its schedule and cost goals is likely to be regarded as a failure. That would also naturally tend to favor a “Waterfall” approach where the project locks in the requirements upfront and does not encourage making changes once the project is in progress.

    A project manager who works in that kind of environment will have difficulty developing a more adaptive approach to project management if that isn’t consistent with what the organization expects of him/her. Many of these organizations see it as a binary and mutually-exclusive choice between “Agile” and “Waterfall” and think they have to force-fit their business and projects to one of those extremes and they’re scared to death of adopting an Agile approach for fear of totally dismantling their existing management systems and completely losing control of their business.

    That’s a key reason why I developed the “Making Agile Work for Your Business” course so that project managers who are stuck in that kind of environment can use that training to influence their organization to understand how to fit an Agile Project Management approach to any business environment.

  3. Agile Teams – You might ask, “Why would an Agile team need to know anything about ‘project management’?” The answer to that question may not be obvious but there are several good reasons why Agile teams need to learn how to integrate some level of project management principles and practices into their work.
    • There’s a common misconception that “project management” isn’t required in an Agile project at the team level because you typically won’t find anyone with the title of “Project Manager” at that level. The truth is that there is still a need for “project management”; it’s just a much more adaptive approach to “project management” and the “project management” functions are distributed among the members of the team rather than being performed by one individual with the title of “Project Manager”. Even a developer or a tester on an Agile team has some very basic project management responsibilities for planning and managing their own tasks and collaboratively working with the rest of the team to integrate all of the work of the team around a common goal.
    • Many projects require some level of predictability and control in addition to being Agile. A good example of that is an Agile contracting situation where it is essential to manage a customer’s expectations regarding costs and schedules in addition to being agile.
    • Many people on an Agile team have been thrust into the role that they’re in with little or know training at all. They may know something about the “mechanics” of how to do Agile and Scrum but they typically may have no project management background at all and they may even see “project management” as inconsistent with an Agile development approach. My courses will also help people on Agile teams see this in a broader perspective and learn how to integrate an appropriate level of “project management” focus into their efforts on an Agile team.

The effort required to develop a training curriculum on Agile Project Management to meet these needs has been significant; however, I’m pleased do announce that I can begin to “see the light at the end of the tunnel”.

  • Video Overview – Over the past week, I’ve completed a video that provides an overview of how all the courses I’ve been developing fit together around the overall vision I’ve been developing for Agile Project Management. You can check that video out here:

    https://www.youtube.com/watch?v=4ospxWEnCWg

  • New Advanced Agile Project Management Course – I’ve also completed the outline for the final primary course in this series which will be called “Advanced Agile Project Management”. You can check that out here:

    Advanced Agile Project Management Course Outline

You can find more details on all of my training courses here:

Agile Project Management Training Curriculum

I would welcome any feedback and inputs on these courses and the overall direction and strategy behind them. I’ve tried to take an agile approach to developing this material by taking an incremental and iterative approach to doing the development and relying heavily on user feedback and inputs all along the way.

Modifying and Extending Agile/Scrum

I recently participated in a discussion on LinkedIn that was initiated by someone who suggested several possible roles for a Business Analyst in Agile/Scrum that didn’t seem consistent with Agile principles at all. I believe that Agile/Scrum can and should be modified and extended as necessary to fit the situation, but it has to be done intelligently and I think it takes some skill to figure out what makes sense and what doesn’t.

We all know that there are Agile “zealots” who insist on rigid adherence to doing Agile/Scrum “by the book” without any deviation. On the other hand, there are people who “wing it” and treat Agile/Scrum practices like a “cafeteria menu” where you can pick and choose the principles and practices you want to adopt and which ones to ignore. Neither one of those approaches makes sense in my opinion but there’s a lot of “gray area” between those extremes. So, how do you determine what makes sense and what doesn’t make sense? I don’t think there’s a clear answer to that question but here’s some guidelines that I think are useful.

  • There’s a big difference between:
    1. Taking a proven framework like Scrum and modifying it and extending it in a way that is consistent with Agile principles and practices, and
    2. Just starting from scratch ignoring Scrum and all other Agile methodologies, principles, and practices and attempting to put together some kind of ad-hoc approach
  • There’s an analogy to the martial arts that I think fits pretty well. There are a variety of different kinds of martial arts but they all have some similarity and they all require some level of knowledge, proficiency, and discipline in how they’re practiced to be good at it. You don’t just go out and start doing martial arts without any training and experience to know how to do it. Check out this article I wrote on “Stages of Mastery in Agile”.

    http://managedagile.com/2014/06/13/levels-of-mastery-in-agile/

    It is based on a model of stages of maturity in martial arts called “Shu-ha-ri”:

    http://managedagile.com/2013/07/17/agile-and-lesssons-learned-from-martial-arts/

    The essence of the “Shu-ha-ri” martial arts philosophy is that you should be at a level of proficiency before you start improvising and “improvisation without knowledge and proficiency is just amateurism”. I think that is also very applicable to Agile. It takes a considerable amount of skill to figure out how to modify and extend Scrum and other Agile methodologies to fit a given situation.

The key message is that people shouldn’t underestimate the level of skill it takes to modify and extend an Agile/Scrum approach to fit a given situation. That’s a key advantage of some predefined frameworks like SAFe but, on the other hand, even with some of the predefined frameworks, it takes some skill to adapt an Agile approach to fit a business and there is no “silver bullet”.