Evant, this Application Service Provider (ASP) formerly known as Retail Aspect, embraced XP and is now reaping the fruits of that decision.

Industrial Logic’s Joshua Kerievsky has participated on this project and photographed it for your viewing pleasure.

The Evant XP engineering team, led by CTO Vraj Mohan and coached by Rob Mee, is featured in the visual tour below.

Environment

XP environments are optimized for productivity. At Evant, programmers and product managers sit in one large room.

Programmers pair-up on computers in the center of the room and integrate code at a nearby computer, while product managers sit at desks that circle the room.

This enables programmers to ask questions of product managers in person.

Questions are often answered within seconds, allowing a pair to quickly continue productive programming.

And because programmers sit so closely together, it is easy to ask questions, or help others when you hear them getting stuck or confused.

XP wants to err on the side of too much public space. XP is a communal software development discipline. The team members need to be able to see each other, to hear shouted one-off questions, to “accidentally” hear conversations to which they have vital contributions.
— Kent Beck, Extreme Programming Explained, page 79.

This mini-dialogue occurred when a programmer had a question in her mind about how to program an algorithm.

She looked around and saw the very two people who could answer her question. In moments, these two people were by her side, reviewing the steps of the algorithm.

The difference between a good space for a team and a bad space for the team is immediate and dramatic.
— Kent Beck, Extreme Programming Explained, page 78.

Every three weeks, the team revisits the “Worked Well / Needs Improvement” wall-poster.

This poster is intentionally large - you can see it across the room, which helps especially with entries in the “Needs Improvement” column.

On this project, one entry in the “Needs Improvement” column related to poor communication between XP programmers and data warehouse people (who work on adjacent floors).

Over an iteration or two, the XP team improved their communication with the data warehouse team, and the entry was transferred from “Needs Improvement” to the “Worked Well” column.

Iteration Planning

Every three weeks at Evant, programmers and product managers conduct an Iteration Planning Meeting.

Product managers take turns describing the stories which they’d like to see implemented in the next 3-week iteration. A programmer stands at the board recording these stories.

While describing a story, a product manager may field questions from programmers, other product managers, or business managers. Over an hour or so, the board fills up with stories.

Next, programmers will have a chance to study these stories, begin to think about which ones they’d like to implement, and begin to estimate how long each story will take in Ideal Programming Days (IPDs).

Some programmers and the XP Coach (seated) surround the board to study the stories. Mini-dialogues happen at the board.

Some programmers go off to ask product managers more detailed questions. Gradually the whole programming team approaches the board.

The next task is for the team to make their time estimate in Ideal Programming Days (IPDs).

Programmer, Kevin Rugg, considers an estimate. Each programmer will have a chance to place their initials beside a story, along with the number of IPDs they think it will take to complete the story.

Programmer, Karen Bradshaw, initials a story and records an IPD estimate.

Once all of the stories contain estimates, the Business team can count up the total number of estimated IPDs, and compare it with the Programming team’s velocity (the amount of IPDs that the Programming team can implement over a 3-week iteration).

If the total number of IPDs listed beside the stories is 25, but the team goes at a speed of 20 IPDs per iteration, 5 items must be deferred to a later iteration, or redefined for the current iteration.

Some members from the Business team (product managers and executives) confer with the XP Coach about which stories they will need to scratch from the list.

Sometimes items don’t have to be deferred - but usually they do, as the Business team usually wants more per iteration than the Programming team is capable of implementing.

During this phase of the game, some stories may have their scope reduced in order to make room for stories that would have been deferred.

Ultimately, the Business team decides on the final stories that will make it into the 3-week Iteration, based on the Programming team’s velocity.

The game is now over, and the iteration is ready to begin.

All of the stories will be recorded on large posters for the Business and Programming teams to see and update during the iteration.

Pair Programming

Pair programming is a dialogue between two people trying to simultaneously program (and analyze and design and test) and understand together how to program better. It is a conversation at many levels, assisted by and focused on a computer.
— Kent Beck, Extreme Programming Explained.

As XP Coach (and an experienced programmer), Rob Mee often signs up for programming tasks during the Planning Game.

Iteration Posters

During Iteration Planning, stories are described and programmers estimate those stories and sign up for them.

After an Iteration Planning meeting, stories and estimates are transferred to posters, which are then taped to the walls.

The photo above shows what the posters look like at the end of an iteration. Note that all but one story is marked with an “X”.

Who actually marks each story with an “X”? Well, programmers aren’t allowed to do that. Only product managers can do this, and they do so when they are satisfied that a story has been fully implemented.

It is nice to see a product manager “X” a story that you have been programming.

A closer look at one of the posters. Notice the initials of programmers on the team and numbers that represent Ideal Programming Days.

Programmers who have their initials beside a story are responsible for implementing that story.

They will do so with another programmer, who may have his or her initials beside other stories as well.