|
|
 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
 Last month, I’ve been mostly reading Thinking Beyond Lean by Michael Cusumano and Kentaro Nobeoka.
The book describes the move from single- to multi-project product development at the major automakers and the different strategies they use.
Typically, Toyota was the first company to move in this direction. At a time when other car makers were starting to adopt Toyota’s “Lean” product development model, Toyota started to think that their product development model should be improved.
Lean product development
What are some of the characteristics of “Lean” product development?
- Development is led by a “heavyweight project manager”, someone with a lot of authority, well-respected because of his technical experience and who has a clear vision of the product to built.
- Development teams are cross-functional and co-located: designers, engineers, production engineers all work together from the start and work is integrated frequently. At the end of the development process, the product is well-integrated and ready to be produced efficiently.
- People stay on a team beyond a single project, to preserve the implicit knowledge, processes and working habits.
Agilists will recognize many traits of this model. The “heavyweight” project manager is odd: imagine someone who’s the onsite customer, the coach, the manager and the technical lead all rolled into one. It’s astonishing that Toyota is able to grow such supermen.
But, Toyota started to see some drawbacks…
- because the teams wanted to make ‘their’ car the best they could possibly build, lower-end models started to get high-end features. This not only made the cars more expensive, but the distinction between models started to blur. Some of the models became competitors and “cannibalized” each other’s market.
- to reduce costs, car makers increasingly (re)use common parts. The major shift is towards common “platforms”, the base of the car. However, it was hard to coordinate the different independent projects to reuse parts and to transfer knowledge from one project to another.
- team members became more generalists, less specialists. This is great for working as a team, but there were fears that the engineers would lose their technical “edge” and would no longer be innovative.
These drawbacks are not unique to car makers. Similar problems are encountered by teams working “vertically”: each team builds one application from start to finish. The resulting systems are “silos”, completely independent applications with nothing in common.
What to do then? Move back to a “horizontal” organization where people are organized by what they do, not what they work on? Create a design group, a chassis group, an engine group…? That’s great for innovation in each area and reuse. But it’s hellishly hard to coordinate all those departments to build something that has conceptual integrity. There’s a real danger that each department will optimize their own work, at the expense of the overall result.
I’ve seen many organizations flip-flop between the two models, never satisfied with the results.
Beyond Lean
Toyota didn’t go back to the old model. They went the “Development Center” way:
- There are 4 development centers
- 3 development centers each develop several models. The different models in a development center typically share a small number of platforms.
- the fourth development center is responsible for research and parts that are common to all models
- Each development center is run by an experienced ex-heavyweight project manager, whose job is to coordinate the effort of the product project managers in the centre. There’s now a hierarchy of ‘chief engineers’, so that each of them only has to coordinate with a limited number of other chief engineers.
- Each development center has a simplified matrix structure:
- there a small number of functional groups (e.g. chassis engineering, power-train engineering…)
- product development is still done by heavyweight project managers, using a team composed of people from the different functional groups.
- For each component in a car, the appropriate level of reuse is determined:
- Is this something that is unique to one model, something that distinguishes this model from the others? Give the model’s project manager authority.
- Is this something that is common to the models in the development center, like the shared “platform”? Give the the development center’s manager authority.
- Is this something that is common to everything that Toyota makes? Is this something that requires a large R&D effort (like developing a hybrid engine)? Give the authority to “Development center 4”.
- For common parts, there is a limited choice (maybe 3-5 options), from which each team can freely choose. A new option is only added if it’s clearly superior to existing options; one of the existing options is dropped, to keep the number of choices down.
This system reduces complexity while promoting reuse within an appropriate scope. They’re still able to develop products quickly but also to reduce costs by reuse. And as Toyota grows, this structure keeps the number of communication lines and people to manage within manageable bounds.
What about agile software development?
That’s great for cars, what can we learn from this? Already, some people in the agile world are looking beyond single projects, because the same advantages and disadvantages as in Lean Product development are starting to appear. What can we reuse?
- Group several small agile teams in one unit, managed by an experienced agile team leader, who can coordinate the teams and see opportunities for cooperation.
- Reuse at the right level. Take into consideration the cost of reuse; the wider the scope of reuse, the larger the cost.
- If you use standard components, provide a small list of options. Too many choices means you won’t benefit from reuse; too few choices and chances are that none is a good fit to the problem.
Oh, and if you need to plan and coordinate multiple projects and their dependencies, look up “Critical Chain“.
|
|
