Demystifying Change: Agile, Lean, TOC, Systems Thinking & 6-Sigma (Part II)



In this short series we’re demystifying the differences between common change methodologies including Traditional Change Management, Agile, Lean, Theory of Constraints, Systems Thinking and 6-Sigma.

In Part I we looked at the big picture and highlighted 16 different aspects. In this article we’ll introduce the six methodologies in more depth, explore their key facets and compare their different objectives.


Let’s remind ourselves about the six different methodologies:

Aspect

Traditional

Agile

Lean

Theory of Constraints

Systems Thinking

Six Sigma

Objective

Deliver on Time and Budget

Deliver Value Early and Often

Maximise Flow of Value

Maximise Throughput

Service Demand Perfectly

Maximise Quality & Predictability

Example Method

Prince2, PMBOK, CMM, ISO9000

Scrum, XP

Kanban, Toyota Production System

Theory of Constraints

Vanguard Method

Motorola 6-Sigma, TQM

The first thing worthy of note is that the different methodologies actually have different objectives. You might say they are all trying to deliver the project, product or service in question, and you’d be right, but they differ in the objective they use to do it.

As we go through them, we’ll make use of Dave Snowden’s Cynefin Framework to understand which environments are suitable for each.

I want to highlight through this series that this isn’t about which methodology is best – it’s about how they vary, where they work and why. I’m a firm believer that there are useful tools in each of them and it is never about EITHER/OR, but always about how best to combine them.

Traditional Change Management


It's not as complex as it can sometimes seem!

Traditional change management is principally concerned with scope, time and budget. Quality plays its part, of course, but not often as a primary driver – the solution need only be of sufficient quality so long as we deliver the scope on time and on budget.

The main weaknesses of this approach are two-fold:


1. It makes the assumption that we can know the exact scope, time it will take to deliver and budget required at the beginning of the project.

2. It encourages an up-front-planned sequential flow (waterfall) of overlapping tasks.

(1) is plainly false – we know the least at the start of the project and as we progress we learn more. As the project progresses the invalid assumptions about scope, time and costs start to hinder progress more and more, e.g. it becomes more important to “stick to the budget” than to deliver the best solution and change-control becomes a big issue.

(2) leads to big projects lasting many months and expensive up-front planning efforts which are largely redundant (thinking harder at the beginning of the project doesn’t make your estimates any better). Coping strategies are largely distorting – e.g. let’s pad the timescale and budget generously with lots of contingency.

Traditional management approaches are heavy with bureaucracy, document-check-and-audit control processes and tend to lead to a proliferation of management roles. Work is divided up into different functional specialisms and managed separately for each specialism.

Thinking harder at the beginning of the project doesn’t make your estimates any better

In theory plans are continuously updated, adjusted and changes neatly controlled. But in practice this is huge amount of effort and it is expensive, slow and painful for a large project.

In Cynefin terms, Traditional Change Management is suited to Simple or Complicated systems and problems where predictability is high. Given the extremely high costs of change, it is unsuited to Complex or Chaotic situations.

The record of traditional change management processes is extremely poor, particularly in IT as highlighted long ago in the Standish Group Report.

Agile


Agile approaches take a different tack. They focus on incremental and iterative delivery.

The goal here is to deliver a (part-)completed solution early and often. This embraces the value of feedback as a learning mechanism. We only know if we’re delivering the right solution when we have real users using it and giving their feedback. So let’s get to that point as quickly as possible.

In this model we care much less about scope, time and budget. The philosophy is that if we repeatedly deliver the most value we can then we are, by definition, doing the best that can be done.

The effects of Agile are to maximise learning, increase control and significantly reduce risks by delivering parts of the ultimate solution very early in the process

Capital equipment aside, the costs of an agile team are relatively predictable and principally involve the headcount. Over time new teams get a track-record of delivery that allows predictions to be made about how much scope can be delivered by when.

The effects of Agile are to maximise learning, increase control and significantly reduce risks by delivering parts of the ultimate solution very early in the process. The final solution becomes simpler, easier and cheaper than the traditionally-planned alternative precisely because it evolves with feedback as it is built.

However, with Agile techniques the scope of change is explicitly variable. Early on an Agile team can often say very little about how much time or what budget will be needed to deliver a completed solution nor what that solution will look like. As the team gains experience through incremental delivery then estimates of time, budget and form become progressively easier and more accurate.

It should be obvious that no method can ‘guarantee’ delivery of a specific solution by a specific date and cost since the future isn’t perfectly predictable. Because this is the (wrong-headed) premise of Traditional Management, it drives all sorts of costs and waste (e.g. padding, contingency, over-estimating) that Agile teams explicitly avoid.

The most common Agile approaches have been developed for IT teams and don’t concern themselves with the wider needs of business beyond the engineering of each product

There’s an honesty about this approach which can be very troubling for traditional change managers (or anyone steeped in traditional management). There can be a fundamental misunderstanding of why it isn’t possible to provide an up-front guarantee of what by when and at what cost.

Agile approaches can struggle in these environments, appearing less controlled and concrete than traditional methods. This isn’t helped when Agile evangelists advocate zero planning and no forecasting of final completion dates and costs.

The most common Agile approaches have been developed for IT teams and don’t concern themselves with the wider needs of business beyond the engineering of each product. For example they have little to say on how to understand which features are valuable, how to prioritise to deliver the most value soonest and how to integrate Agile working beyond the IT team.

In Cynefin terms, Agile is well suited to Simple and Complicated systems and can function to some extent in Complex environment. The use of short-timescale iterative working allows for sudden changes in direction and is good at absorbing change. However, techniques that depend heavily on up-front estimation of tasks (such as many real-world implementations of Scrum) will struggle when cause and effect are not predictable.

Lean


Lean methodologies come originally from manufacturing, with the classic example being the Toyota Production System (TPS). Decades of optimising assembly lines have lead to a family of tools and approaches that aim to minimise waste and optimise the flow of work.

Today, Lean methods are increasingly applied to product development and service delivery. Don Reinertsen’s Principles of Product Development Flow is a good example.

Lean is a ‘Pull’ approach. All work items are prioritised and when one task is complete the team ‘pull’ the next one off the list

Lean uses neither a planning-based approach (like traditional management) nor an iterative approach (like Agile). Instead it considers all work as a continuous flow of tasks going through a series of steps. The goal is to optimise this flow so that work can proceed as smoothly as possible.

Both Traditional and Agile management methods are normally “Push”-based. Prior to starting the project or iteration/sprint, teams pre-agree a list of work items that they will aim to deliver by the end. By contrast, Lean is a “Pull” approach. All work items are prioritised and when one task is complete the team “pull” the next one off the list.

Lean methods include tools such as Value Stream Mapping which are used to map out the process steps and both illustrate and understand how much work of different types in the system. This data helps design both visual representations (e.g. Kanban Boards on the walls) and targeted improvement efforts.

Lean’s main improvement focus is to eliminate waste. There are many possible forms of waste including delivering the wrong things (misunderstanding value), wait waste and busywork. Lean teams work to identify problems in the flow and progressively eliminate waste. They utilise tools such as Work-In-Process (WIP) limits to manage the flow.

The use of visual management through representing work on the wall live enables simple measures that can be used to quickly understand if change is an improvement. Examples of these are Cycle Time, Lead Time and % Right First Time. This visual approach isn’t specific to Lean but is emphasised much more than in other methods.

Lean’s ability to map the existing work and incrementally improve it can be an advantage (some advocate Kanban over Scrum for this reason), though the flip-side of this is that discipline through deadlines isn’t enforced for you – so with Lean methods the team need to be serious about measuring their performance and improving it every week.

Lean teams work to identify problems in the flow and progressively eliminate waste

One of the weaknesses of Lean is that it assumes that the whole system of work is predictable. In terms of Cynefin, Lean assumes that processes are either Simple or Complicated and can be modelled as relatively simple flows. To a first approximation this is often true and useful to do, but it can be a trap if the target is moving.

Teams operating in a Chaotic or Complex environment can find Lean tools ineffective because the past is no guide to the future, hampering improvement efforts. To be fair, this is also true of Traditional management and Agile methods, but in the case of Agile iterative working may better deal with complex and emergent behaviour because the focus of each iteration and increment can shift significantly. In the face of Chaotic systems, all of these approaches fail.

Theory of Constraints (TOC)


The Theory of Constraints is a management theory that every system of work is limited by a set of constraints and at any one time there will normally be a single dominant constraint that limits performance. TOC then provides tools to identify, improve and eliminate those constraints.

TOC’s main goal is to maximise throughput on the basis that doing this will maximise the productivity of the business and therefore best serve business goals

TOC’s main goal is to maximise throughput on the basis that doing this will maximise the productivity of the business and therefore best serve business goals. TOC does this by identifying the dominant constraint, first finding a way to improve its throughput and then working to eliminate the constraint (rather than simply limit the amount of work in that area as Lean methods might). It provides tools such as Five Focusing Steps and Drum-Buffer-Rope to work on each constraint.

One of the differences between TOC and Lean is that teams using TOC will often temporarily increase waste upstream of a constraint in order to have the constraint perform better. This can increase delays with the benefit of better throughput, making a different tradeoff to Lean which will always favour reduced delay over throughput. Which approach is best all depends on the nature of the work.

TOC also includes a suite of tools to map the current system (Reality Trees), work out which problems to tackle in which order (Thinking Processes, Stategy/Tactic Trees) and to identify and resolve conflicts (Evaporation Clouds). As will all of these different methodologies, many of the tools and concepts within TOC are compatible with other methods and can be usefully used within Lean and Agile settings.

TOC is also the only one of these methods to provide a comprehensive system of accounting: Throughput Accounting

TOC is also the only one of these methods to provide a comprehensive system of accounting: Throughput Accounting. This considers inventory as a liability that ties up cash (not an asset) and drives increasing throughput (sales, output) over cost-cutting, because cost-cutting is inherently self-limiting and can permanently harm the ability of an organisation to deliver.

By focusing on the bottom-line of the business, TOC has a wider scope than Lean and Agile approaches. However, higher throughput is not always desirable nor possible, so it is important to understand when TOC is suitable. Just like the other methods, in the face of a Chaotic or Complex system TOC can struggle because it assumes a level of predictability that may not exist.

Systems Thinking


Just as TOC concerns itself with a bigger picture, so does Systems Thinking. With Systems Thinking the important focus is to understand the whole system of which the solution and customer is part, starting by focusing on customer demand. Specific approaches, like the Vanguard Method include tools to map and track demand.

Typically demand is split into two types: Value Demand (which provides value to customers) and Failure Demand (which arises through a failure to service value demand well: e.g. complaints, support calls, bugs, deficiencies in the product or service).

Systems Thinking goes directly to customer needs at the point they enter the system

Whereas Lean tends to focus on the internal process flow to understand value and optimise internally, Systems Thinking goes directly to customer needs at the point they enter the system: e.g. when first buying/using the product, arriving at the website or calling the call centre.

The goal with Systems Thinking is to service Value Demand perfectly first-time while minimising Failure Demand (sometimes termed Avoidable Contact). The philosophy with Systems Thinking is that the overall behaviour of the system determines performance (95%) not the individuals within it (5%).

Because of this Systems Thinking depends on an inversion of traditional hierarchical management control: by studying work at the point of contact with the customer, the people involved in that work are engaged and empowered to design and test their own improvements.

The role of management is to enable and support this process using simple measures directly derived from customer demand – it is not to performance manage the individuals. This is similar to Agile, where the team is granted autonomy, but is also much wider, extending to everyone involved in the delivery and support of the product and service.

With Systems Thinking, there is much more focus on the customer and their needs than there is typically in Lean, TOC or even Agile. While Agile methods embrace the “user”, they typically do so in a narrow feature-driven (e.g. using user stories and personas) sense rather than a broader focus on who these people are and how the product or service fits into their wider lives. With Agile, the user is considered in terms of their interaction with the product, but with Systems Thinking the product or service is considered in terms of their interaction with the user.

With Agile, the user is considered in terms of their interaction with the product, but with Systems Thinking the product or service is considered in terms of their interaction with the user

This might seem a subtle distinction but is quite different in practice. For example, a Systems Thinking team might well eliminate an entire product line (because there’s a better way to give the customer what they need without a product) or perhaps interact with them in a different way altogether whereas Agile teams will tend to only replace or improve an existing product, innovating within existing constraints.

In this way Systems Thinking can deliver results more quickly and can function well in a Cynefin Complex environment because it makes no assumptions about fixed processes or future demand and teaches both flexibility and adaptability, giving people the tools they need to probe, sense and respond to changes.

Systems Thinking doesn’t have wide adoption and is often poorly understood. Because it inverts traditional management control processes it can be too big a leap for some to take. It also challenges traditional thinking on economies of scale, functional specialisation and cost-cutting which can hamper adoption.

Six-Sigma


Six-Sigma is an approach to maximising quality and predictability through the use of statistical methods with process control. The goal is to achieve the (sometimes mythical) 99.9997% quality target for work in the system by eliminating variations in the system.

Six Sigma gets its name from “six standard deviations from the mean” which is the statistical quantity covering 99.9997% of cases under a normal (or Gaussian) distribution. One point that is sometimes overlooked is that many types of work are not Gaussian in nature (they have an asymmetric long-tail) and therefore the six-sigma case may be unachievable.

However, notwithstanding that, Six Sigma provides a suite of tools based around Deming’s Plan-Do-Check-Act cycle (shared with many other approaches such as Lean and Systems Thinking) and uses a rich suite of tools for analysis including 5 Whys, Chi-squared tests, ANOVAs, Root Cause Analysis and many more. Most of these tools are not specific to Six Sigma but it does favour highly mathematical methods of analysis.

For Six-Sigma to function well then the system of work needs to be predictable

Traditionally used successfully in manufacturing, where production processes tend to be fixed, well-defined and highly repeatable, today the same methods are being applied to product development and services.

For Six-Sigma to function well then the system of work needs to be predictable – it is fundamentally unsuitable for Complex or Chaotic systems where the lack of repeatability will defeat any attempt to statistically improve processes. This is often misunderstood with predictably disastrous results – it is easy to have a complex statistical method that produces meaningless output because the inputs are not stable.

A common misconception is to think that Six-Sigma is not customer-focused but just concerned with internal processes. Actually, it is highly customer-focused, prioritising quality as its primary concern.

Variation is the big evil in a Six-Sigma system and it is designed to identify, understand and then eliminate causes of variation in the system

Variation is the big evil in a Six-Sigma system and it is designed to identify, understand and then eliminate causes of variation in the system. It’s important to understand that sometimes variation is important – it matters because customers may have different needs and attempting to eliminate variation can result in everyone being unhappy; a poor product or service.

Six Sigma these days is much maligned and criticised outside manufacturing for a lack of effectiveness and over-reliance on statistics. However, just because it has a narrower set of problems for which it is applicable, that does not mean that it has no value. Mathematical rigour and analysis can be highly useful when applied appropriately with good quality input data.

Conclusions


I hope you can see that none of these approach is a “silver bullet” and they each have strengths and weaknesses. Equally, I hope you’re already seeing how many of their aspects and tools are complementary and can be used together.

In Part III, we’ll compare the different methodologies further and compare and contrast different facets in more detail.

Posted in Agile, Kanban, Lean, Methodologies, Scrum, Six Sigma, Systems Thinking, Theory of Constraints.

4 Comments

  1. Hi Tom,

    i see that you have totally misunderstood and mis represented systems thinking. The vanguard method is just a variation of PDCA.

    • Hi Geoff,

      It’s not my intention to misrepresent anything but I’ll need you to provide specifics for me to respond any further.

      It is certainly the case that there are different camps in the Systems Thinking space with different views. John Seddon describes the Vanguard Method as Check, Plan, Do and distinguishes it from PDCA through its focus on first studying demand and its varieties in depth. There are also a whole bunch of tools and techniques in the method which cannot be said to be ‘part of PDCA’ AFAICS.

      Thanks,

      Tom.

  2. Pingback: Can TOC and Agile work together? Sure they can! (part 4) | Now I am the Master

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>