Note 10 Jan 2008:
See "Evolutionary Methods (Evo) at Tektronix: A Case Study" by Frank Goovaerts and Doug Shiffler, Proceedings of the PNSQC 2006 (11Mb!), page 63.

US company

This fall, 2004, we introduced Evo at a new US client. Very professional developers, eager to become even better. We started a pilot with a subset of the project, with about 15 of the software people, to test the validity of the Evo claims. There are more software developers in this project, both in the US and India, as well as hardware developers.

The introduction process was "designed" very carefully:

• First one hour with the Product Manager (who's project we selected as pilot). Short presentation about the basic Evo ideas. He agreed to try Evo.
• Then half a day with Project Manager (he has to do the actual work), discussing his project and how we could start. He agreed.
• Then a one day workshop: morning tutorial, afternoon working with the team. At the end of the day the team could disagree or agree to continue with Evo. If agree: commitment for the next three weeks. They agreed.
• The morning tutorial was attended by more people than the pilot-team, so that people around this team will be knowing what is going on and don't start asking strange questions.
• When the people went to lunch on the workshop day, I did a one hour presentation for higher management. They didn't object.
• During the workshop-afternoon, we organized only 3 people's work for the next week, because that was enough for the group to get the idea. The day after the workshop, the PM did 1-to-1's (see 2nd booklet, chapter 6.9, item 2) with the people who did not yet organize their work for the next week. This way I could coach them on how to do these 1-to-1's.
• At the end of the 1-to-1's, we held a team meeting (see 2nd booklet, chapter 6.9, item 3).
• The first day I met the PM, he couldn't tell me whether he would succeed a defined milestone after six weeks: "Aggressive schedule, may not succeed". When I returned, two weeks later, he said "No problem, we'll be done two weeks early".
• In an internal survey, after 3 weeks, the people of the team were asked to answer three questions:
  • What do you like about the method?
  • How do you think we can improve the method?
  • List at least one thing you do not like about the method. (This question was designed to invite any resistance into the open)
• Main responses: Evo adds focus and accountability, less wasted time, less duplication of effort, excited about the possibility of improving our quality
• Things people "did not like" (can't go into detail because of confidentiality) were mainly related to Evo issues we did not yet introduce and will introduce shortly.
• After 3 weeks: they still want to go on with it.
• Finally they met their six week milestone just 1 day early. That's much better than before. 100% done usually takes more time than we normally anticipate...

Several go/no-go moments were designed in to avoid people feeling pushed into this new way of working. Persuasion by Results works, especially if the results take only a short time to materialize.

The next step will be to:

• Include the other people of the project.
• Add more Evo methods gradually. We only started with introducing the TaskCycle (see 2nd booklet, chapter 6.1), so now we can add the DeliveryCycle, to focus the work, and TimeLine, to connect the short-term TaskCycles to the longer-term goals of the project. After that, we can hone the process with adding Evo Requirements Engineering and Delivery optimization techniques, while constantly optimizing whatever we do, actively using Plan-Do-Check-Act, with a focus on Return-on-Investment for everything we do.

Niels Malotaux, Project Coach
niels@malotaux.nl
www.malotaux.nl/nrm/Evo