XP does not insist on pre-prepared and detailed specifications. It uses lessons learned from the concepts of Just-In-Time manufacturing and KanBan to plan programming tasks in small increments. The customer gives the developers "requirements" in the form of user stories written on index cards. The cards are spread out on a large table and the developers give them weights based on perceived effort each would take. The cards to be completed in the iteration are selected based on their importance. Iterations are typically a week or two in length, but can be as short as an hour in certain situations.
The second step in the planning game could be very useful to Open Source software. This is the selection of stories to work on for the iteration and the selection of pairs to work on individual stories. Most Open Source software development teams tend to be distributed. Distance increases the difficulty of keeping everyone on the same page. It would be nice to have a way for everyone to keep track of what everyone on the team is currently doing, and it would be great if everyone could, at any time, obtain information about where and how they could contribute to the effort. XP solves the problem. After the stories for the iteration have been selected, they are pinned to a board, where everyone can see them. When a pair wishes to work on a card, they take the card off the board or leave their names on it. When they are done, they tear up the card in everyone's presence. Everyone on the team now knows how many tasks are remaining in the iteration and who is or has been working on them, all the time.
Planning games work very well when all the stakeholders can be in the same room. When the team is distributed, things are not so easy. A distributed team can't use index cards because physical cards can only be in one place at one time, so people began experimenting with the concept of distributed planning games with electronic index cards.
Probably the first attempt at using all the practices of XP in a distributed team was made by the Sangam project in the year 2004. A team of students and consultants from across the United States programmed a pair programming plugin for Eclipse called Sangam using XP practices and some additional practices like retrospectives. The fact that the team members hadn't all met one another would have proved an insurmountable obstacle to the use of eXtreme Programming except for their use of very resourceful methods to conduct weekly planning games and pair programming sessions.
There were two important categories of synchronous tools that could support distributed pair programming. One category consisted of screen-sharing programs like VNC. The other category consisted of domain-specific software that operated at a higher level of abstraction, that is, any IDE that supported collaboration, such as Eclipse with the Sangam plugin.
The advantages of the latter class of tools are that they do not need high-bandwidth connections, are capable of linking collaborators in asymmetric relationships, are capable of confining collaboration to specific tools and parts of the screen, and can be equipped with domain-specific interaction-enhancing signals and protocols. Thus, they have a far better chance of smoothing the bumps on the road to remote collaboration nirvana.
The Sangam project held weekly planning games using VNC and a free sticky notes program. In the top right corner of the computer screen, they maintained a bucket of stories that customers had contributed. If a customer came up with the story "Synchronize typing", they would add a note in the Stories Pool region.
At the beginning of each weekly iteration, they would pick stories to work on during the week, sizing the stories in the process and filling up the week's quota with only as many work-points as they had been able to complete the previous week. The selected stories were moved to the bottom left corner of the screen, which they demarcated for their iteration bucket. For instance, if the velocity of iteration 2 was 7 story points, they would pick no more than 7 story points worth of cards for the 3rd iteration. In eXtreme Programming, 7 would be called the velocity of the project.
There are usually little features that would be nice to have and which the developers may want to keep around in case they have time to work on them during the iteration. These were posted in the lower right corner. These extra cards are usually called "slack cards".
The top right corner was reserved for retrospectives. At the end of each week of work, the team would go over what went well and what didn't, after agreeing that everyone did the best they could have under the circumstances. Once cards were completed, they were discarded. Snapshots of the screen were mailed to all stakeholders on a weekly basis.
VNC and sticky notes on a desktop worked great except for the following problems:
Even so, the successful use of online index cards on the Sangam project showed how online planning games could be conducted successfully.
AgilePlace was intended to be an online tool that allows eXtreme Programmers to conduct a planning game just as the programmers on the Sangam project did, and to have the same layout and feel as sticky notes on a computer screen.
Over time, the goals of AgilePlace became more ambitious. It grew to encompass pair programming support thought IDE integration and the support of teaming activities like core protocols and retrospectives to give a collaborating team the impression that they were sitting within earshot and arm's reach of one another.
The AgilePlace website simulates shared tabletops with index cards on them. Electronic index cards can be dropped onto the tabletops and moved around just like real paper index cards. The tabletops are implemented as applets and can run within a browser. No special software needs to be installed.
When a user performs an action of interest to the other collaborators, as when he cuts or pastes an index card, the action is communicated to all the others in realtime. Any number of stakeholders may join a planning session, and can work with the index cards independently and collaboratively.
Weights can be assigned to cards, and the velocity of the iteration is computed automatically. This value is very useful in deciding which cards are included and which are left out of the iteration.
Anyone can get a user account on AgilePlace. Once a user account has been registered, multiple projects can be created under it, one for each software project that the user owns. The owner of the project can give other users access to it. When users log in, they see the latest project they had been working on, and can switch to another by selecting it from a drop-down list. Teams can customize their tabletops by changing the number of rows and columns in them.
The tabletops in AgilePlace are themselves very interesting because very few project management tools use them as a means of organizing requirements. At the top of each project in AgilePlace is a large tabletop that holds all the user stories that have been conceived. At the beginning of each iteration, a new tabletop is created for the iteration. Cards are then transferred from the story pool to the iteration tabletop and worked on by the team. Stories from old iterations are preserved on their respective table tops, forming the history of the project.
Each card corresponds to a task in the iteration. Cards generally have an optional nuts value to indicate the size of the task.
It is possible to make a chat client appear anywhere on the index card tabletop. This serves as a flexible means of communication that can be positioned in the field of view. They are usually used when performing teaming activities involving the Core Protocols, like the Decider or the Group Check In.
The server is written using PHP and needs MySQL. There are servers supporting MySQL 3.x and 4.x. Plans are in place to build servers in Python and Perl.
RoleModel Software donated their time to help us find the pain points in AgilePlace in its early days. Some of the problems they found were real breakers and had to be fixed to make the online planning games viable in a typical XP project environment. There was no way one could fit a hundred cards comfortably in the 800x500 pixel tables that we had. There was no way to move index cards around in groups. We only allowed users to drag/copy/paste single cards, and as a result, even the simplest operations required many clicks. We also lacked simple utilities like one for tallying work units, and there was no way to export stories.
When conducting planning games with team members in India, we observed the following problems:
We created a user list on which all the visitors to the page would be listed. We began to use a figure with the text "I'm looking here" to indicate the point of focus. Everyone would then know where the current speaker's focus was. We also moved the chat client out of its position at the bottom of the page and made it embeddable inside the tabletops. We plan to add multi-modal immersive commentary (in a generated voice) to tell everyone about each other's activities, something that should feel like listening to cricket commentary in the background. It should not affect the task you are performing, but give enough information to alert you to potential problems. We also hope to version cards so that if a collision were to occur, there would be no loss of information, and a merge action could be initiated.
Other users from XP User Groups around the world provided us with further suggestions. When we asked people for their comments on the tools, one of the problems they noticed almost immediately was the inability to see all the cards at once. The ability to resize boards allowed us to fit hundreds of cards, but it did not help the user see all these cards at once. We found that this was a major irritant to many people.
We thought about it, and realized that the feedback from the earlier customer trials also reinforced the need for a synoptic view. They had wanted to be able to put more cards on the table, and felt ours did not allow it. The system was quite unusable to them, even though we had scrollbars that allowed them to scroll around the space where the cards were. We had made it possible to have larger boards, but the board went out of the browser, and the browser window had to be scrolled to see all parts of the table. One of the users then suggested that we add support for zooming in and out. That made a big difference when there were more than ten cards on the table.
At about this time, we began to get feedback from folks who felt that the UI flickered too much and that the cards did not respond very well to moving, resizing, etc. Since the cards were made not to drag or resize until the mouse was released in order to keep the flicker low, moving cards to a precise target location became difficult. We solved both problems by using double buffering.
We hope to integrate the pair programming tools that the Sangam project produced with AgilePlace, in order to enable both distributed pair programming and distributed planning games through the same Web site. This will mean adding support for pair selection among a group of programmers. We also hope to integrate calendaring and scheduling tools. Once this is done, a programmer should be able to log onto agile place, select a task to work on, find a time when someone else comes online, link his/her IDE with the other programmer's, and pair-program with the latter on the chosen task.