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.


Office environment with workstations distributed in U-shape

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.

3 team members having a conversation

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.

A poster with two columns full of text, worked well and needs improvement

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

team sits in a circle planning, woman at white board writes notes down

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).

team around white board estimating

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).

kevin in front of the board estimating a story

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.

karen and steve on the white board estimating

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.

business team and coach discuss which stories to cut from the 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.

3 people from the business team in front of the white board

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

Kent Beck and Eric Evans 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.

Benny Sadeh programs with Rob Mee

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

Edward Hieatt pair programs with Karen Bradshaw

Iteration Posters

3 posters on the wall

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.

close up of one week's poster with stories

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.