- Property 1.Frequent Delivery
- Property 2.Reflective Improvement
- Property 3.Osmotic Communication
- Property 4.Personal Safety
- Property 5.Focus
- Property 6.Easy Access to Expert Users
- Property 7.Technical Environment with Automated Tests, Configuration Management, and Frequent Integration
- Evidence: Collaboration across Organizational Boundaries
- Reflection on the Properties
- Footnotes
This chapter is from the book
This chapter is from the book
This chapter is from the book
Property 2. Reflective Improvement
The discovery that took me completely by surprise was that a project can reverse its fortunes from catastrophic failure to success if the team will get together, list what both is and isn't working, discuss what might work better, and make those changes in the next iteration. In other words, reflect and improve. The team does not have to spend a great deal of time doing this work—an hour every few weeks or month will do. Just the fact of taking time out of the helter-skelter of daily development to think about what could work better is already effective.
Did you get together at least once within the last three months for a half hour, hour, or half day to compare notes, reflect, discuss your group's working habits, and discover what speeds you up, what slows you down, and what you might be able to improve?
The project that gave me the surprise was Project Ingrid (described in Surviving Object-Oriented Projects (Cockburn 1998)). At the end of the first iteration—which was supposed to be four months long, but they had extended—they were far behind schedule, demoralized, and with what they recognized as an unacceptable design. It was what they did next that surprised me: They released twenty-three of the twenty-four client-side programmers to go back to their old jobs, hired twenty-three new people, changed the team and management structures, paid for several weeks of programmer training, and started over, requiring the new group to redo the work of the first team and make additional progress.
At the end of the second iteration, they again were behind schedule but had a design that would hold, and the team structure and programmers were functioning. They held another reflection workshop, made additional changes, and continued.
When I interviewed them, they were in their fourth iteration, ahead of schedule and content with their design and their work practices.
Since that interview, I have noticed that most of the projects I have visited got off to a rough start or encountered a catastrophe early on. This is so common that I have come to expect, almost even welcome it: from that first catastrophe come all sorts of new and important information about the project's working environment, which would be deadly, but hidden.
On Project Winifred we managed at the end of the first three-month delivery cycle what I called a "bubble-gum" release (the system was just barely held together by the software equivalent of bubble-gum). However, we delivered something every three months, getting better and better each time until we finally delivered the contracted function on time.
After each delivery, a few of us got together. We identified what wasn't working and discussed ways to fix it. We kept trying new strategies until we found ones that worked. Frequent delivery and reflective improvement became critical success factors to us as they are to so many projects.
The people, the technology, and the assignment change over the course of a project. The conventions the team uses need to change to match.
The people on the team are the best equipped to say what is best suited to their situation, which is why Crystal Clear leaves so many details unstated, but for the team to finalize. The reflective improvement mechanism allows them to make those adjustments.
Every few weeks, once a month, or twice per delivery cycle, the people get together in a reflection workshop or iteration retrospective to discuss how things are working. They note the conventions they will keep and the ones they want to alter for the next period, and they post those two lists prominently for the team members to see while working in the next iteration.
Whatever the frequency, meeting format, and technique used, successful teams hold this discussion periodically and try out new ideas. Teams may try, in various forms: pair programming, unit testing, test-driven-development, single-room versus multiple room seating, various levels of customer involvement, and even differing iteration lengths. These are all proper variations within Crystal Clear.
For people to say they are using Crystal Clear, it is not necessary that they continue to use the starter conventions. In fact, it is expected that they will try new ideas. In a Crystal user group meeting, people discuss what they had experimented with, how they felt about those experiments, and how they evolved their working conventions. One team may report moving the meetings from every two weeks to every month, another moving from the format I describe in Chapter 3 to a straight discussion of people's values while developing.
I like to use the reflection workshop described in Chapter 3. Norm Kerth's (2001) book, Project Retrospectives, presents an extended format, along with many activities to try within the workshop. The specifics of the workshop format aren't nearly as significant as the fact that the team is holding one.