systems thinking « Thinking for a Change

Mar

Book Club

Starting up a book reading group

J., the manager of the Financial systems IT department, came to me for advice. He wanted to expand his developers’ knowledge and responsibilities. He wanted them to grow beyond pure development: to get more involved in architecture and analysis, interact with customers… We looked at several options and finally decided to start up a book reading group.

In a book reading group, a number of people get together to read and discuss a chosen book. To set up a book reading group:

Invite participants. Participation isn’t mandatory.
Select a book that interests the participants.
Get enough copies of the book, so that everyone can choose when to read.
Define a suitable reading pace. For example one chapter per week. Keep the iterations short.
Agree on a fixed meeting schedule, time and place to discuss the book. The discussion is often scheduled during a lunch break, with lunch provided by the company.
Moderate the discussion and record the main insights, so that there’s an output and those who miss a session can catch up.

The quiet team

There was something unusual about this team. They were so… quiet. You probably don’t want your accounting, invoicing and ERP systems maintained by a bunch of party animals, but still. These developers rarely talked to each other, they all worked individually on their own part of the systems. I was a bit worried: would they come to the discussion meetings? Would they say something?

What would be a useful book for this team? They all had different backgrounds, worked on different applications and used different technologies. I proposed we should start with something that would be useful as a basis for further study. We chose “Quality Management I: Systems Thinking” by Gerald Weinberg. I’ve found Systems Thinking to be a useful tool to make sense of a lot of situations, but would the team find it interesting? Would a book about “management” be useful for developers? The manager and I decided it was worth the risk.

We’ve noticed that some people will find or create the time to read books to learn more, but they are the exception rather than the rule. Many people are so busy at work that they don’t have the time to read books. Reading a book isn’t “work”. And the principle of “sustainable pace” surely means you shouldn’t be spending time reading work-related stuff outside of work.

The reading group has a number of advantages:

Reading becomes part of “work”.
Peer-pressure and the short timeboxes ensure that participants create the time to read one chapter every week.
The discussion sessions ensure that participants read more attentively and hear how others interpret the material.
The discussion regularly leads to ideas for improvement actions or people getting together to try out some new idea.
Reading the book together improves team cohesion and (cross-)team communication. Even if participants work on different applications or work in different teams, they’re doing something together and realise that they face the same issues.
A reading group reveals strengths, weaknesses and skills in individuals you wouldn’t usually notice about one another working together day-to-day. This discovery could lead to increased appreciation among team members which, in turn, leads to increased respect.

Group learning

The first couple of sessions required a lot of facilitation to get participants to speak up and give their opinion. The participants didn’t see the relevance of systems thinking. And why were we reading a book about management? They weren’t managers. They were developers.

Luckily, they kept coming to the book group, they didn’t give up. Gradually, they started to speak up more; discussions started; they debated different viewpoints. They started to see things in their environment, things that had always been there. But now they saw the world with different eyes. They started to see the connections between things. They started to understand why things happened as they did. They started to realise how they could influence their environment. They started to generate ideas to improve the way they worked. The group required less and less facilitation: two participants emerged as leaders, they kept things going. I didn’t have to say anything; I just acted as their scribe. The team was no longer quiet; they were full of energy and ideas.

When starting up a reading group:

Ensure that there’s enough support and encouragement from the coach, a manager or some team members to get the group going. The first two chapters of a book are often not very exciting; the group needs to get to know each other and the format.
Small signs of company support like paying for the books, providing a place to meet and buying lunch shows participants that they and their growth are taken seriously.
Provide facilitation to get the discussion going and to keep the meeting on track. As the group gets more experience and self-organises, they will require less facilitation.
Take notes and publish them so that those who weren’t present can see the outcome. Publishing an output raises the importance of the meeting.
Ensure that the book is relevant to the work of the team. Let the team describe what they want to learn. The coach should have enough experience to suggest books that fulfil the requirements of the team.
As with iterations, a regular pace with short iterations is crucial. We recommend weekly sessions, to discuss one or two chapters.
Ensure you always meet in the same room at the same time. Don’t reschedule the book group meetings because someone can’t attend. They can always catch up.
In a larger or more heterogeneous team you can create two groups who read a different book. Discussing the two books together gives everyone some insight into both books. Maybe the participants will find interesting links or contradictions between both books.
Try to find books that contain questions or exercises for the reader. Participants must answer one question or perform one exercise per chapter. The group facilitator can set up questions or exercises for the group.
If participants are uncomfortable during discussions, the facilitator can use techniques like a clustering exercise to elicit everyone’s input.
The discussion will often result in ideas for improvement and action. Handle these like you would at a retrospective: prioritise them by value and include them as part of the team’s delivery iteration.

Feb

Beyond Jidoka – Poka-Yoke

Do you want to improve your productivity?

There’s a very simple way to improve productivity.

How much time do you spend on “bugs”? Finding them, analysing them, fixing them and making sure they don’t reappear. Not to forget the time spent writing the bug.

Imagine how much time you could save if you stopped writing bugs.

How do you write bug-free software? It’s simple.

Jidoka is not enough

Great, you’ve implemented Jidoka. Your systems and people find issues quickly. Your team responds quickly to resolve any issue raised. You even improve your tests whenever another issue slips through.

You’re well on your way to deliver quality quickly. But there’s something missing.

Poka-Yoke

Poka Yoke is the practice of “mistake-proofing” work. It’s another principle from the Toyota Production System. Poka-Yoke mechanisms ensure that the user or operator can’t make a mistake. For example a plug that can only be inserted correctly (like the 3 pin UK plug) or can be inserted in two ways that are both correct (like a 2 pin plug).

Poka Yoke is not Baka-Yoke or “fool-proofing”. The goal is not to prevent idiots from doing the wrong thing, but to make intelligent people do the right thing.

Poka-Yoke software

We can Poka-Yoke software if we really think about it.

In one case, a web application didn’t work because of an incorrect configuration parameter. Two tools each required a configuration setting. The two settings had to correspond. One configuration, created by the developers, contained ‘G004’. The other configuration, maintained by the sysadmin, contained ‘GOO4’. Can you spot the mistake?

Once we found it, the issue was easy to fix. How could we avoid it? Some thinking and experimenting showed that there was a way we could reduce the configuration to one setting, even with the existing tools. This type of error couldn’t happen again.

Thank you for reporting this error. Finding and resolving issues is a great trigger to add some Poka-Yoke.

It doesn’t have to stop here. Why wasn’t the mistake found sooner? Because this feature was only fully tested in the acceptance environment and the configuration error happened only in the production environment. Why wasn’t it tested in production? Because testing that part of the application could show confidential customer information. Next time, we’ll get someone who’s allowed to see the confidential information to test that part of the application in production. Poka-Yoke the software is the first step. Poka-Yoke the software process is the next step.

I had finished implementing this class. I just needed to add a comment to explain how to use the class. First, you had to call the methods A, B or C. Then, you could call methods X, Y or Z.

This class was very error-prone. Why not write a class with methods A, B and C? These methods return an object of a class that implements X, Y and Z. You can’t call the methods in the wrong order.

If I feel the urge to document, I stop and think. Isn’t there a way I could simplify? Isn’t there a way to change the system so that errors are impossible? The pay-off is clear: less time to document, more time to code.

Poka-Yoke is an ongoing process. It isn’t done until the system is so easy to use it doesn’t require a manual or training. It isn’t done until all testers have become specifiers instead of verifiers.

Doesn’t this take a lot of time?

Yes it does.

But imagine you only had half the issues you have now. How much time would you save? Now invest that time in finding root causes and making your work Poka-Yoke.

It’s simple. But not easy.

Jan

Outliers and raising the capitalisation rate

The Story of Success

Father Christmas brought me a large stack of books. First off is an easy read, the new Malcolm Gladwell book “Outliers: The Story of Success“. In the book, Gladwell tries to dig deep to explain the causes of unusually successful people, the outliers that are so far beyond the statistical norm that they seem magical.

Why do some people become hugely successful corporate lawyers, wealthy captains of industry, billionnaire IT entrepreneurs or hockey stars?

First of all, there’s talent. But talent isn’t enough. It takes effort, practice and hard training to develop that talent. Gladwell states that you need at least 10,000 hours of practice and illustrates the number with examples of The Beatles, Mozart, Bill Gates and Bill Joy.

But talent and practice by themselves are not enough to explain the cases Gladwell examines.

It’s not only who you are, but where you come from

For example, if you look at the month of birth of successful Canadian hockey players, the statistics show that most of them are born in the first months of the year. A few years ago I heard about the study that showed the same weird result for Belgian football players. Coincidence? Fluke? Is there something in the air in those months that gives babies an edge in sports? Gladwell doesn’t think so.

You see, there’s a cutoff date to select promising young players. That date happens to be the end of the year. The children who are born in january are just a few days too young to be eligible, so they have to wait until next year. By then, they are 11 months older than the eligible children born in December. They are stronger, smarter and have had more practice. They are more likely to stand out, get selected and profit from intensive training given to talented children.

A similar case can be made for successful IT entrepreneurs: they were all at the right age and in the right environment to profit from the availability of computer time to develop and apply their skills.

Held back by systemic constraints

In the case of the hockey players, it is likely that children born in December are (on average) as talented and hard working as those born in January. If they don’t get selected, a lot of talent and effort is wasted.

Gladwell calls the rate at which talents make it the “capitalisation rate”. The capitalisation rate for hockey players is lower than it could be. Why? Because of an arbitrary systemic constraint: the decision to select and sign young talents based on one cut off day. This effect is known and repeatable across the world. When the cut off date changes, the distribution of children is changed accordingly. We’ve all been subject to this systemic constraint because schools work with a fixed calendar.

Should we just accept those constraints?

Raising capitalisation rates

If we wish to raise the capitalisation rates, we need to tackle similar systemic constraints. One hopeful chapter describes how a school system improves the results of its pupils. First they notice the systemic constraint:

children from richer backgrounds do better after the summer holiday as they have lots of stimulating activities;
children from poorer backgrounds do worse after the summer holiday as their environment is much less stimulating.

The solution: less vacation and more school. Which also leads to more hours of practice, the second factor of success. Which leads to more opportunities to succeed and provide a stimulating environment to their children.

The chapter about plane crashes is chilling. The chapter contains several transcripts from cockpit conversations right before a crash. One common element comes back: the pilot makes a set of small mistakes and no one dares to speak up.

Some airlines have many more accidents than others. These statistics correlate with the culture of the country of the airline. Geert Hofstede has compiled a set of cultural dimensions for countries. One of the dimensions is “Uncertainty Avoidance”. A high score indicates a culture that doesn’t like ambiguity, relies on procedures and plans and is likely to stick to procedure regardless of circumstance. Another dimension is the “Power Distance Index”: a high score indicates that authority is very respected and a more powerful or knowledgeable person will not be questioned easily.

Do high Uncertainty Avoidance and Power Distance scores correlate with high numbers of airline incidents? Yes. If something goes wrong you want people to speak up and consider alternatives to the routine. Knowing this, training can take into account the differences. For example, techniques to lower the power distance can be taught and applied in the cockpit. Again, dealing with the systemic constraints brings dramatic improvements.

What have we learned today?

I got two lessons out of this book.

First, the capitalisation rate on our teams. It is sometimes said that “Agile only works with really good people and teams”. That’s true. But Agile also makes the people a lot better by providing them with a better environment, support and many learning opportunities. We create communities, conferences and help each other get better. We raise the capitalisation rates within IT. But we can do a lot more if we have the courage to tackle the systemic constraints. For example:

Why are there fewer women than men in IT?
Why is IT seen as a “young man’s game”? Why don’t we value experience more (and keep reinventing yesterday’s mistakes)? Don’t we need to put in our 10,000 hours to become proficient? Well, at least many of us put in many hours in death marches. I don’t know if that’s useful practice, though…
Why the division into “Business” vs “IT”? Aren’t we in this together?
Why the division into development, testing, maintenance, operations? Isn’t it all one value stream?
<your favourite constraint here>.

What small thing can you do to raise the capitalisation rate?

Secondly, Belgium was used as an example of a country with a high “Uncertainty Avoidance” culture. Yeah, we’re great at creating little rules to organise everything. We’re also great at breaking the rules, because they keep us from doing any useful work. But nobody must know we broke the rule, because we’re also a culture with a very high “Power Distance Index”. In this, we’re quite similar to France. Now, that’s not a culture that’s naturally predisposed to accept Agile methods. Except maybe, when they’re introduced top-down and are very structured?

On the other hand, The Netherlands and Scandinavian countries have a much lower Uncertainty Avoidance and Power Distance Index score. One would expect that they would accept Agile methods more easily.

Have a look at the scores for your country. Do they correlate in any way with the success and ease of introducing Agile?

Watch Gladwell present some of the ideas in the book:

Jul

Why bother with bottlenecks?

Why?

Bottleneck Game at XP Days London 2005

Portia writes about a participant of our Bottleneck session asking her about the relevance of a session on (industrial or manufacturing) process improvement techniques at an IT conference. Portia already told me she had the same reaction when she attended this session at XP Days London in 2005. If you look carefully, you can see Portia at the right, a bit bored as she’s waiting for the bottleneck.

Moreover, with terms like ‘exploit’ and ‘subordinate’, the 5 focusing steps don’t sound very friendly. Is this just another management fad ‘to squeeze the workers’? Can we apply manufacturing ideas to IT? Isn’t the manufacturing metaphor (or the house building metaphor) responsible for some of the worst ideas in IT?

That participant took the first step in understanding: they asked “Why?”

What is it about?

The session (and the Theory of Constraints) is about creating meaning and value by really understanding systems.

To do this, you need to:

Design systems that fulfill a meaningful goal.
Take a step-by-step approach to diagnose problems.
Find real cures by going beyond your area of responsibility, beyond your comfort zone and considering the system as a whole.
Involve everybody, to continuously challenge assumptions and long-standing traditions to create lasting improvements.

These are things I use every day in my life and my work. Are these things you could use in your work, in your life, every day?

Thank you to Portia for excellent writing advice and helping to edit this entry.

Jul

Les goulots d’étranglement pt. 3

Université du SI day 2: Heroes

We start the day with a refreshing run up the Champs Elysées, down to the Eiffel tower and along the Seine. I’ve been looking forward to this day: I will meet two of my heroes!

Eli Goldratt challenges us throughout the whole keynote. Do we want an easy life or a meaningful life? We have in our hands the most powerful tool that has ever been invented and what have we done with it? Have we brought enormous value to companies and people? We haven’t: we’ve automated the same old processes; we’ve looked no further than local optima; we’ve enabled people to perform useless work faster than ever before. Is that all we want to achieve?

What is the greatest challenge businesses face? The ability to take the right decisions at the right time. IT is the ideal tool to support that decision-making, at all levels of the company: we can store, transfer and manipulate prodigious amounts of data almost instantly. We can provide the Information people need to make decisions. We can create an enormous amount of value, but by all accounts (sic) we haven’t.

Why haven’t we fulfilled the promise of IT? The tools are out there: Theory of Constraints, Lean, the Thinking Processes, Agile… Most of them readily available and only a few clicks away. Why haven’t we used those tools? One of the reasons is that we would have to step out of our comfort zone. We need to stop dabbling with technology and look further, to accounting, sales, marketing and production. We need to see the whole system and realize its goal. Do we want an easy life or a meaningful life? Do we want to ‘fulfill requirements’ or do we want to add value? Who dares to enter into a contract with a customer where payment depends on value added?

Where are the real constraints?

The real constraints are in (implicit) rules. Who has the intelligence to recognize those rules and the guts to challenge them? Common Action (“that’s how we’ve always done it”) is not the same as common sense. Accounting rules and the way we measure are some of the most pernicious constraints. We have the tools and the obligation to change the system, to enable our companies and people to realize their full potential.

People do not resist change, according to Goldratt. People resist changes that are unclear, that threaten them, that might harm them or that bring no clear value to them. Resistance is your cue to realize that your proposal is not fully worked out and that your explanation is not clear.

Goldratt’s call to arms can be summarized as: “Get of your asses and start using your brains!” I thought this was an excellent, inspiring and thought-provoking keynote. I left the auditorium with a renewed resolve to create meaning and value.

Lean

We participated in an excellent exercise led by Olivier Pizzato and Christian Daniel about using Lean techniques to solve IT project challenges. We worked in small groups on different scenarios. For each scenario we defined three approaches to solve the problem; listed the three biggest obstacles/objections to the most promising approach; searched for a way to overcome the biggest obstacle. After a group presented their analysis, Christian linked the solution back to Lean principles and techniques.

What I like about the session are the exercises and the short (15 min) timeboxes. To make this session perfect I would provide participants with more structure and guidance about Lean, so that they can apply the techniques to the exercises.

We attend part of the session about how Google will revolutionize the development of IT systems. Bernard Notarianni and Didier Girard pair-presented the session in a very relaxed style. Portia thought it looked like a French game show. The session gave examples of web design principles that can be applied to internal IT systems. The resulting systems, often using a RESTful style, are simple and easy to integrate. We had to leave before the end to prepare for our next run of the Bottleneck Game.

Goulots d’étranglement, take three

After Goldratt’s keynote interest for our session is very high, the room is packed full. Seven volunteers come forward to play the role of the “workers”; the other participants are the “consultants” who observe and give improvement tips to the workers. They all get paid in Belgian chocolates and British sweets.

After one round of play we go through the “5 focusing steps”:

0. Define the goal of the system
1. Find the bottleneck
2. Exploit the bottleneck, get the most value out of the constrained resource
3. Subordinate all decisions to the bottleneck
4. Elevate the bottleneck when it has been exploited fully and all decisions have been subordinated
5. GOTO 0. Don’t let inertia become the constraint

The team makes some improvements to their process and plays a second round. The decision to subordinate to the bottleneck wasn’t fully implemented. The team had planned to put a buffer of work in progress before the bottleneck. They failed to keep it filled, which led to an idle bottleneck and reduced output of the system. The players used their idle time to ‘learn’ so that they could help the bottleneck in the next round.

Changing the system, breaking through constraints

Warning: don’t read this section if you want to play the game with an open mind!

The game is filled with arbitrary constraints:

players are very specialized and can’t help each other
the two customer representatives sit far apart
the layout of the table makes it difficult to get an overview and to communicate with the other team members
testing is done at the end. Nobody but the tester knows the acceptance tests

In the third round we make the players think about the assumptions and rules built into the game. They get to change their system. The most powerful thing they can do is to re-arrange the tables. As you can see in the picture, the team has a better oversight and can communicate more easily when they sit around the tables.

In the end, this team didn’t produce as much as the previous team on the first day of the Université du SI. I think this is because this team tried to be too sophisticated. Instead of simply implementing an optimisation as agreed, they kept discussing and tweaking their way of working. The DO part of Plan-Do-Check-Act shouldn’t be skipped.

Running this session in 90 minutes is exhausting. Time for a break before the closing keynote.

Man from the moon

OCTO brought Neil Armstrong to Paris for the closing keynote. As a little kid I read a lot of science fiction, fascinated by the tales of wonder and limitless possibilities. I devoured everything about the “Space Race”. These people were making science fiction a reality. By the time I was old enough to understand what was happening, the space race was already over; interest for space exploration was gone. We had stopped looking outward.

Armstrong’s keynote was humorous, enthralling and humble. These teams achieved wonders with the technology of that day (e.g. on-board computers with a few K of memory) and took enormous risks. The American and Russian space programs are a testament to what we can achieve if we really set our mind to it.

I was thoroughly inspired by these two keynotes by my heroes. Armstrong showed us what we can achieve; Goldratt exhorted us to achieve our potential, starting NOW.

The end. Or the beginning?

The conference is over. Our visit to Paris is over. Thank you to Octo for organizing this conference and for inviting Portia and me. We left Paris buzzing with ideas and energy.

Thinking for a Change

Categories

Blogroll