| In Chapter 6, I describe Crystal Orange, Crystal Orange Web, and Crystal Clear using three different formats. The Crystal Orange Web format was the newest, and I experimentally recommended it as a faster and simpler way to capture methodology rules. I am happy to report that several people have used that format and have reported back to me that it works well, and fast. Bill Barnett at Wachovia Bank was setting up five concurrent agile teams for the first time. His first group was using an experimental set of conventions, so of course they didn't write them down. A month later, when he set up the second group, the first team conveyed the current set of conventions to the second team verbally, and again they didn't write them down. But by the time the next three teams were getting started, both management and the teams themselves were asking to have the conventions written down. Normally, writing down a methodology is something that takes several months and results in a long document that almost no one reads. Bill feared his task accordingly. I suggested that he simply write the conventions as a list of sentences and then cluster them into topics. This he did, and he wrote to me a few days later, saying that he had drafted the entire document in one afternoon! Another afternoon of review with the team (and touching up the text), and he was done. Greg Luck, then at Thoughtworks (working out of Australia), also picked up that documentation style and became proficient at it. He joined a project and within a few days had captured a first draft of their methodology. Why is this important? For Bill Barnett, a short, readable document was needed so that each new team could go through it and see what they had to set into place. In Greg's case, it was more for the Thoughtworks client than for the development team. The people on the development team knew what they were doing. The client didn't know what conventions the development team was operating under. By producing a document quickly and making it short and readable, the team was able to reassure the client about what was happening, the client did not have to pay months of consultant salary for it, and other departments could see how they would interface with the development team. Here is a summary of how to do this writing: Plan one afternoon for the first draft, and then review each sentence with the team and update it. You may need to update it quarterly as the team conventions change. If you are a member of the team and have been working in a consistent way for several iterations, you may know enough to just sit down and do the writing. If you are coming from outside the team, gather the team for the afternoon and create the sentences together. Have a (fast-typing) scribe use a word processor projected onto a screen so that everyone can see and comment on what is being written. You will probably want a facilitator in addition to the scribe. Capture the sentences in a list. The person doing the typing asks questions for clarification, and the people in the room comment on the content. Don't get locked up in wordsmithing details; just get the ideas down. There will be a review session for correcting small errors.
Write down one sentence for each convention in use. These can cover any topic at all. Here are some possible sentences: "Everyone sits in one room." "Each multi-specialist function team sits together; the different function teams sit as closely together as they can manage." "The marketing and sales representative visits the team each morning to see the progress, answer any questions, and report on changes in the direction of new observations about the market and the competition." "Programmers check in code several times a day." "2:00 to 4:00 p.m. is reserved for focus time each day; people who agree can work on a topic together, but no meetings are called, and outside calls are blocked." "The traffic light (or other information radiator linked to the automated build machine) turns green after a successful build and red when a build fails. Sound broadcasts (e.g., cheer or baby crying) are up to the discretion of each team." "Teams located across time zones have a daily stand-up meeting once a day by telephone to pass along what each has done or is planning to do."
Cluster the sentences by topic (this can be done later). Some will describe basic workflow, such as who hands what sort of decision or document to whom. Some will describe formats, such as the format of the story-tracking board or the use case or the user story. Some will describe communication patterns, such as times of meetings, quiet time, and so on. Some will describe morale-raising conventions, such as playing Doom, or group volleyball games, or the Friday afternoon wine and cheese gathering.
Review the document with the team. If you think you will have trouble completing this review in two hours, get someone who is good at facilitation to lead the session and make sure it doesn't get bogged down. If there is real disagreement on some point, appoint a separate working session with only the people who are concerned with that point, and move on. After that working session, see if you can get agreement to the changed session in the daily stand-up meeting or by email. Review and update the document after the next iteration or after three months at most.
That's it; that's the whole thing. Now try it. |
