Collect the suggestions. If the list gets very long, question how many new practices or habits the group really wants to take on during this next period. It is sometimes depressing to see an enormous list of reminders. It is more effective to have a shorter list of things to focus on. Writing on a single flipchart with a fat flipchart pen is a nice, self-limiting way of handling this.
Periodically, see if someone has thought of more good things the team is doing that should be kept.
Toward the end of the workshop, review the list. See if people really are in agreement to try the new ideas, or if they were just being quiet.
After the workshop, post the list where everyone can see it.
At the start of the next workshop, you might bring in the poster from the previous workshop, and start by asking whether this way of writing and posting the workshop outcome was effective, or what else you might try.
Holding this meeting every two to six weeks will allow your team to track its local and evolving culture, to create its own, agile methodology.
The Value of Reflection
The article on Shu-Ha-Ri excerpted in Chapter 2 continues with the following very relevant discussion of reflection:
Consider "agile" as an attitude, not a formula. In that frame of mind, look at your current project and ask, "How can we, in this situation, work in an agile way?"
"As you learn a technique, and as it asymptotically approaches your mental model of the technique as you see others practicing it, you can begin to reason about the technique. It seems the important questions to ask are:
1. How does this technique work?
2. Why does this technique work?
3. How is this technique related to other techniques that I am practicing?
4. What are the necessary preconditions and postconditions to effectively apply this technique in the combatitive situation? ...
As you develop a reasonable repertoire of techniques that you can perform correctly, you will need to expose yourself to as broad a range of practitioners as possible. As you watch others, you need to ask and answer at least three questions:
1. Which other practitioners do I respect and admire?
2. How is what they do different from what I do?
3. How can I change my practice (both mental model and attempts to correspond to it) to incorporate the differences that I think are most important? ... The questions you need to ask yourself about a competition in your post mortems are:
1. Were you able to control the pace and actions of your opponents.
2. Were you able to keep calm and make your techniques effectively with an unhurried frame of mind.
3. Does your competition look like those of the practitioners you admire. ...
Throughout all of this, you must honestly evaluate the results of each 'test'. Cycle back to Shu through Ha and then Ri as you go down dead end paths."
I couldn't say it better.
Look for how far you are from the sweet spots in your development team. See how creative you can be in getting closer to, or simulating them. Look for where your team can lighten its methodology. Look for where it is not-yet sufficient. Perform one project interview as described. Get several people to perform one each, and share results. Find the common thread in your interview results. Hold a one-hour reflection workshop within your project. As you encounter difficulty in this, reflect on which aspects of people are showing up; compare them to the list I gave in Chapter 3. Look for antidotes and extend my list. Post the reflection workshop flipchart, and check how many people ever look at it. See what it takes to hold a second one. Learn how to get people to complain less and make more positive suggestions a these workshops.. Develop yourself into a Level 2 methodology designer. Yes, it is part of your profession.
This chapter describes how I resolved the dilemmas involved in methodology design: the difficulty of communication, the need for people to be people within the methodology, and the need for multiple methodologies. I chose to construct a family of methodologies, along with principles for tuning them. This is not a kit of methodology parts for you to assemble on your own, but a set of samples that you adjust to your circumstances.
"Crystal" is the family name for the methodologies. As with geological crystals, each has a different color and hardness, corresponding to the project size and criticality: Clear, Yellow, Orange, Orange / WebStream, Red, Magenta, Blue and so on. Each one Is people-and-communication centric Gets adjusted to fit its particular setting Works from the project tolerance level and the bottleneck activities to an answer that matches the project ecosystem. This chapter describes three members of the Crystal family that have been put to use on live projects: Crystal Clear, Crystal Orange, and Crystal Orange / WebStream. For each one, I Describe the characteristics where the methodology is appropriate Describe the methodology itself Reflect on the construction of the methodology The reason for including this chapter is to show one way of working through the problems and principles surrounding methodology design, and to give you something to copy and alter when you start on your own.
Two plausible responses to the problem of needing multiple methodologies are to Create a kit of methodology parts that the project team assembles for their project, and to Create a copy-and-alter family of specific methodologies that get tailored on each project.
Rational Corporation used the kit approach in the first generation of their methodology product, the Rational Unified Process (Krutchen 1999). RUP is a framework for constructing methodologies for individual projects. It is centered around processes, work products and tools, with a collection of "best practices" to guide the practioner along the way
The assembling of a correct methodology for a RUP project hinges around creating a "development case" for the project, and then assembling the parts from the RUP kit that fit the development case (Larman 2001).
The standard mistake managers make is not to do that assembling and tuning. They drop the library of work products on the development team and say, "Do that." The developers do one of two things: They recognize that producing all of those work products will damage the project, so they ignore the manager's instructions; or They do as they are told and produce all of those work products (and damage the project accordingly).
RUP is not incompatible with the principles developed in this book, but it doesn't naturally lead people to focus on the two key success factors, communication and community.
My hope is that after reading this book, managers who buy RUP will allocate time to get it tuned it to their projects. I also hope that the people who do the tuning will cut down the required work products produced to the smallest possible set, and augment RUP with attention to communications, community, concurrent development and so on.
Crystal Family
An alternative way of approaching methodology-per-project is to collect a set of concrete, sample methodologies that have been used on projects, and let the people on the project use the tailoring techniques described in the last chapter to adjust them on the fly.
This is the approach Jim Highsmith and I are following. We are collecting examples of successfully used, communication and community based agile methodologies that people can use as starting points.
By seeing one that is already written, the new project team can see how the communication and community issues were addressed in a real situation. By having a set of examples to choose from, the team can find the one that most closely matches their situation.
I nickname the ones I design, "Crystal."
The word Crystal serves two purposes.
First, it is just a pleasant name. In the book, Crystal Clear, I create a protagonist called Crystal to personify the methodology, and argue for its design.
Second, it provides a metaphor that supports the first two degrees shown in the project grid in Figure 4-21.
Moving right in the grid means coordinating more people, which means a heavior methodology is needed. In the crystal metaphor, moving right corresponds to choosing a darker color (clear quartz, topaz, ruby, sapphire).
Movement up in the grid corresponds to more potential damage from the system., and the use of more rigor and ceremony. In the crystal metaphor, moving up means increasing "hardness" (in the mineral hardness scale, diamonds, the hardest stone, receive the harness number 10).
Thus, in the crystal metaphor, two people programming the overtime food menu are working on a project that calls for a soft, clear quartz crystal methodology. The two people programming the movement of boron rods in a nuclear reactor are working on a project that calls for a diamond-category methodology.
Of the two dimensions, I find the color dimension the more useful as the project index. The hardness dimension can be more easily picked up in the methodology tuning workshops.
I therefore index the Crystal methodologies by color: Clear, Yellow, Orange, Red, Magenta, blue, violet, and so on (Figure 6-1).
Figure 6-2. The Crystal methodologies are named by color. In Figure 6-1, I omit life-critical systems from the shaded areas. This is because I have not worked on or interviewed life-critical-system projects, and so don't have enough information to say exactly how an agile life-critical project looks.
The gray E6 box, outside Crystal Clear, indicates that Crystal Clear does not explicitly address "essential moneys" projects, but that the team may be able to stretch Crystal Clear to such a situation.
The other restriction on Crystal methodologies is that they only address colocated teams. As discussed earlier, none of the distributed and off-shore development projects I have seen would count as methodologically successful. They only recommendation I have for such projects is to put the team together at one location.