|
|
The Toyota Way
 Last March I did a presentation about the Toyota Way at XP Day France in Paris.
Jacques Couvreur was there and now he has written an interesting article (in French) about the parallels and differences he sees between the Toyota Way and Extreme Programming. The main differences he sees are in the practice of Hansei (reflection) and the fact that the Toyota Way explicitly defines how people and teams work together, throughout the whole organisation.
Indeed, retrospectives weren’t an “official” part of XP v1, but all agile teams I know of, have incorporated some form of reflection and process improvement in their process. XP is intended specifically for the development team; all interactions with the outside world go through the mythical customer, whose job definition is left as an excercise for the student.
I particularly like the way Jacques starts the article with some nice, big, hard numbers about Toyota’s business. He ends with the rethorical question “which IT company would like to be as successful as Toyota?”. Jacques follows the advice Charlie Poole gave in his keynote at XP Day France: if you want to talk to deciders, talk their language. Money talks.
Pictures of XP Day FranceAlexandre Betis has published some pictures he took at XP Day France. Some great pictures of Charlie Poole telling his story, all the while the same slide up on the screen with one word: “Extrême”. Charlie has been watching Presentation Zen.
You can see me presenting with a laptop on a chair, the chair on the table. Near the end of the presentation, electricity fell away. No more beamer. The audience self-organized: they put the laptop on a chair and rearranged themselves to sit closer to the small screen.
Luckily, I used a “Takahashi” style presentation with really large fonts. Since that day, I’ve made the fonts even larger, as large as I could make them. Even if the laptop had gone too, I could still have continued to tell my story. I just had to “call an audible“. We did just that shortly after this image, the last 35 minutes. A nice talk with the audience about the parallels between Lean, agile, martial arts and our experiences applying these ideas. I enjoyed myself and learned something new; I hope the other people in the room did too.
CMMI, the debate
As debates usually go, this one generated a bit of heat and little light. In my day-job I’m looking deeper into PMBOK, CMMI and ITIL. What are they good for, except for padding my bookcase and resumé? More about that later.
The afternoon
The standing lunch was a bit cramped. Lots of people came up to me to talk about the Toyota Way and my presentation. I think the sales of the Toyota Way, Lean Software Development and Retrospectives books will go up in the next few days.
Gery Derbier led a simulation of “specifiers and artists”, where we had to evolve (by way of retrospectives) ever more effective ways to explain what to do. In the simulation, we had to make drawings, based on the instructions from our specifiers. My team didn’t draw everything wanted, but got manyt of the requirements done in each of the three rounds. Consistent, but not much improvement. Another team didn’t get anything done in the first round, but managed to complete the second-round task completely, after making some major changes during the retrospective. Maybe they were motivated to change.
J.B. Rainsberger led a workshop on the role of testers in agile teams. First, we listed a few issues to discuss. Among them “the effects that tools have on the way developers and testers work together”, “the (lack of) respect testers get”, “what’s a tester’s job? Verification or validation?”. Joe sees testers as a third major role in XP, next to the developers and customer, helping the two other roles communicate. In our group we talked about the “respect” and “validation” topics. Testers are part of the “customer team”. They write the specification, the acceptance tests, they verify if the specification is met, validation. Gery uses the terms “developer tests” and “user tests”. Developer tests are all the tests made by developers: unit tests, integration tests… They are verification that it works. User tests are all the tests made in name of the user, by the customer and/or testers. They are verification that it does what it should do. Testers get a lot more respect if they act and are seen as ambassadors of the users.
Closing
There was a short closing. The conference was a success, people asked for more. Thanks to Laurent, Emmanuel and Christophe. See you next year!
Tags: XP Day
The night before
At the end of the first day, we had dinner on a boat touring on the Seine. I didn’t see much of the scenery, because we had a lot of animated discussion about Lean, Theory of Constraints, agility, books, dysfunctional organisations…
After that, we went for a (Belgian!) beer, where the conversation turned towards less serious subjects.
Friday morning
Start bright and early, because I have to present two “one minute presentations”: each session organizer explains in less than one minute why people should attend their session. I advertised my Toyota Way session and Johan Peeters’ Agile Security session, because Johan arrived “just in time” for the start of his session.
The Toyota Way session was in the first slot of the morning. Things were going well, I rarely stumbled speaking French and the audience seemed interested. Shortly before the end, we lost power. No more beamer. The audience self-organized to solve the problem: my portable (running on batteries) was put on a chair on the table, which allowed most people to see what’s on screen. Luckily, I used a “Takahashi” style presentation, with large fonts and big images.
After the presentation, I had reserved half an hour for questions and remarks. There were a lot of questions, lots of discussion, so it seems the presentation piqued people’s interest.
CMMi vs Agile
I’m currently attending a “CMMi vs Agile” debate. Hmmmm… there’s that “vs” word again. I feel an “Evaporating Cloud” coming on.
Day one of the first French XP Days
A brief train ride and I arrive in Paris, to be met by Christophe Thibaut, Marc Evers and Willem van den Ende. Off to the “Centre Hamelin”.
Laurent Bossavit opened the first French XP Days. Charlie Poole presented a brief keynote about “Extreme Value”. He urges us to understand the business and to explain (and show!) how we generate value. This is an interesting subject, but I would have liked to see a longer, more in-depth session. Charlie and some audience members mentioned something I’ve also experienced: it’s easy to speak about the value of XP/whatever you do with the top people. These people are used to making decisions about value, cost, investment and risk. Nothing extreme there: more value sooner; lower cost and risk; more control. It’s the “managers in the middle” that are harder to deal with. What are they motivated by; what do they want; what’s their problem? Answers on a post card…
Retours d’experiences
I’m attending the “retour d’experiences” (experience reports) track. In the other rooms, there’s a refactoring session and the “Leadership Game” session by Yves and Ignace Hanoulle.
What’s the common theme running through all these experiences? These are ordinary people, doing ordinary IT projects in ordinary companies. They’ve encountered problems. They have used agile methods. Some things have improved; most things have improved considerably. There are still problems to be overcome, but they like where they are now. They’ve come a long way and know that they will have to keep going further.
Another common element is “fun”. These people are passionate and love their jobs. Like in the case of Ardatis, they report that one of the indicators that they’re doing well is that teammembers are happy, that customers and users are happy.
Let there be pudding!
That’s the kind of real-world down-to-earth story that we need to get out at events and conferences like the Benelux XP Day. Whiz-bang, super-cool consultanty type things are fun and interesting. But the proof of the pudding is in the eating. Let there be lots of pudding!
It’s great to hear all of those success stories. But my inner sceptic wonders if this is due to selection bias? Who’s going to present a story of how they used agile techniques and failed? (Update: J.B. Rainsberger did exactly that: see the day 2 entry).
I’d like to hear such stories. I’d like to discuss such stories: what has gone wrong, what could have been done differently, what have we learned for our next project?
Call me
Who’s got a succesful agile project? Contact me. Come and tell us about it at a user group meeting, an open space conference or an XP Day.
Who’s got a failed agile project? Contact me. Let’s put together an interesting session a user group meeting, an open space conference or an XP Day.
Collection fieldstones
As you read earlier, I’m reading “Weinberg on Writing: the Fieldstone Method“.
I’ve begun to consciously think about how I collect fieldstones.
Slippery fieldstones
I get most of the material for what I write by reading, by thinking about what I read and by writing about what I think. There are plenty of fieldstones. The problem is collecting them.
I don’t always have something to write ideas down, especially when I’m reading. I have an inhibition against “mutilating books” by cracking their spines, writing in them, folding down corners of interesting pages or putting sticky notes in them. In any case, I don’t have sticky notes on me when I’m reading. This means I must trust my memory to collect interesting fieldstones.
A few days ago, I was re-reading “The Toyota Way” to collect material for my presentation at XP Day France, when I came across this fantastic fieldstone: “Obeya”. This was a perfect fit for what I wanted to convey with the presentation. With this word, I could link two sections of the presentation. I tried to remember the word. And I did… for 5 minutes, or so. And then I forgot the word.
I don’t worry too much when I forget something: if it’s important it will come back. “Obeya” came back when I was getting something to drink from the fridge. This time I could keep the word in memory long enough to write it down on the back of an envelope. Whew! Later that day, I added “Obeya” to the presentation.
Leaving stones behind is not too bad. If the fieldstones are good, they’ll turn up again.
Playing with words
Weinberg describes many ways of playing with the text. There’s one I used to use long ago at school, when I didn’t have any “inspiration” to write an essay.
I opened the dictionary at random points and scanned the pages for “interesting” words. There are many ways a word can be interesting: the sound or the shape of the word, the meaning, an “exotic” origin… I usually collected between 10 and 15 random words like that.
Then I shuffled the words. Weinberg calls this “playing Solitaire” with the words. Slowly, the words would prompt a story. The only thing I had to do was write that story down, using at least 10 of my “chosen” words. Quick and easy.
I particularly enjoyed obscure or unusual words. I pictured the teacher looking up all those words in their dictionary. I thought they might learn something by grading my work. I think they mostly learned that I’m an obnoxious smart aleck…
There are many more “games” like that in the book. I’m going to try a few of them. I particularly like “Dani’s Decimation”, a game where you remove 1/Nth of words from every sentence, 1/Nth sentences from a paragraph. It’s bound to simplify my writing.
Playing with structure
There’s another writing game that I play, that’s not in the book. For the “Things I didn’t Learn” series, I imposed a certain structure on the stories, to see what would happen.
I started with three stories and tried to give them a common structure. You need at least three exemplars before you can generalize (like in framework writing). You need at least three before you can start to talk about “series”.
Once these three stories were composed in my head, using the common structure, I started to think about other stories that I could fit in the format. Working against the limitation of a fixed format, I found more stories that would fit. Each of them had to have a certain structure:
- I encounter a problem that others have also encountered
- I solve it using an Extreme Programming or Agile technique
- But I go back to using the tried and true ways. The problem reappears.
- Everyone (me included) says “that’s how it’s supposed to be”. Software projects are meant to go badly. If there were a way that projects could succeed, we would have to change our ways of working. There is no such way, so we can’t be blamed if things fail.
An outline’s not for me
Weinberg warns that writing from an outline usually doesn’t work very well for him. It doesn’t work for me either. I prefer the collecting-shuffling-writing-rearranging method.
Sometimes I have to follow an outline. For example, the “Toyota Way” book contains 14 principles, which are part of 4 categories. I’ve kept this structure for my presentation. I use the 14 principles and 4 categories as a “backbone”. For the rest, I’ve collected fieldstones and put them where they made most sense. And then I rearranged them, and rearranged them again. I’m still rearranging and will probably continue to do so until the day before the presentation. But still, the 14 principles are there.
The 4 categories are still there, but I reordered them. The book presents the philosophy first. I prefer to keep it at the end. That way, the presentation ends on a strong note, building up from the Process practices like Flow, Pull, Heijunka… Then we have the People principles, then Problemsolving and finally Philosophy.
P.S. If you’re curious about the meaning of “Obeya” and you haven’t looked it up yet, “Obeya” is the Japanese for “Big Room”. It’s the name given to the practice of putting all people involved in the design of a car in one big room, so as to facilitate communication. This word is useful for two purposes:
- “Obeya” is a practice that is the same in the Toyota Way and in Agile Development. It reinforces the idea that Agile and the Toyota Way share some practices. In the presentation, I want to show that they also share most of the principles, even if the practices are different.
- “Obeya” links two sections, the one on “Learning” and the one on “People and Partners”. Letting people work together lets them learn from each other, encourages frequent integrations and speeds up “Nemawashi”, seeking consensus. Engineers from partner companies also work in the “Obeya”, so that their designs are perfectly integrated with the rest of the design. Working in the Obeya, these engineers experience The Toyota Way firsthand. They can become ambassadors and sensei of the Toyota Way in their own companies.
p.p.s. As you may have noticed, these days I like to write stories around obscure Japanese terms 🙂
Tags: agile, Toyota Way, XP Day
|
|
