Your goal is to delivery something, some small, running, tested code in the first increment. This is a critical success factor on a project (Cockburn 1998). Once you deliver this first release, you will have time to pause and consider what is happening.
After each increment
Hold a team reflection workshop after each increment.
Bothering to reflect is a critical success factor in evolving a successful methodology, just as incremental development is a critical success factor in delivering software.
The length of this reflection workshop may vary from company to company or country to country. Americans like to be always busy, short of money and on the run. I see Americans allocating only two to four hours for this workshop. In other parts of the world, the workshop may be given more time.
I once participated in a two-day offsite version that combined reflection, team-building, and planning for the next increment. It took place in Europe, not surprisingly.
The dominant reason for delaying this workshop until after the first increment is that you can only properly evaluate the effects of each element in your methodology after you have delivered running, tested software to a user. Only then can you see what was overdone, and what was underdone.
There is a second reason for holding the workshop at the end of the increment: People are quite often exhausted after getting the software out the door. This meeting provides a chance to breathe and reflect. Done regularly, it becomes part of the project rhythm. After each increment, the staff benefit from a short shifting of mental and social gears.
Whether you take two hours or two days, the two questions you want to address are: "What did we learn?" "What can we do better?"
The responses may cross every boundary of the project, from management intervention, to timecards, group communication, seating, project reviews, standards, and team composition.
Very often, teams tighten standards after the first increment, get more training, streamline the work flow, increase testing, and reorganize the teaming structures.
The changes will be much smaller after the second and subsequent increments, since the team has already delivered several times.
In the Middle of the Subsequent Increments
After the first increment, the team has established one (barely) successful way of working. This is a methodology design to fall back on, if needed.
Having that as a fallback plan, you can be much more adventuresome in suggesting changes in the mid-increment meetings you hold in the second and later increments.
In those mid-increment meetings, and particularly after the second successful delivery, look to invent new and better ways of delivering.
See if you can do any of the following: Cut out entire sections of the methodology. Do more concurrent development Use informal communications more to bind the project information Introduce new and better testing frameworks Introduce new and better test-writing habits Get closer collaboration between the key groups in the project, between domain and usage experts, programmers, testers, training people, the customer care center, and the people doing field repair.
You might use interviews or a reflection workshop for these mid-increment adjustment. By this time, your team will have had quite a bit of practice with these meetings, and will have an idea of how to behave.
You may omit the mid-increment workshops if the project is using increments three weeks or shorter.
Why bother with mid-increment reviews, when the project is already delivering, and you already have post-increment reviews in place?
In the middle of the development cycle, those things that are not working properly are right in people's faces. The details of the problems will not be as clear four or six weeks later, at the post-increment meeting. Therefore, you can pick up more details in the middle of the increment, get feedback immediately about the idea, and try out a new idea the same day, instead in several weeks or months.
What if a new idea doesn't work out?
Sometimes the team tries a new idea on the second or third increment, and finds that the idea simply does not work well. Mid-Project Team Structure Changes
On one project, we went through three different team structures during the third increment.
A short way into the third increment, we decided that the team structure we had been using was weak. So we chose a new team structure to use on increment three.
It was catastrophically bad. We knew within two weeks that we had to change it immediately. Rather than revert to the original, awkward but successful team structure, we created a new suggestion and tried it out right away.
It turned out to be successful, and we kept it for the duration of the project. In inventing new ways of working in these later increments, you create the opportunity to significantly improve your methodology. This is an opportunity not to be missed.
The Post-Project Review
Given the mid- and post-increment reflection workshops, I place less emphasis on having a post-project reviews. I feel that the time to reflect is during the project, when the reflection and discussion will do the project some good. After the project, it is too late.
Usually, I find that teams that run post-project reviews did not bother to reflect during the project, and suddenly wants to know how to do better for the next project. If you find yourself in such a meeting, put forward the suggestion that next time, you want to use incremental development, and hold postincrement reviews instead.
Nonetheless, it may be that the post-project review is the only time you get to make statements regarding the staffing and project management used. If this is the case, I suggest getting and using the book Project Retrospectives (Kerth 2001), which describes running a two-day post-project review.
If you hold a post-project review, think about who is going to make use of the information, and what they can really use, as they run their next project. You might draft a short (two-page) set of notes for the next project team to read, outlining the lessons learned from this project.
Of course, you might write yourself a one-page lessons learned reminder after each of your own increments, as a normal outcome of your reflection workshop.
A Reflection Workshop Technique
The tangible output of a mid- or post-increment reflection workshop is a flipchart that get posted on the wall in some prominently visible place and seen by the project participants as they go about their business.
I like to write directly onto the flipchart that will get posted. It is the one that contains the group memories. Other people like to copy the list from the scratched- and scribbled-on flipchart to a fresh sheet for posting. The people who created the one shown in Figure 3-10 decided to use sticky notes instead of writing on the flipchart.
A Sample Reflection Workshop Technique
There are several different formats for running the workshop, and for sharing the results (of course). I tend to run the simplest version I can think of. It goes approximately like this:
A Reflection Workshop
Hi, welcome to this workshop to reflect on how we can get better at producing our software. The purpose of this meeting is not to point fingers, to blame people, or to escape blame. It is to announce where we are getting stuck, and nominate ideas for getting past that stuckness.
The outcome of this workshop will be a single flipchart on which we'll write the ideas we intend to try out during the next increment, the things we want to keep in mind as we work. Let's break this flipchart into three pieces. On the left side, let's capture the things we are doing well, that we want to make sure we don't lose in the next increment.
On the right side, let's capture the new things we want to focus on doing.
On the supposition that the list of what we're doing right will be the shorter of the two, let's write down the major problems we're fighting with, halfway down the left side here (see Figure 6-1).
Let's start with what we're doing right. Is there anything that we're doing right, that we want to make sure we keep around for the next increment?
Figure 6-1. Sample poster from reflection workshop.
At this point some discussion ensues. It is possible that someone starts naming problems, instead of good things. If they are significant, write them down under the Problems section. Allow some time for people to reflect and discuss.
Eventually, move the discussion along:
All right, what are some of the key problems we had this last time, and what can we do to improve things?