If you have been reading this book from the beginning, you should still see one mystery at this point.
Every person is different, every project is different, a project differs internally across subject areas, subsystems, subteams and time. Each situation calls for a different methodology (set of group conventions).
All communication is visible to anyone. I find this plausible using the following comparison with industrial projects:
On an industrial project with a colocated team, trouble comes if the team evolves into a society with an upper and a lower class. If analysts sit on one side of the building and programmers sit on the opposite side, an "us-them" separation easily builds that causes hostility between the groups (I almost wrote "factions"). In a well-balanced team, however, there is only "us", there is not an "us-them" sensation. A key role in the presence or absence of this split is the nature of the background chit-chat within the group. When the seating forms enclaves of common specialists (I almost wrote "ghettos"), that background chit-chat almost inevitably contains comments about "them."
In open-source development, the equivalent situation would be that one sub-group, the colocated one, is thought to be having a set of discussions that the others are not able to see. The distributed people would find it easy to develop a sense of being second-class citizens, cut away from the heart of the community, and cut off from relevant and interesting conversations.
When all communication is online, visible to everyone, there is no natural place for rumors to grow in hiding, and once again there is only "us."
I would like one day to see or do a decent investigation of this aspect of open-source development.
The mystery is how to construct a different methodology for each situation, without spending so much time designing the methodology that the team doesn't deliver software. You also don't want everyone on your project to have to grow into a methodology expert.
I hope you can guess what's coming.
Bother to Reflect
The trick to fitting your conventions to your ever-changing needs is to bother to think about what you are doing.
Individually and as a team, do two things:
Bother to think about what you are doing.
Have the team spend one hour together every other week reflecting on its working habits.
If you do these two things, you can make your methodology effective, agile, and tailored to your situation. If you can't do that, well ... you will stay where you are.
Although the magical ingredient is remarkably simple, it is quite difficult to pull off, given people's funky nature. People usually resist having the meeting. In some organizations, the distrust level is so high that people will not speak at such a get-together.
There is only one thing to do:
Do it once, post the results, and then see if you can do it again.
You may need to find someone within your organization who has the personal skills to make the meeting work. You may need to go outside your organization for the first few times, to get someone with the right personal skills, and whom everyone in the room can accept.
A Methodology-Growing Technique
Here is a small technique for on-the-fly methodology construction and tuning. I present it as what to do at five different times: Right now
At the start of the project In the middle of the first increment Between each increment In the middle of subsequent increments.
After that, I describe a sample one-hour reflection workshop.
Right Now
Discover the strengths and weaknesses of your organization through short project interviews.
You can do this at the start of the project, but you can also do this right away, regardless of where you are in any project. The information will do you good in all cases, and you can start to build your own project interview collection.
Ideally, have several people interview several other people each, and start your collection with six or ten interview reports. It is useful but not critical to interview more than one person on one project. For example, you might talk to any two of the following: the project manager, the team lead, a user interface designer, a programmer. Their different perspectives on the same project will prove informative. Even more informative, however, will be the common responses across multiple projects.
The important thing to keep in mind is that whatever the interviewee says is relevant. During an interview, I don't speak my own opinions on any matter, but use my judgement to select a next question to ask.
In my interviews, I follow a particular ritual:
I ask to see one sample of each work product produced.
Looking at these, I detect how much bureaucracy was likely to be on the project, and see what questions I should ask about the work products.
I look for duplicated work, places where they might have been difficult to keep up to date.
I ask whether iterative development was in use, and if so, how the documents were updated in following iterations.
I look, in particular, for ways in which informal communication was used to patch over inconsistencies in the paperwork. Work Product Redundancy
On one project, the team lead showed me 23 work products.
I noticed a fair degree of overlap across them, so I asked if the later ones were generated by tools from the earlier ones. The team lead said, no, the people had to reenter them from scratch. So I followed up by asking how the people felt about this. He said, they really hated it, but he made them do it anyway.
After looking at the work samples, I ask for a short history of the project: date started, staff changes (growing and shrinking), team structure, the emotionally high and low points of the project life. I do this mostly to calibrate the size and type of the project, and to detect where there may be interesting other questions to ask.
Discovering Incremental Development
That is how I learned the fascinating story about the project I call "Ingrid" (Cockburn 1998).
During just the project inception phase, the team had hit most of the failure indicators I knew at the time. That their first four-month increment was a catastrophe came as no surprise to me. I even wondered why I had traveled so far just to hear about such an obvious failure. The surprise was in what they did after that.
After that first increment, they changed almost everything about the project. I had never seen that done before. Four months later, they rebuilt the project again - not as drastically, but enough to make a difference.
Every four months, they delivered running, tested software, and then sat down to examine what they were doing, how to get better (just as I am asking you to do).
The most amazing thing was that they didn't just talk about changing their way of working, they actually changed their way of working.
The value of this interview lay, not in our discussing deliverables, but in my hearing their phenomenal determination to succeed, their willingness to change, every four months, whatever was necessary to get the success they wanted.
After hearing the history of the project and listening for interesting threads of inquiry to pursue, I ask, "What were the key things you did wrong, that you wouldn't want to repeat on your next project?"
I write down whatever they say, and I fish around for related issues to investigate.
After hearing the things not to repeat, I ask, "What were the key things you did right, that you would certainly like to preserve in your next project?" I write down whatever they say. If the person says, "Well, the Thursday afternoon volleyball games were really good," I write that down. Getting Seriously Drunk Together Once when I asked this question (in Scandinavia), a person said, "Getting seriously drunk together."
We went out and practiced that night, and I did, indeed, see improved communication between the people the next day.
In response to this question, people have named everything from where they sit, to having food in the refrigerator, to social activities, communication channels, software tools, software architecture and domain modeling. Whatever you hear, write it down.