|
|
 It’s always a people problem (Gerald Weinberg)
In “The Secrets of Consulting“, Gerald Weinberg tells us that Whatever the problem is, it’s always a people problem.
All too often, problems are labeled as “Technology problems”, to hide the real problem and avoid blame. This strategy is very effective in a field like IT, where there is lots of technology churn. However, you can always trace even these problems back to people: who selected the technology and why, do people know how to use the technology, were the users of the technology consulted…
 It’s always a process problem (The Toyota Way)
The Toyota Way states that Whatever the problem is, it’s always a process problem.
Not surprising, coming from a company which has one of its principles: “The right process will deliver the right results.”
An example situation: Mike the micromanager
Imagine an all too common situation: someone who micro-manages their team. As the number of interventions rises, so does the disruption to team member’s flow. This reduces the team’s productivity. When the lower results become visible, this increases the need the manager feels to intervene, which leads to more interventions. And the vicious circle goes on an on…
Micromanagement as a people problem
What questions would Gerald Weinberg ask?
- Where does this need to intervene come from?
- Is the manager aware of the effects of his actions? Could we clarify this by using a Systems Thinking approach as above?
- Can we improve the way the manager and the team communicate? E.g. the manager could “batch” his requests of the team; the team could provide better visibility into the state of their work, so that the manager need not fear that “things are getting out of control”.
- How do the team members react to the interventions? Are they acting incongruently themselves?
Micromanagement as a process problem
What questions would Toyota ask?
- What is wrong with our hiring or promotion process, that put this manager in a situation he wasn’t able to handle?
- What is wrong with our training and coaching process, that we left this manager in a difficult situation without any help?
- What is wrong with our Genchi Genbutsu (go see on the workfloor) process, that this manager’s manager didn’t go and see how the team was, so that he could see the problem?
- What is wrong with our Hourensou (report, inform, consult) process, that this manager didn’t inform his manager of the problem and consult him for ways to solve the problem?
- What is wrong with our evaluation and “Stop the line to fix mistakes”, that nobody stopped to report the problem and find its cause?
People or Process? Evaporating the cloud
We clearly have a conflict: either every problem is a people problem or it’s a process problem. The “Thinking Processes” provides us with the “Evaporating Cloud” technique to examine and resolve such conflicts.
How do you read this diagram?
- In order to have “An effective organisation” (goal) we need “Effective people” (requirement 1), because the effectiveness of the people determines the qualities of the result (assumption 1)
- In order to have “An effective organisation” (goal) we also need “Effective processes” (requirement 2), because effective processes enable people to work well together (assumption 2).
- In order to have “Effective people” (requirement 1), we need to “Treat every problem as a people problem” (prerequisite 1), because this will help us focus on solving the fundamental people problems and not get sidetracked by superficial symptoms (assumption 3).
- In order to have “Effective processes” (requirement 2), we need to “Treat every problem as a process problem” (prerequisite 2), because this will help us focus on continuously improving our processes and thereby making our solutions available to the whole organisation (assumption 4).
- There is a conflict between D1 and D2: either all problems are people problems OR all problems are process problems.
How can we resolve the conflict?
- Are the relationships between goal and requirements valid? I think so. I believe we need a combination of effective people and processes to succeed. Take away one of them and you can’t have an effective organisation (if you have effective people, they will probably grow a process anyway).
- Are the relationships between prerequisites and requirements valid? I believe the only way to be effective is to be continually be solving problems, be they people or process problems.
- Are the assumptions correct? I believe so, I can’t find any counter-examples for the moment.
- Why can’t D1 and D2 co-exist? Are they really mutually exclusive? What’s the assumption behind this? Hmmmmmm. Let me think…
Imagine that both statements are true: Every problem is a people problem AND a process problem. Would this assumption lead to a contradiction? Let’s see what we would do in Mike’s case:
- First, we could call in Jerry Weinberg and resolve this manager and team’s issues, so that this team can work effectively.
- Then, we could call in a Toyota sensei to question the processes that led up to this problem and failed to detect and correct it. They would help us to improve the processes, so that this kind of situation could be avoided in the future, so that in the future, all teams can work effectively.
I believe this resolves the conflict: every problem is a people problem that must be solved now AND an underlying process problem that must be solved, so that this problem doesn’t reoccur in the future. That means we have to clarify our goal: “To have an effective organisation, now and in the future“. With these changes, the diagram looks like this:
Reconciling people and process, present and future
Both types of problem solving have their place. We need to deal with the problems that people are having now. We need to continuously improve our processes so that these problems won’t reappear for other teams in the future.
An analogy I like is that improvement needs to be like a ratchet: relentless reflection and continuous improvement (Hansei & Kaizen) drive the gear wheel forward; processes encode our growing and changing knowledge to act as the “click” that prevents the wheel from turning back.
Tags: Systems Thinking, theory of constraints, thinking processes, Toyota Way
 Rob Westgeest and I ran the I’m not a Bottleneck! I’m a Free Man! session on the “Theory of Constraint’s 5 focusing steps” at XP Day London.
We had rather a large group, so instead of the usual 7, we played the session simulation with 14 people or 7 pairs.
You can see the first run of the simulation on the left. Notice how
- some people are very busy, most notably the two people in the middle who have to fold the boats. Half finished work starts to pile up in front of them.
- some people are idle and look a bit bored, like the people at the end of the production line. They only receive some work once in a while, most of the time they’re waiting for input.
As per the simulation’s design, the ‘programmers’ in the middle of the team are the bottlenecks. Our first round programmers didn’t seem to be very happy about that.
 Rob and I then introduced the “5 focusing steps” to optimize the system. We chose one of the optimization steps and ran the simulation again with 14 other people. This let everybody experience the simulation and avoided the “elevation by experience” effect.
This time, the team produced one more boat/hat pair (their primary goal) and consumed a lot less paper (their secondary goal). As expected.
But we also saw some unexpected stuff happening. This time round, all of the player roles were idle some of the time. In a system with a bottleneck, we expect the bottleneck never to be idle, because every bit of work wasted at the bottleneck is wasted work for the whole system. Why did this happen? Maybe the players in front of the new bottleneck (design, just in front the programmers), over-optimized the second goal (don’t waste paper) at the expense of the primary goal (fold more paper boats and hats). By doing this they “starved” the bottleneck.
We had some more discussion of the 5 focusing steps. Usually we do this first part in one hour. At XP Day London we had 90 minutes. Instead of stopping when the material ran out, we continued, trying to fill the extra 30 minutes with some extra material on Throughput Accounting. That was a mistake, because the participants (and presenters) got very low on energy. We should have listened better to Tim Lister’s keynote where he wondered why projects never finish early…
In the second part, 4 volunteers played “customers” who wanted some help with their process. The other participants played newly graduated “Theory of Constraints consultants” who wanted to make a lot of money help their customer.
Some observations:
- most “customers” felt that their “consultants” had really helped them to see their situation and options more clearly.
- I thought most of the “consultants” really had trouble following the focusing steps “slowly”, but wanted to jump ahead to the solution before understanding the problem. I have this problem too. That’s why I use the 5 focusing steps: they force me to slow down and think carefully.
- One customer said that the goal of his system was to “implement “. It’s not uncommon in “real life” that customers bring in a consultant to “just implement my solution”.
Programmers often complain that “customers don’t know what they want“. For consultants, a customer “who knows what they want” is the most dangerous kind. Whatever you do, never implement this solution, unless you’ve made sure that it really is a good solution for the worst problem the customer has. If someone asks you to implement a solution, ask them first “If that’s the solution, what’s the problem?”
Simon Baker has written a blog entry about the session
 Theory of Constraints @ XP Day Benelux
Rob Westgeest and I ran the I’m not a Bottleneck! I’m a free man! session at XP Days Benelux 2005. I ran this session with Marc Evers at the XP2005 conference before. You can read more about that session on my site.
The first part of the session is a simulation of a production line, where participants have to fold and decorate hats and boats. The picture on the left shows the participants re-running the simulation after “elevating the constraint” by adding another person (Nathalie on the left) to help Vincent, who was the bottleneck in the first round. This had the effect of increasing the team’s output. Some of that increase can also be attributed to the fact that by the second simulation, the participants have more practice.
Elevating the constraint also had the effect of shifting the bottleneck away from folding the boats and hats, towards the next step: decorating hats and boats. That’s quite likely if you perform a large intervention like elevating the constraint by doubling the manpower.
In the second part of the session the participants, newly graduated “Theory of Constraints consultants”, had to solve some real-world problems. Erik, Marko and Nathalie acted as customers. The others played consultants who tried to help their customers by discovering the system, the goal and the bottleneck and applying the “5 focusing steps“.
What amazes me is that each time we ran this session, participants were able to understand their customer’s situation and propose 3 possible optimizations. Within less than an hour! And after only one hour of schooling. If you want to optimize your process, hire these people!
That tells me that the 5 focusing steps are both easy to understand and apply. These steps might look trivial, but they give you focus. And these steps are not as easy as they sound. Just try to find out what the goal of your organisation is…
We’ll be hosting this session at the XP Days London 2005 conference, next Monday. If you want to improve your process, join us there.
 I’m again organizing XP Day Benelux with Vera, Marc and Rob. This year we’re back in the Netherlands, in Rotterdam.
It’s the third time we organize this event and it keeps getting bigger. This year is the first time we have two conference days. This brings with it some extra work (e.g. people need to stay overnight), but the growth and extra work is still manageable with the help of Marko, Willem, Nynke, Erik and Peter. We already have experience with two day events, because the Agile Open conference started out as a two day conference.
The conference will be held on November 17th and 18th, only a month from now. Still a lot of work to do, but things seem to go smoothly (for now…). I’m currently mostly working on handling the registrations, invoicing, payments. We have a little application to help us with that and I’ll tell a bit more about it later.
I’m also co-presenting two sessions at the conference:
And that’s not all… November is “conference month” for me:
 I’ll be going to the German XP Days on November 21st in Karlsruhe. My boss (me 🙂 won’t let me go to such conferences unless I present a session, so that’s what I’ll be doing. I’ll be hosting a session on The Toyota Way, similar to the session I hosted at the XP2005 conference in Sheffield this year.
 And I’m also going to XP Day London on November 28th and 29th. The London XP Day inspired us to do something like that ourselves. I will be hosting the I’m not a bottleneck! I’m a free man! with Rob Westgeest.
There’s a lot of cooperation and exchange of ideas between the different XP Days. And soon we’ll have XP Day France!
See you at one of these fine events!
Final project burn up/down chart
 I’ve posted some pictures of our project’s burn up/down chart before. Reminder:
The green line represents the percentage of planned value implemented. By the end of the project we expect this to reach 100%
The red line represents the percentage of planned effort todo. By the end of the project we expect this ro reach 0%
Updates are performed every week by counting the cost and value estimates of each implemented story. The crosses indicate where we want to get.Did we get to our goal? As you can see on the picture we got a little more done than expected:
- We delivered 132% of planned value
- We performed 116% of planned effort
In normal people’s words: our users got a bit more than planned. Notice how with 16% more effort we were able to generate 32% more value. That’s because the customer (when we notified them that we could do a bit more than planned) was able to add stories that:
- had relatively low cost estimates. If they hadn’t we wouldn’t have added them late in the project.
- had relatively high value estimates. If they weren’t so valuable, the customer wouldn’t have risked adding more work and change to the project.
There are more interesting bits of information that can be gotten from this graph:
- in the middle of the project, we had two weeks with flat lines, where no stories were finished. None. This indicates that our stories were probably a bit too big.
- the work graph drops quickly near the end of the project. Several stories were waiting to be finished and they got finished just in time. This could mean we had “too much inventory” (in Lean terms): we had started too many stories at once.
- the final week or so is flat. That’s when we did formal acceptance testing, preparing to put the application in production. So, it’s normal that we don’t add more features then.
Looks good… Our velocity has gone up, again. We can promise a bit more for next release. Or can we?
This release had a lot less user involvement and testing than any recent release. Time pressure, holidays and lots of work on the user’s side took away a lot of time that could have been spent on the application.
- We can expect more problems than usual with this release. That will take some time away from new development.
- We need to spend more time with the users, to explain the release, set up more effective test sessions. That will take some time away from new development.
- The users are nearing the point where new features are implemented too fast for them, as predicted earlier. They can’t specify and test the features as quickly as they can be developed.
All of these reasons indicate that instead of going faster, the team should go slower. The bottleneck is shifting from IT to users. It’s time for IT to subordinate to the users and help them elevate the constraint, in Theory of Constraints terms.
But that’s no longer my job. This was my last release for this company. I’m off on holiday, so that I again have the time to blog and to organize and participate in the XP Day conferences all around Europe
Thanks to Nathalie, David, Nico and Thomas. It’s been fun. Keep up the good work!
Picture courtesy of Nico Mommaerts
|
|
