Bruno Orsier describes (in French) how he has run the “I’m not a Bottleneck! I’m a free man!” game. He felt a bit uncomfortable to let his colleagues experience Lean and the Theory of Constraints with such a “silly” game: folding paper boats and hats to earn chocolates. Nevertheless, the session was a great success and he sees how the Theory of Constraints tools can be used in his retrospectives.
He follows up with another blog post about the metrics underlying the game. He applies the Throughput Accounting techniques to compute the ROI in chocolates.
Bruno reflects on the game and wonders about the role of the “Production” player: they redo the test work of the tester and count the number of pairs of hats and boats (throughput). The documentation is not completely clear on the subject. A similar question arose in a previous workshop, but this time about the “Requirements” role. The player in that role didn’t really feel part of the process, as they just hand out pieces of paper and count the pieces of paper (investment).
These two players are supposed to represent the customer. They are at the start and the end of the process, where investment and throughput are measured. They don’t really participate in the process, but they track its progress. The “Production” player tests the output like a customer would acceptance test the output of their supplier. During most of the simulation they don’t have a lot to do. How could they make themselves useful?
Don’t read on if you don’t want to spoil playing the game….
Involving the customer
How could you involve the customer more? Here are a few ways to do it in the game:
Unite the two customer representatives, one who defines the requirements and the other who performs acceptance testing.
The customer representative(s) examines the process and offers improvement ideas. The other players are much too busy to see anything but their own work.
The customer representative can be involved in the work, for example by helping with quality control. I usually add a few poorly cut sheets of paper to the stack of folding paper. The customer can help their team by performing quality control on the paper, rejecting any bad raw material.
If the quality that comes out of the team is very high, the customer has more confidence and needs to do less testing, leaving them more time to do more interesting and value-adding work.
If you haven’t played it yet, this game lets you play in a team of account managers who have to prioritise a portfolio of projects for their development team. To win, you have to make difficult business decisions:
Which project goes first?
Do I start many projects at once or do I focus on one project?
Do I focus on revenue or customer happiness?
Can I afford to lose that customer? Can I afford to keep that customer?
Do I invest in process and productivity?
How do I deal with variance in performance?
In the beginning, the game is very easy. In each iteration we add another twist so that by the end of the game, the players are juggling loads of projects and customers while dealing with unreliable developers who want new tools. Many developers came out of this game with increased respect for the account and product managers in their company 🙂
It’s instructive and lots of fun. If you don’t believe me, ask Laurent Morisseau and the other participants of Agile Open France.
But in the real world…
Of course, the real world is always a bit more difficult than a simulation. After the game, we run a workshop where the participants look at how they can apply the game’s ideas to a range of circumstances: product development, many small projects, large projects, support and maintenance…
A developer came up to me and told me something strange was happening to him since he worked in an XP team: he’d started to call everything he liked “Agile”. When he saw something he didn’t like, his first reaction was “but that’s not Agile!”
I reassured him that this was just a phase. Soon he would regain his ability to be creative with adjectives.
Isn’t that a good example of how Agile is like a sect that brainwashes its members? Or do we call everything that’s good “Agile” and win every possible argument?
Agile == Professional
Recently, I was asked to explain what “Agile Project Management” means. I said I had no idea. Do you have a good definition of Agile Project Management?
To me, there’s only good or bad project management. Similarly, there’s professional software development or amateurish hacking. You take your pick.
As Dave Nicolette observes, “Methodologies don’t succeed or fail. People do. If you apply a methodology that doesn’t fit the problem, it won’t help you. If you apply an appropriate methodology for the problem, but you use it poorly, it won’t help you. Either way, the methodology deserves neither the credit for success nor the blame for failure.” A professional team will select the appropriate methodology for the domain and context, implement it professionally and inspect/adapt where necessary.
Unfortunately, the waterfall (or the Lean equivalent batch mass-production) mentality is still alive and well in many companies Dave and I encounter. Unfortunately, many people prefer to muddle on (or fail) with the familiar methods.
Which side are you on?
So, let’s forget about the red herring of Waterfall vs Agile vs PMBoK vs CMMi vs PRINCE2 vs…
Yesterday evening I was back in Paris to give a presentation about “Lean and the Toyota Way“. As I walked from the train station to the offices of Zenika, I came across a large billboard announcing “Dorothy et le magicien d’Oz”. It’s reassuring to see that the fairytales are alive and well.
My friends at Zenika had arranged a nice place and provided some fine drinks and snacks. More than 100 people showed up, among them many of the French Agilistas. I chatted for a while with them about agile, lean and the upcoming XP Days France.
And then it was time to start the presentation. The auditorium was almost completely full.
The Toyota Way
The presentation explained the 14 principles of The Toyota Way of Managing and the many parallels with Agile methods. As I go through the principles I illustrate them with stories from projects I’ve worked on. Each time I do this presentation it changes, as I learn more and discover more great ideas in Lean.
There were some great questions and discussions:
“What can I do to introduce more Lean and Agile in my organisation?” – Apply the principles and values, set an example. Support and collaborate with others who apply these values.
“Are there any incompatibilities between Lean and XP?” – None that I can see.
“For Agile and Lean transformations to succeed we need support from management and workers. Often, we only have support from one of them.”
“Lean coaches are very direct, not afraid of saying it as it is to management. Is that something they’re taught?” – It does seem so, judging from the documentary Kenji Hiranabe showed at Agile 2008, where a Lean coach almost made a factory manager cry by bluntly pointing out all the flaws in the production line.
“Does Lean make you lose weight?” – A Gemba Walk a day helps 🙂
Unfortunately, I couldn’t stay for drinks afterwards because I had to rush to catch the last train back to Brussels. The next day I had another team to coach, another opportunity to “Develop exceptional people and teams”, the tenth principle of the Toyota Way.
Jean-Claude Grosjean summarizes the principles and contrasts them with the 7 principles of Lean Software Development and Agile.
Nicolas Martignole wrote a very extensive report on each of the principles and relates Lean, Scrum and XP.
Claude Aubry thinks “Obeya” is more beautiful than “War Room”. I fully agree. He currently tries to recreate the Obeya experience for an offshore team.
Thank you for the rapid and very detailed feedback!
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.
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:
A lean evening
