Systems Thinking Explained by Chris McDermott

Thinking about software development work being organised as a system hasn’t generally been the default approach taken by business leaders over the past few decades. That is until lean / agile approaches started being talked about.

Traditionally a popular way to build software, especially in large organisations, was to split into teams of specialists. Typically a team of business analysts would specify what would be built, a team of programmers would then construct the specified features and finally a team of testers would check everything worked as specified. A conventional organisation would watch individual team performance, assuming that when the three teams are working optimally, maximum productivity must have been reached. The problem is that maximum productivity isn’t the same thing as maximum profitability and businesses exist to make money not just to have busy workers.

Systems theory embraces the idea that sub activities are interrelated and could be best optimised by studying how all they worked together. In the case of a business, the customers and suppliers become part of the system. Feedback in the form of sales or worker ideas and observations are also part of the system.

Lean / agile approaches like Scrum or Kanban are built on system thinking ideas that have been around for decades and Chris McDermott presents a system thinking overview here and hopefully throws some light on the roots of the lean / agile shift within the IT industry.