Introduction

Connextra is a two-and-a-half-year-old company with 35 employees, working with Internet technologies. When the company was started, the founders were interested in using XP to create their first product. To this end, the company (right down to the design of the office) was based on XP principles.

The Physical Environment

One of the key XP principles is to program in pairs, and from the second week of development, convex desks were installed to facilitate side-by-side paired programming. There are no individual desks or computers, so for access to e-mail, there are some "Web café" style machines, where any developer can log in as required. There are also several screened booths that are equipped with phones, where personal calls can be made, or individual work can be performed. Furthermore, each developer has a locker, where they can keep personal items.

Twenty Iterations and Counting

We have been working in this environment for 20 iterations, each lasting three weeks. Every morning we gather around a planning board and hold a stand-up meeting, where we discuss the progress on yesterday's tasks, select new partners, and focus on completing the remaining tasks in the iteration. We have found that we have become very good at this mode of work and have rarely missed a delivery target. We have really seen the benefits of applying the XP process to customer requirements.

Story Processing Machines

As a team, we have a real sense of accomplishment and are always striving to improve our velocity and deliver greater value to our customers. To this end, we are constantly looking at our storyboard and trying to check off as many stories as possible. We have become a software factory in the true sense. Worryingly, we began to observe that we were missing something.

Religious Guilt

In conversations with colleagues in other companies, we noticed that we were missing the ability to sit alone at a desk and try out ideas, untroubled by the work of the rest of the team. These colleagues were able to "waste time" on nondeliverables without suffering from the "religious guilt" that such time was not contributing to the project velocity.

In our working environment there were only two legitimate places to be for any length of time: (1) at a development machine, pairing, or (2) at a Web café machine, checking and replying to e-mail. If you weren't in either place, you felt that you were wasting time. There was no place to be where you could think of new things without feeling guilty. However, any development effort needs to look continually for innovations in technology and process, which often come from the lateral thinking of individuals rather than a collective focus on task completion.

Spikes Were a Delay

Once the team had finished the iteration and were preparing for the next planning game, we found that we weren't always able to accurately estimate items being introduced in new user stories. In those cases, we took several days to spike potential solutions and play (to a limited extent) with new technologies. Although this helped us give accurate estimates, unfortunately the users viewed it as an activity that was getting in the way of starting the next iteration. We also noticed that this time rarely allowed us to experiment with blue-sky possibilities, because our mind-set was constrained by the existing expectations of both customers and developers. Customers didn't know what possibilities existed, while developers didn't know whether they were feasible (if requested).

Positive Recognition

As we have been working together, we have formed a real sense of team. We pair with each other, share knowledge, and have a collective responsibility to make sure that the best job gets done. In a "no blame" culture, there also needs to be room for positive contributions that don't detract from the sense of team. Many team members had some great ideas but found that there was no way to explore them without feeling that they were letting the rest of the team down. It is a perfectly human impulse to want to impress your peers with new ideas, but not at the expense of leaving other team members to bear the burden of finishing the committed work.

The Dreaded Review

As the company grew, more formal personnel procedures were introduced, including a regular review process. This was viewed as a healthy addition to our working practice. However, in a team-based process like XP, it was difficult to point to specific achievements that would enable individuals to be recognized and rewarded. We tried agreeing on action points that would be reviewed in the next period; however, in our software machine, there was never a good way to make sure that these points were addressed adequately. Again, the religious guilt was kicking in.

Velocity Was High, Morale Wasn't

At about the fifteenth iteration, we began to notice that although everyone was making sure that they contributed to the velocity, there was a certain sense of dissatisfaction with our success. We are all aware that every day new tools, new APIs, and new products are likely to have an impact on our business, and we all want to stay ahead of the curve. It's good for developing an individual's skills to be able to practice new techniques, and good for morale to sort out aspects of the development environment that are annoying. Some of us tried to work on this stuff after working hours; however, a full day of guilt-free paired programming is extremely tiring. An XP practice is the 40-hour week, and we were devoting this to task completion, leaving no room for individual achievements.

Remembering the Old Days

When you pair-program with people every day, you often reminisce about how it was in the "good old days." Some of us tried working alone on pet projects after hours and reported back to the others that it was a useful reminder that paired programming is actually a more efficient way of working you just need a reminder from time to time. Sometimes, however, it is nice to work alone for a short duration and have the time to cover new material, unhindered by a partner's questions. Furthermore, some days people just feel unsociable and want to work by themselves for a change.

Everything Goes Gold?

To address these issues, we introduced a new practice that we call "Gold Cards." Because we are used to planning and working using index cards, we decided that a special kind of card would be a suitable way to integrate a new approach to innovation and sustainability.