TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
Ours was a reasonably typical enterprise distributed networking project. It consisted of around 1,000 C++ classes in 60 different program executables. Each customer deployment supported 10,000 to 500,000 clients. The system involved around a dozen different types of servers — accounting, system watchdog, state maintenance, and so forth. Security and reliability were the paramount concerns. Performance was second, and features were a distant third.
The company was a startup, so we were tight on both cash and time. The company was typically operating with between -30 and 180 Days ‘Till Broke. Our contracts all had lead times of 3-5 years. This meant that sales had to start at the same time as engineering. Thus, engineering had to produce many sales demos and to frequently alter the product to more closely fit the needs of a particular customer.
Due to these influences, we chose a software process with rapid feedback and change. We ran the shortest iterations we could (1 week) to get the most data possible. We tracked our metrics closely, and we ran several experiments each iteration. We used the metrics to decide what worked and to what degree. We then adopted those things that worked and started the next set of experiments.
Chief among these experiments were variations on
§ How to handle task ownership,
§ How to assign tasks to people, and
§ Which style of Pair Programming to use.
Agile . since Jun 23 . Index . DOCs TOP TOC
The Flow mind state [1], [2] is one of intense focus. The entire problem and solution spaces are loaded into the developer’s head. Programmers work orders of magnitude better when in Flow.
Pair Flow is similar to Flow. The solution and problem spaces are shared between the minds of the participants. Again Pair Flow works significantly better than pair programming without flow.
Unfortunately, it takes a long time to get into either Flow state. Both can be easily interrupted. Changing tasks or swapping pairs forces a restart. Pair Flow is more resilient to interruptions such as the phone, but it still gets interrupted frequently throughout a typical day.
It often takes days for a given pair to be comfortable enough with each other to be able to achieve Pair Flow at all. This means that pairings tend to be long. The longer the mean time between pair swaps, the less effectively pair net distributes information through the team.