Alistair Cockburn - Agile Software Development

You may notice that many of the foregoing stories use surprising low-tech items, with much use of paper and cardboard. O'Dell (1998) wrote about the World Bank's successful knowledge management and transfer experiences with an appropriate lesson: "For best results, take one spoon of low-tech and one spoon of high-tech. Mix and drink."

Watching and Listening

Humans have a knack for learning by watching as well as by doing.

Wenger and Lave (1993) discuss success and failure in apprenticeship-based professions. They highlight the value of line-of-sight and line-of-hearing learning in these professions. After I read the book, I made the following unhappy discovery: Line-of-Sight Design Learning

As I walked into our programmer's room, I saw all the programmers staring at their own screens! There was no line-of-sight learning anywhere in the room.

I had the chance to change the situation somewhat a few weeks later. When someone asked a design question, I made sure we discussed it at the whiteboard or said our ideas out loud.

It took another month or two, but eventually I could hear the designers talking about their designs using the words and ideas we had been building up in the room over the previous month.

This room set-up is the basis for the "Expert in Earshot" strategy (Cockburn 2000), which is further developed in Convection Currents of Information. [book? Date?]

Programming in pairs is a programming technique that provides line-of-sight-and-hearing learning. Larry Constantine (1995) found this technique so effective that he nicknamed Brian Kernighan's use of pair programming "dynamic duo" teams. Pair programming has been repopularized largely through Extreme Programming (Beck 1999). Groups who practice pair programming report faster learning of both programming techniques and problem domain, as well as faster code production and lower defect rates (Cockburn 2001).

Supporting Concentration and

Communication

Software development as a both thinking-intensive and communication-intensive activity presents an interesting dichotomy.

Programmers need sufficient quiet time to get into a quiet and productive mode known as flow (Csikszentmihalyi 1991). After spending 20 minutes getting into a state of flow, it takes only a minute or two of other conversation to disrupt it.

Every project team should find a way to provide quiet times sufficient to get into flow and protect those times. DeMarco and Lister (1999) suggest designating two hours as quiet time every day, turning off all phones and banning all meetings during this time. I watched one organization adopt this convention. It was so appreciated, from the CEO on down, that among three dozen suggestions for improvements to the company's working habits this was uniformly acclaimed the most critical.

XP recommends a "caves and common" room layout (Auer 2001). The center of the room is used for group work: tables with 2-6 workstations and space for two people at each workstation (see Figure 3-??). [Fill in reference.]The outside of the room is set up with individual areas where people put their bags, make phone calls, answer e-mail messages, and so on. With this layout, the people have close access to other people while they are designing and private space for their personal needs.

I have found no consensus on the question of private offices versus shared workspace. People regularly tell me that they have produced their best work when they shared an office with someone else on the project or worked in war-room seating. Some say that they enjoyed the quiet of their private offices but produced better work when they didn't have a private office. Others, however, are so strongly attached to their private offices that they would quit rather than move into a shared workspace. That may be too high a price to pay for communication.

Personality-Matched Work Assignments

For people to perform as well as they can, it helps if their job assignments are aligned with the strong points of their personalities, not their weak points. Methodologies name the roles that must be present on a project but don't mention the personality characteristics required for each role.

Here are three examples of a person whose personality characteristics did not match those required for the role. The Socially Minded Manager

Once, on a large multiteam project, the cross-team manager was socially minded to the extent that he did not want to offend anyone.

As a result, he would not make those hard personal and priority decisions that are exactly what the cross-team manager is hired to make.

The Non-Verbal Team Lead

The person hired as lead programmer and mentor was a stereotypical noncommunicating programmer.

Rather than coach the novice programmers on improving their programming skills, he simply changed their code when they weren't around!

The Concrete-Thinking OO Designer

One person on our OO project desperately wanted to learn object-oriented programming. He seemed unable to get his thinking to an abstract enough level to generate good OO designs, though.

After much coaching for six months, his programs still looked like the user interface or the relational database.

What could be done with these people, instead? On the first project, the person was too high on the project ladder to be replaced, and so the project continued to suffer. On the second project, the person was eventually replaced with someone who had good communication skills, who taught the novice programmers basic OO design skills.

On the third project, we were luckier. The person was spectacularly good at defining requirements, where his careful thinking and attention to detail paid off. In exchange for his working on the requirements, he continued doing OO design and programming on sections of the system where the quality of the design was not a critical issue. Everyone benefited: He had fun doing the programming, and the project was safer due to the high quality of his requirements work.

Talent

The best programmers on the team may be so much better than the rest that just a few of the best programmers can put out more than all the rest combined. eBucks.com Goes Live

The top programmer at a consortium of banks, called the First Rand Group, in South Africa managed to get the company's new eBucks system out in just three months. I asked him how he managed that feat. He said that he and one other person had personally programmed it.

I nodded as I heard this. "The old solution. Get the best two programmers to sit together and program it up rather than coordinate 20 people through a fancy methodology.” But that left an open question. I knew that he had many other duties and would have to attend so many meetings that he couldn't possibly concentrate enough to program. I asked him about that.

He answered, "I attended meetings until 5 p.m. or so and then wrote code from 6 p.m. until 2 a.m. each day."

Oh. Another far-too-obvious solution. Have the two best people work back-breaking hours for several months. Painful, but effective. This combination of talent and practiced skill I call "personal prowess." Although a manager can increase the skill of the team members by encouraging them to learn and sending them to courses, he can't change the talent level of the team. A talented designer will still outperform an average designer with good skills.

John Wooden, the famously successful college basketball coach, considers talent such a key issue that he labeled his first coaching secret, "Secret #1: The team with the best players almost always wins." (Hill 2001, p. 63)

Rewards that Preserve Joy

Inventing reward structures is tricky. I recently got tripped up on this myself, in what I thought was a simple work-reward situation: Picking Dandelions

Dandelions were beginning to clutter our back yard. Having three children aged 10 –and under, I concocted a brilliant solution: I offered them one cent per yellow flower and ten cents for any dandelion in the seeding stage. For five to ten dollars a year, I thought, we'd get rid of dandelions in a few years. The kids brought in bags of dandelions, and I paid out the cash.