One day seminar organized by Technologisch Instituut of KVIV.
Introduction, case studies and agile techniques.
There are several case studies of companies that have adopted agile techniques, amongst others Ardatis. I wrote about their story before. I recommend you hear their story of how they succesfully applied agile software development in a large project.
There are also two session on testing techniques and how to introduce them in your team. I’ll be presenting the Toyota Way session, about the parallels between lean management and agile management. Should be fun.
More info and registration here. See you there.
The Toyota Way
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.
Agile Open. Day Two.
We planned to start day two with a re-planning session: look at the plan we made yesterday and adapt where necessary, based on new information. Raphael then asked the question if we shouldn’t try to go more with the “open space” idea, instead of having planned sessions. We decided to have a planned session in one track (the XP Game) and an unplanned session in the other track.
That meant I got to play an XP Game for the first time, after having hosted so many runs. I discovered I’m crap at inflating and putting knots in balloons. Halfway through the game I had to leave for the next session. This gave my team the opportunity to learn what you do when 1/4 of your team leaves: you reduce your velocity to 3/4 of what you produced in previous releases.
Metrics and Thoughput Accounting
I proposed this session to get some input. Throughput Accounting has basically three important variables, expressed in monetary terms for convenience:
Of course, time is also involved. The longer the time it takes to generate throughput, the higher the investment will be. To emphasize the fact, I keep time as a separate variable. All these variables are pretty easy to measure at the company level. We want to align the work we do with an improvement in these company metrics: increase throughput or decrease time, investment or operating expense.
The goal of the session was to find some metrics or indicators at an individual (IT) project level. We brainstormed some potential metrics for each of the 4 throughput accounting variables.
The throughput accounting variables and formulas are very simple. The only problem is that all the variables are interrelated. If you change one component of I, it’s going to have an effect on t, T and OE. And vice versa. You can’t really create a mathematical model of a project, but you can apply systems thinking. The advantage of methodologies with short iterations or releases is that you shorten the feedback loops, thus making it easier to see the result of your action and react in time.
We didn’t come to a conclusion. I’ll have to do some more thinking about it. Expect some throughput accounting posts in the near future…