Introducing Crystal Clear by Jonathan House In March of 2005, I had just taken a management position with Amirsys, a medical informatics company. I was excited about joining a new company but feeling a sense of resignation at all of the heavy lifting that was in front of me to get the new company to adopt an agile approach to developing software. The sense of resignation was from my previous experiences as an "agile mentor," working to bring agile software development practices into various companies I had consulted with. In each case, the new practices were well received but never really caught on, for a variety of reasons. As I was preparing to leave our monthly Salt Lake Agile roundtable meeting, Zhon Johansen, a long-time XP practitioner and one of the roundtable "old-timers," approached me. Like me, he was intrigued by the clean slate that Amirsys presented, but unlike me, he wasn't carrying my sense of resignation. He had an ideaself-organizing adoption of agile practices. Rather than my pushing the practices onto the team, he suggested that it would be interesting to see what practices the team would adopt when given specific "stimuli." I liked the idea because it would allow me to become a "minimalist" project manager (or "maximalist," as one person corrected meI get the maximum results from each action). My sense of resignation was gone, just like that. Although I had experience with XP, Scrum, DSDM, and FFD, I decided to use Crystal Clear as our methodology framework, partially because the lightweight approach appealed to me, and partially because of my existing relationship with its progenitor, Alistair Cockburn. The very next day I reached my first crisis with my new philosophy as I started to prepare to fight with the executive team about the need to adopt an incremental, iterative approach. This was always the first fight I fought in my other mentoring engagements. I stopped. I closed the door of my office, closed the shades, turned off the light, and started thinking about how to get the executive team to decide that they had to have iterations. It was then that I remembered a lesson from my high school biology class. Put simply, the executive team had to "feel the pain." I walked into the director's meeting armed only with a notepad and a goal of ferreting out the pain that would lead to a realization that an iterative approach would be the necessary cure. As soon as the meeting began, I realized that I wasn't going to have to work very hard to get the executive team to feel the pain. First on the agenda was a discussion of how to get the development team to be more responsive to changing business requirements. After about 10 minutes of carefully directed questioning on my part, the president of the company said, "Is it possible to get the development teams to deliver just a part of the functionality that we need more frequently?" I grudgingly agreed that it may be possible and that I would see what I could do with the development teams to get them to deliver functional code on a more frequent basis. As I walked out of the meeting, I was shocked to realize that we had become an incremental development shop without so much as a single Power-Point slide shown. Now that I was mandated to implement iterations, it became clear that a lack of automated tests would be a serious drag to us. Continuing the experiment, and looking to install the right pain in key places, I asked that we increase the formality of the testing process. Pain immediately set in. Testing became an "all hands on deck" operation that completely halted other efforts. For a full two weeks, this pain went on, and not once did I mention "automated tests" or "test-first development." At the end of the iteration, I got the team together and asked them if they thought it was a good idea to talk about the previous iteration (thereby introducing the reflection session practice). After letting the team vent about the pain of the testing process for a while, I said, "You know, it would be nice if we were able to automate most of the testing effort, wouldn't it?" The development team decided that it would be a good idea to write code-based tests while they worked on application features. Our director immediately allocated resources to develop automated tests and reduce the 80 or so pages of manual tests. I still hadn't given that two-hour long PowerPoint presentation about how automated tests are a good idea. The pattern had emerged, and the best part was that it was self-reinforcing. As our development teams reached a point where a specific agile practice was needed, I went looking for the pain. After I found it, I made it a point to ensure that everyone felt that pain. As soon as the pain was established, I would lightly introduce the team to the needed practice and then get out of their way. One of the developers mentioned that a critical user story had been missed in the last iteration planning session. I took the developer aside after the meeting and showed him the "iceberg list" (Figure 5-12 in Crystal Clear). I came in the next day to discover that our backlog lists had been reorganized into iceberg lists. The new approach worked with the executive team as well. Executive team members were introducing conflicting priorities on the goals of the iteration (this is known as "feature thrashing"). So, I began convening meetings in front of the iteration chart (Figure 5-22 in Crystal Clear) whenever a change was requested mid-iteration, with the development team and all of the executive team stakeholders. Not only did the executive team members resolve the conflicts themselves, but they now go directly to the iteration charts on their own initiative to discuss changes to the functional goals of the iteration. Strangely enough, with all of this success, I still wasn't happy. As a project management minimalist, I felt I was doing all of the pain discovery and "inflammation." Our daily stand-up meetings were taking too long, and I could tell one of the developers was getting annoyed and spacing out during the meeting. Rather than policing the meeting as I might have done before, I just showed him the one-page description of the stand-up meeting in Crystal Clear. The next day, he objected during the meeting that it was taking too long and started enforcing the correct, shorter format. Today, Amirsys is a great place to be a project manager. We can tell the state of every project simply by walking into the developer area and looking at the walls. Developer team members handle most of the status reporting tasks themselves. There are several copies of Alistair's Crystal Clear book floating around the office, and we have matured to the point where team members are starting to identify "pains" on their own and look for applicable solutions. And I still have yet to create a single PowerPoint presentation. | 