"What are your priorities with respect to the things you liked on the project - which is most critical to keep, and which most negotiable?"
I write those down.
It is useful to ask at this point, "Was there anything that surprised you about the project?"
Finally, I ask whether there is anything else I should hear about, and see where that goes. At one company, we constructed a two-page interview template on which to write the results, so we could exchange them easily. That template contained the following sections:
1. Project name, job of person interviewed (the interviewee stays anonymous)
2. Project data (start / end dates, maximum staff, target domain, technology in use).
3. Project history
4. Did wrong / would not repeat
5. Did right / would preserve
6. Priorities
7. Other
Do this exercise, collect the filled-in templates, look them over. Depending on your situation, you might have each interviewer talk about the interview, or you may just all read the notes.
Look for common themes across the projects. The Communication Theme
At the company where we created the template, one theme showed up across the projects:
"When we have good communications with the customer sponsors and within the team, we have a good outcome. When we don't have good communications, we don't have good results."
Although that may seem trivially true, it seldom gets written down and attended to. In fact, within a year of that result, the following story occurred at that company: The Communication Theme in Action
Mine was one of three projects going on at the same time, each of which involved small teams with people sitting in several cities.
As you would expect I spent a great deal of energy on communications with the sponsors and programmers.
The three projects completed at about the same time. The director of development asked me the difference could be, that the project I was on was successful, while the other two that ran at the same time were unsuccessful.
Recalling the project interviews, I suggested it might have something to do with the quality of communication between the development and sponsoring groups, and within the team.
He said this was an interesting idea. Both the programmers and the sponsors on the other projects had both reported problems in communicating with their project leads. Both programmers and sponsors had felt isolated. The sponsors of my project, on the other hand, had been very happy with the communications.
The theme was different in another company. Here is what one interviewee told me: The Cultural Gap Theme
Our user interface designers all have Ph.D.s in psychology and sit together several floors above the programmers. There is an educational, a cultural, and a physical gap between them and the programmers. We have some difficulty due to the different approach of these people, and to the distance we sit from them. This company will need extra mechanisms to increase contact between those two groups of people and extra reviews of their work..
The point of these stories is to highlight that what you learn in the interviews is likely to be relevant on your next project. Pay attention to the warnings that come in the project interviews.
At the Start of the Project
Expect to do some tailoring to the corporate methodology standard. This will be needed whether the base methodology is ISO9001, XP, RUP, Crystal, or a local brew.
Stage 1: Base Methodology to be Tuned
If possible, have two people work together on creating the base methodology proposal for the project. It will go faster, they will spot each other's errors, and they will help each other come up with ideas.
They have four steps to go through:
Determine how many people are going to be coodinated, and their geographic distribution (see the grid in Figure 5-21). Decide what level of correctness is expected of this software, what degree of damage it could cause. Determine and write down the priorities for the project: time to market, correctness, or whatever they may be.
Using the methodology design principles from Chapter 4, select the basic parameters for the methodology: how tight the standards need to be, the extent of documentation needed, the ceremony in the reviews, the increment length (the time period until running code is delivered to real, if sample, users). If the increment length is longer than four months, they will have to find some way to create a tested, running version of the system every four months or less, to simulate having real increments.
Select a base for the methodology, one not too different from the way they would like to work.
Recall that it is easier to modify an existing one than to invent one from scratch. They may choose to start from the corporate standard, the published Unified Process, XP, Crystal Clear, Crystal Orange, or the last project's methodology.
Boil the methodology down to the basic work flow involved - who hands what to whom - and the conventions they think the group should agree to.
These steps could take between a day and a few days for a small or medium-sized project. If it looks like they will spend more than a week on it, then get one or two more people from the project team involved and drive it to completion in just two more days.
Stage 2: The Starter Methodology
Hold a team meeting to discuss the base methodology's work flow and conventions, and adjust it to become the starter methodology. For larger projects, where it is impractical to gather the whole team, gather the key representatives of each job role. The purpose of the meeting is to Catch embellishments Look for ways to streamline the process and ways to communicate with less cost Detect other issues that did not get spotted in the baes methodology draft Consider these questions in that meeting: How long are the iterations and increments to be (and what is the difference)? Where will people sit? What can be done to keep communication and morale high? What work products and reviews will be needed, at what ceremony levels? Which standards for tools, drawings, tests, and code are mandatory, which just recommended? How will time reporting be done? What other conventions should be set initially, and which might be evolved over time? An important agenda item for the meeting is selecting a way for the team to detect morale and communication problems.
The meeting results will include: Basic work flow
Hand-off criteria between roles, particularly including overlapped development and declaration milestones Draft standards or conventions to be followed Peculiarities of communication to be practiced This is your starter methodology. The meeting could take half a day, but should not exceed one day.
In the Middle of the First Increment
Whether your increment length is two weeks or three months, run a small interview with the team members, individually or in a group meeting, at approximately the mid-point of the increment. Allow one to three hours.
The single question for resolution is, "Are we going to make it, working the way we are working?"
In the first increment, you can't afford to change your group's whole way of working unless it is catastrophically broken. What you are looking ofr is to get safely to your first delivery. If the starter methodology will hold up that long, you will have more time, more insight and a better moment to adjust it, after you have successfully made your first delivery.
Therefore, the purpose of this interview or meeting is to detect whether something is critically wrong and the first delivery will fail.
If you discover that the team's way of working isn't working, first consider reducing the scope of the first delivery.
Most teams overstate how much they can deliver in the first increment - to me, this is simply normal, and not a fault of the methodology. It is a result of overambitious management driving the schedule unrealistically, and overly optimistic developers, who overlook the learning to be done, the meetings to be held, the normal bugs they put into the code. It comes from underestimating the learning curve of new technology and new teammates. Overstating how much can be delivered in the first increment is actually quite normal.
Therefore, your first approach is to reduce scope.
You may, however, discover that reducing scope will not be sufficient. You may discover that the requirements are incomprehensible to the programmers, or that the architects won't get their glorious architecture specification done in time.
If this is the case, then you need to react quickly and find a new way of working, which, combined with drastically reduced functional scope, will allow you to meet that first delivery deadline.