Archive

Archive for July, 2013

It’s all about the System: Systems Thinking and Scrum

July 25, 2013 Leave a comment

This blog entry is a summary of my session in Scrum Gathering Las Vegas. You can view a video of the session (31 minutes) in YouTube and the slides are available in SlideShare.

1. Systems Thinking

Systems Thinking is an approach to understand the performance of organizations. It looks at organization as a System which consist of interconnected parts that together create the characteristics of the entire system. Instead of looking at the parts separated, Systems Thinking takes a holistic view to understand how the parts fit together.

Parts of the system affect each others. This means that cause-effect relations in a system are cyclic: a results of an event can be also the cause of the event. For example, development team doesn’t automate tests. Team analyzes the causes and finds that problem is the excessive workload causing lack of time. However, when they study consequences of missing tests, they notice that their product has lot of bugs which causes extra work. The effect of a problem is also a cause for the problem.

This brings up an important lesson about system improvement: Getting rid of what you don’t want does not give you what you do want.

Organizations as systems have a Purpose. A system as a whole works to achieve the purpose.

Why it is important to understand Systems? W. Edwards Deming has said that 95% of variation in the performance of the system is caused by the system itself and only 5% can be accounted for the people. This may sound counter-intuitive. You can check my blog post about “Exercise to illustrate 95/5 rule” to see that it is actually quite true. “A bad system beats a good person every time“, says Deming. Similarly, bad people fail in a good system. We need to create a good system and find good people to work there.

2. Thinking – System – Performance

Organizations are created by Thinking: the way we understand cause-effect relations. Thinking creates the system which creates the sustainable performance of an organization.

Unless we change our thinking we are constrained to create systems that repeat the errors of previous systems. For example, if we think all work should be done in projects then we are constrained to fiddle with project details rather than find radical improvement through new thinking (for example continuous delivery).

In order to improve we must have two things

  1. See the system to understand it
  2. Change thinking to improve

3. System Conditions

How can we see the system?

System Conditions are visible, tangible things that help to see the system. They are direct or indirect results of design and management of work. Here are some common System Conditions (click to enlarge).

SystemConditions.001

Picture by Hermanni Hyytiälä (Twitter @hemppah)

System Conditions are important for several reasons: (i) They drive the performance of the organization, (ii) In order to improve at least some of them needs to be changed and (iii) They tell us about management thinking.

Everyone wants good for the company so why do we have harmful system conditions? The reason is that people who are responsible for system lack knowledge about the nature of work being done. They do not know how the work works.

4. Change strategies

How can we change something once we see it?

We can change with three strategies. Power-Coercive strategy uses carrot and stick, it rewards following the new rules and punishes for disobedience. Empirical-Rational uses logical arguments to rationalize the benefits of new behavior. Normative-Reeducative uses observation and action, collects information and understanding before changing.

Normative  is the only strategy that creates sustainable change.

Imagine 3 year old child learning that fire can be dangerous. Coercive learning would be telling him that touching the fire will result a punishment. Rational learning is telling him that fire is hot. Normative learning is that he sticks his finger in the fire, immediately changes his assumptions about safety of fire, cries a little and learns a lot.

5. Systems Thinking and Scrum

Scrum allows two paths to improve the system. We can deploy Scrum and immediately get rid of some harmful system conditions. Secondly, we can use Scrum as to see the system and experiment with new thinking.

When deploying Scrum, we can have the following improvement just by doing Scrum

  • From competing projects to single product backlog
  • From functional silos to cross-functional teams
  • From long feedback cycles to daily feedback
  • From project model to continuous delivery

However,  deploying Scrum sounds like a Coercive change. At its best is will be Rational. By it is not Normative, especially if “deployment” involves harmonization of practices or top-down push for Scrum.

A better way to use Scrum is to get transparency, see the system and learn through experiments.

Scrum creates transparency to the work at hand. How do you know Scrum works? If you know, at the end of each Sprint, exactly where you are — then Scrum is working.

Systems have a Purpose. Purpose comes from understanding demand that customers have. Scrum allows teams self-organize to fulfill the Purpose.

Teams and organizations should measure their performance against the purpose. Unfortunately, teams often measure some proxy variable that has no value for the end customer, e.g. velocity.

Second effective pattern in Scrum is experiments. Each Sprint is an experiment. Each improvement that team does is an experiment. This pattern has two benefits. First, it allows to change harmful system conditions gradually through experimentation. For example, “Let’s try to limit work-in-progress in the next Sprint and work on one item at the time”. Usually this has better buy in that pushing changes.

Another benefit of experiments is that it creates culture of experimentation in organization. When teams are doing enough experiments, also management moves away from “analysis paralysis” towards trying new things.

6. Summary

  • Organizations are systems, created by Thinking
  • System Conditions help to see the System
  • Scrum helps to see the system
  • Scrum can be used to create Normative change in Thinking
Advertisements

Exercise to illustrate Deming’s 95/5 rule

July 24, 2013 3 comments

W. Edwards Deming has said that 95% of variation in the performance of a system (organization) is caused by the system itself and only 5% is caused by the people.

This sounds counter-intuitive and training attendees often argue that having great people would solve the problems. Or at least people have greater impact than mere 5%. Many also argue that we should invest in people, coach them, motivate team members and do other “people stuff” to get better.

Unfortunately that will not work. “People issues are not the point of intervention“, says John Seddon and I fully agree. System is the point of intervention. By improving the system, we improve not only results but also motivation and well-being at the work.

Here is an exercise that I use in my trainings to illustrate how Deming’s 95/5 rule applies in knowledge work. This is a quick one, takes about 10-15 minutes including set-up and wrap-up.

1. Context: I draw the following picture on flip chart and tell the context. Joe works for an IT department of a large company. The IT system is used by customers to place orders on-line as well as company internal functions to manage invoices, inventory, sales forecast and marketing. Joe and the team have Product Owner who gets requests from customer help desk and suppliers.

(click to enlarge)

Context

I start drawing from Joe, then the team -> product -> Product Owner -> help desk -> customer -> suppliers -> logistics department

2. Case: I explain people that “help desk receives a call from customer saying that it would be nice to follow order status on the web-site, e.g. estimated shipping date. Product Owner thinks this is a cool idea and puts it to backlog, ready for next Sprint”.

3. Task: After explaining the context and the case, I ask people to pick a pair (or in their table groups) to think “What could go wrong?”. What could happen between customer requirement and Joe so that Joe can not complete the work on time, with agreed content and good quality. I give 2 minutes for the discussion.

I also explain that SW development is a team effort, but in this case we assume that we look at Joe’s work. For example, why Joe (or his boss) would feel at the end of the Sprint that things went wrong.

4. Collecting answers: After discussion I collect answers to flip-chart. Usually the list has something of the following

  • Unclear requirement
  • Conflicting priorities
  • Bad tools
  • Bad working habits in the team
  • To much work
  • Joe’s competency (lack of)
  • Misunderstanding customer need
  • Lack of testing
  • Interrupts
  • Poor communication with other teams
  • ..and so on

5. System or Joe: The last part is to ask people “Who’s fault is this?”. If we have two baskets, System and Joe, which is the cause of the problem. I write on the flip-chart on each line “System” or “Joe” based on what the participants shout. Pretty soon the list is full of “System” and very few “Joe’s”.

This is a powerful way to show what is the impact of work design: When things go wrong, it is because the system. The point of intervention is system, not individuals.

Credits go to Richard Moir at Vanguard System for telling me this exercise. I have modified the original story (about plumbing) to fit the IT industry.