We are now ready to begin writing our first lines of actual production code. To assist us we have our acceptance tests that we need to pass, and the CRC-cards from last time. More importantly perhaps, we have access to those who can tell us what the acceptance tests really mean if we get confused, and we have access to the rest of the team that can help us recall and refine what came out of the CRC-session.

We start by looking at the acceptance test. The first thing that it does is to establish a connection between two subscribers. This looks like a good place to start.

Remembering the quick design session, we begin with the Subscriber class. Our first test ends up looking something like this:

class TestSubscriber < Test::Unit::TestCase
  include FlexMock::TestCase

  def setup
    #...
  end

  def test_start_waiting_for_calls
    factory = flexmock('CallReceiverFactory')
    receiver = flexmock('CallReceiver')
    factory.should_receive(:create_receiver).with(@address, @port).and_return(receiver).once
    receiver.should_receive(:start).with(@subscriber).once

    @subscriber.start_receiving_calls(factory)
  end
end

This test maps roughly to the first steps in the scenario we discussed last time. The Subscriber class is expected to create a CallReceiver and tell it to start listening to calls.

The code above is not by far the first version of this test. We started by just testing that we could tell the Subscriber to start receiving calls. Then we wanted to test that a CallReceiver would be created. That led us to add a CallReceiverFactory, which enabled us to control how CallReceivers are created from outside the Subscriber class. We needed this to be able to make sure that we are able to have the Subscriber class interact with our mocks in a test environment.

We then moved on to test that the CallReceiver was told to start receiving calls by the Subscriber. We actually missed that the CallReceiver will need to know who to notify when a call is received. That we didn’t discover until we started on the CallReceiver class later. We then had to go back and update this test and the corresponding production code.

We also had some notes from the CRC-session that told us that we need some information about IP-addresses and ports. That information eventually ended up in this test as well. We pass that information to the CallReceiver by way of the CallReceiverFactory so that we know from where the CallReceiver should be listening to calls.

We continue with the rest of the classes, focusing on implementing what is needed to get a connection established. If we notice new things that would make sense to add to the code, but isn’t really related to getting a connection up and running, we make a note of that and move on.

When we take a crack at the code for the acceptance tests, we notice that we need to pass an address and a port to the Subscriber’s constructor in order for it to know where it should listen for incoming calls. This forces us to add that data to the acceptance test as well. We do discuss this with the customer first of course.

Acceptance Tests

The acceptance test for the current version creates two Subscriber objects that listen at two different ports on localhost. This feels like a good compromise. We don’t test the application in its entirety right now, but we do use real communication and we have an easy way of asserting that both clients behave properly. This may be revised later though.

The acceptance tests were revised a bit when we started developing. Some information was added that we discovered was needed by the code in order for it to know what to do, and some information was deemed unnecessary. The current version looks like this:

What the Application Does So Far

• A Subscriber can listen for incoming calls.
• A Subscriber can make a call to a predetermined address.
• Subscribers can exchange information about the identity of the calling parties.

We have strived to keep this as simple as possible. For instance, for now all we do is exchange user information by each subscriber sending their name as a string over a TCP socket. This is all we need at the moment. No XML, SOAP, ASN.1, or other is needed yet. We are focusing on getting a connection up and running. We do know that we will (most probably) revise this later so we do our best to not have any duplication in the code. If we want to change from TCP sockets to another scheme, we shouldn’t need to do many changes. If we want to change to a more elaborate identification scheme, we should be able to get away with doing those changes at one place.

Notes

The tests so far make heavy use of mocks. Nearly everything is about testing that class A calls method M on class B with this and that argument. This may be due to the nature of this application – we’re just passing text between two endpoints, but I’m beginning to feel that there must be a different way.

I like the way mocks help me develop from the top down. If a class that I’m working on needs the help of another class, I don’t have to stop and begin implementing that class before continuing with the first. I just create the interface I need, create a mock from that, and continue with the first class. When I later move on to the “discovered” class, I already have a pretty good defined interface to implement.

The fact that this is done in Ruby seems to get me into trouble from time to time. There is no interface where I can put all of my assumptions when I mock a class that I haven’t developed yet. This means that I have to keep notes about what classes needs what methods with what arguments. When I start to implement a class that has only been mocked earlier I quite often notice that I need to make small changes to the interface that I drafted while mocking. With the interface construct, any such changes would be explicit. Tests relying on that interface would automatically start complain if I messed up there assumptions. In Ruby, I don’t get that help from the language and at times things got a little messy.

Using quick design sessions rather than working on design documents requires that there is a short time between the session and implementation. As it has been a while since I last worked on this, just looking at the CRC-cards wasn’t really enough to start implementing. Luckily, I could read the last blog entry and got a pretty good idea of what I was up to last time.

The team has identified the tasks for the first iteration and are about ready to go to work on it. Before we continue, we pause to have a quick design session where the major classes of the application are identified. The design session is done collaboratively with several, if not all, team members present.

For this session we elect to use CRC-cards (Class, Responsibility, and Collaboration). We walk through the scenario that we are about to implement and try to find the major classes involved. Where possible we try to use terminology from the system metaphor that we decided to use for describing the system. We write the name of those classes along with their responsibilities. Finally, we walk through one or two scenarios and try to see how the classes interact and write down the collaborators of the classes on the cards as well.

Looking at the acceptance test for the current story, we end up with the following set of cards:

The team sits around a table with the cards created so far spread out, each time a class is mentioned someone lifts up that card and holds it for everyone to see. If a new class is needed, a new card is created. If a class is no longer needed its card is ripped up and thrown away.

For the scenario of connecting two applications the discussion can go something like this:

• The calling application is started and an instance of Subscriber is created (The subscriber card is lifted up by one of the participants).
• The Subscriber creates an instance of CallReceiver and tells it to start listening for calls (both cards are held up).
• Here someone notices that we need to store information about how to reach a subscriber somewhere. Probably the IP-address and port where this application receives connections. We make a note of this, but we don’t feel we need to decide exactly what class holds that data at this point.
• The called application is started and the same scenario as above is repeated
• The Subscriber in the calling application makes a call to the called application by creating a Conversation class (cards in the air).
• Someone points out that we need the know how to reach the called application as well. This information needs to be stored somewhere. We make a note of that and move on.
• The CallReceiver in the called application detects the incoming request and creates a Conversation class that will match the one on the calling side. The Conversation is passed along to the Subscriber class, which in turn notifies the Console class about the new conversation.
• The Subscriber class in the calling application notifies its Console about the new Conversation
• In both applications the Console class displays a message that indicates that we have a conversation started.

After the team has been through this a few more times, should have enough information to start implementing the design. At any time the design can be revisited if deemed necessary.

Highlights

• Design is a collaborative effort. Everybody on the team is involved in the discussions and walk away with a pretty good understanding of the design.
• This lessens the need for some of the intra-team documentation needed. If every developer designs her part of the application in isolation, there probably will be a greater need for documentation and formal reviews in order to get input and spread knowledge. The argument for dividing the design up usually is that of efficiency. You can cover more ground if you work in parallel. I believe that the raise in cost of communication that follows will hurt you in the end though.
• The level of the design artifact is at a level that all of the team members can understand and comment on. Developers, customers, technical editors, and QA people, etc.
• Using cards, ripping them up, moving them around, and pointing to them during discussions is a more tactile approach than working in a UML-drawing tool or even drawing on a whiteboard. I’d think this is a positive thing for the overall understanding in the team. In design sessions where the whiteboard is used directly without cards, there is not room for more than one or two people up at the board at the time. This can lead to one or two of the stronger wills in the room to high jacking the meeting, not leaving enough room for everyone to air their opinions.
• This does not replace the use of UML diagrams or other forms of formal documentation and reviewing, if those are necessary.
• The session aims to create a design that is suitable for the stories at hand. We will refine that design as new stories are planned. If we don’t have enough buy in from the organization that this is possible. These kind of exercises will most probably fail.

Let’s start implementing…

After some time off I return to our XP simulation where I attempt to implement a little messaging application. For the iteration ahead there is only one story planned: “A user can send a text message to another user - the console version.” The story is estimated at 5 points. We have a good idea of what this story entails as we have an acceptance test that describes the details.

We begin by planning the iteration by breaking down the story that is up on the white board into tasks for the developers. We estimate those tasks as best we can. When estimating the tasks we don’t use an abstract notion like story points; a simple time estimate will do. None of the tasks should take a lot of time to do, it should be a matter of hours or, at maximum a day.

When we created the user stories we did our best to ignore dependencies. When we plan the tasks for the iteration, we allow ourselves to acknowledge that there is an order to how certain things ought to be implemented. It does make sense to make two applications connect to each other before we attack sending messages between them.

This is the first iteration so we don’t have a good idea of how much we can accomplish in one iteration. My gut feeling tells me that we probably could squeeze more into one iteration, but let’s wait with that until we have marked some tasks as “done” and have a better grip on our velocity. History has proven me to sometimes be too optimistic.

Here’s the project white board after we’ve done the iteration plan:

The next thing to attack: connecting two applications.

After the first iteration I have learned quite a few things about Ruby basics and the support for what I need to get started developing the application. Looking at the project whiteboard we now see that the next thing to do is to tackle the first user story - “A user can send a text message to another user.”

That little piece of information is not enough to start implementing. We need to know a lot more about what the customer wants and how we are going to support that feature. The most common way of describing how a feature is to be implemented is probably by creating a use case.

A use case describes the flow of the system while it solves something for a user. When I first encountered user stories my immediate reaction was “what is the difference between a user story and a use case?” My take on it is that while a user story is a promissory note, a token that tells us that we are going to get to the details of a feature when it is about time for it in the plan, a use case is a way to actually document those details. In addition user stories are a tool for planning a project. They have a cost attached to them. They can be split and combined. Use cases don’t have these abilities.

We also need a way to verify that a feature works properly. For this we need to specify a test that needs to be passed in order for us to consider the feature implemented. More often than not (at least in my experience) there is great similarity between a test case and a use case. With the test case being a concrete example of the use case. Where the use case specifies an actor “first time customer”, the test case specifies a user “Alice”, whose “user profile does not contain any information about a previous visit to the system under test.”

The test can tell us when we have completed the implementation of a feature. That is information that we want feedback on as early as possible. Even so, my experience is that test cases are often specified after the feature is implemented, when it is time for the dreaded system test. Often the test case is created by someone who is isolated from the rest of the team. In some organizations there seem to be a perceived advantage to have an almost antagonistic relationship between testers and developers in particular. I am not sure that I understand why.

If we detail the user story as a test before we implement it, we might remove some of the waste that it means to document the same thing in both use case format and test case format. We also have an opportunity to get immediate feedback on whether we can consider the feature we are working on finished or not. Developing against a pre-specified test case will give feedback on whether the test case makes sense as well. All of this is feedback we want long before we deploy or go into system test.

Having the possibility to run the test cases automatically by just pressing a button, running a script, or just have them run every time someone checks in files to the version control system makes it really easy to make sure that a feature still works after additional changes have been made to the system. Fit and Fitnesse enables us to specify tests in a way that is readable to non-programmers while they at the same time can be executed automatically. We will use Fitnesse to create test cases in this project.

Discussing the Details

With that in mind, the customer, the developers, and quite possibly a tester sits down and tries to flesh out the details of how our application is to enable users to send messages to each other. We begin with the main scenario. No communication errors or timeouts yet. Let’s start simple. The result is a Fitnesse test that looks like this:

This describes how two clients are started. One client is started by the user Alice, and the other by the user Bob. The users exchange some messages and we expect the message history on both clients to contain the messages along with information about who sent them. The tables in the document are interpreted as test fixtures by Fitnesse.

This test should of course be supported by other tests that take care of other scenarios. We should for instance have tests that verify the behavior when errors occur. But let’s stick with this test in this example.

In order for the test to be able to run we need to create some code that takes care of calling the system under test on behalf of our fixture tables. We implement some stub classes and methods so that we can get our test to execute:

require 'go_fixture'
require 'fit/row_fixture'

class EstablishConnection < GoFixture
  def start_client_with_user(client, user)
    return false
  end
end

class StartupResults < Fit::RowFixture
  def query
    return Array.new
  end
end

class Conversation < GoFixture
  def user_sends_message_to(fromUser, message, toUser)
    return false
  end
end

class MessageHistory < Fit::RowFixture
  def query
    return Array.new
  end
end

Running the test gives the following result

Our assignment for this iteration is basically to get these tests to pass. Ideally, these tests should execute a complete system with no fake data or classes. At the moment I haven’t decided on how to approach this though. I can either start two instances of the application and have them communicate with each other, or I can instantiate and configure the internal classes for both client Alice and client Bob in the test code and have them communicate with each other via a fake communication channel. The former approach is the most realistic and tests the actual system, while the latter is easier to test. Right now I think I am going to start with the latter and then see if I can transform it to the former, all in the name of moving forward. Any input on this is highly appreciated.

Now it’s time to start planning the iteration in more detail…

 I spent the first iteration investigating basic Ruby and the tools available for creating automated tests. I am nowhere near feeling confident in all aspects of the language or on all the intrinsics of the tools but I hopefully I have enough to get the story planned for the next iteration going.

Ruby has a unit test functionality as part of its standard library, which is nice. It is a dynamically typed language so there should be a few new ways to create test doubles other than the ways its done in languages like Java or C#. There are a few mocking frameworks (Test::Unit::Mock and Flex Mock seems to be the candidates to choose from) available but I haven’t looked at those in any detail yet.

I was glad to see that RubyFIT is available for creating acceptance tests in FIT or Fitnesse. I haven’t been able to find FitLibrary and especially DoFixture implemented for Ruby. There seem to be some work going on with FitLibrary for Ruby though. If anyone has any info on this, please let me know. I will try to get on without it for now.

So now the second iteration starts. It is time to tackle the first user story!

Last time I did a rough estimation of all user stories supplied so far. In addition the iteration length was set to one week. This time I am going to plan the work for the near future. I may even come up with a rough estimate for the final release.

Ruby

To throw some risk and uncertainty into the mix, I have decided to implement the application in Ruby. I have never worked with Ruby before, and I will address this by adding time-boxed investigations to the plan where needed. Normally, I would probably spend a lot of time up front learning a new technology or language, trying to find all the really cool features of the language so I would be able to take advantage of them from the beginning, but this time I am going to add targeted investigations throughout the development plan. These investigations will be targeted at solving a specific problem or giving enough detail to implement a user story.

The rationale for doing it this way is to see how it works to take a big unknown, or risk, and instead of addressing it as much as possible upfront, address it when needed at different times during the project. It will force me to investigate just enough for the problem at hand, and make me implement features the simplest possible way I can. So be prepared to see a lot of Ruby code with rookie mistakes!

The First Iterations

At this stage I think it is time for the customer to make some decisions about in what order the user stories should be implemented. So, putting my customer hat on, I try to think about what I want to see from the application in its first incarnations. The most important aspect of this application will be the messaging interface; how the user interacts with the system while writing and receiving messages. So as the customer I determine that I want to see the user story “A user can send messages to another user” implemented first. I want to see the GUI for exchanging messages with another user up and running so I can give some feedback on that as soon as possible.

As the developer, I suggest that we add some investigations into Ruby in the first iteration, and that it may be too much to both get the hang of basic language features and GUI support at once. I suggest that we compromise and implement the story with a simple console front end at first, and then tackle the GUI.
As the customer, I am not overly excited about not getting the first crack at the GUI at once, but I trust the developers when they say that the cost for adding a richer GUI to the mix now is too high. But I do want that GUI sooner rather than later though.

So the team decides that the first version of the application will be console based. As we won’t be implementing any central operator service with support for looking up other users in the system, the installed client will be configured to connect directly to another client. Using the metaphor, the team calls this version for the “Direct Line” version. You just lift up the receiver and have another subscriber on the line.

So it is decided that the first iteration will be spent investigating the basics of Ruby and what the options are for implementing simple network connectivity. During that iteration I’ll also look into unit testing support and acceptance testing support.

The second iteration will be spent implementing the “A user can send messages to another user” story. Looking at the estimate for that story we see that it has 5 points. This is relative to the other stories. As all of the stories involve GUI one way or the other, that relative estimate still holds. But we will need to add a user story which adds GUI. As we don’t have enough knowledge about GUI in Ruby, we cannot estimate the new story properly at the moment. We need to add an investigation to get enough info to estimate it properly. We plan to do that investigation in the iteration that follows the implementation of the “Direct Line” console version. In the meantime we give that story an estimate of 3, and expect that estimate to be revised after the investigation.

So the first iterations are planned as follows:

1.Initial Investigations
2.Direct Line – Console Version
3.Ruby GUI Investigations
4.Direct Line – GUI Version

The rest of the stories are deferred to later iterations. I think one could do a more high level release plan that spans further into the future. A plan of that sort would contain a few intermediate releases prior to the final release. I could have done that in this project as well, but for now I’ll just consider this a one release project.

First Shot at a Release Date

The team estimates its velocity to about 5 points per iteration. This project has to share its resources (me) with my family, the swedish summer, some house renovations, and the world cup. So we’re far from the 40-hour work week. The total number of points at the moment are about 45. That would suggest that we need about 9 iterations to complete all stories. This is a rather naive way of doing estimation. We’ve already used up two iterations for investigations, for instance, and there will be more. A really rough, gut feeling, estimate lands at between 10 to 15 iterations.

I expect this estimate to be constantly refined, and I will be in a much better position to estimate after a few iterations. I have deliberately not spent too much time on the overall estimation at this point. Perhaps I should have done it in more detail, but I want to see if, and how, the estimates are self regulated.

The Plan So Far

When I started out I intended to use XPlanner to keep track of my progress. Although I think this may be a great tool, especially for multi-site teams, it doesn’t seem to give me any added value in this particular project. Instead I have switched to plain old pens, notepads, and post-it notes.

This is the project “white board” as it looks at the moment:

At the top are the stories that are in the current iteration. At the bottom to the right are the stories that are scheduled for the next iteration. At the bottom in the middle are the stories in the iteration after that. At the bottom to the left are all stories that are scheduled for later iterations. Pink post-its are investigations. Yellow post-its are user stories.

Time to start looking at Ruby…

As an excursion in XP I am currently implementing a simple instant messaging application so that I can try out the mechanics of it’s practices. As I am alone on this I will not be able to take full advantage of some of the practices (it will be hard to pair-programming for one). The system metaphor is one of the practices that I really don’t see how it will affect development for me personally, for a team I can definitely see the uses. Nonetheless I will attempt to come up with a metaphor to see if it does me any good.

A system metaphor is an analogy that describes the system in a way that it can be discussed by all parties that have an interest in the system to be developed. This is by far the concept in XP that I have most trouble grasping, and from browsing through mailing lists and talking to people, I know I am not the only one. From what I understand the metaphor is not as explicit in the second edition of Beck’s book as it was in the first, but I’m going to try it out anyway.

The first thing that comes to mind is that of a telephone network. Especially the old school types, where you just lifted the receiver and got connected to an human operator. You’d then ask the operator to connect you to whomever you wanted to talk to.

So the act of sending a message to another user may be described as follows:

“A subscriber contacts an operator and asks to be connected to another subscriber. The operator connects the call between the subscribers, who then continues their conversation directly; without involving the operator.”

After getting some feedback on this from the extreme programming group I hesitated whether I should use this metaphor at all. Does this really add anything that thinking about “a client connects to a server and…” I mean, I think of this project as a simulation of an XP project, but I am still the only project member. I don’t think I can simulate the informal communication going on in an agile team at all. So, do I need a metaphor to describe something to myself in other words than clients, servers, and user databases?

I’m going to stick with the metaphor some more and see. One thing I can see already is that the system metaphor makes the application design come to life. When I think of it in terms of clients and servers, the image that pops into my head is that of a UML-like diagram. Something like a sketch on a white board. With the metaphor I get images of people doing things like making calls, working as an operator and connecting phone calls. It’s a more vivid image.

I’ll try to be aware of when this metaphor helps me, or hinders me.

Last time the customer brought the first approach user stories to the rest of the team. By just looking at them, a few things about the design could be inferred, but the team has not created any architecture or design for the application yet. That doesn’t mean that it is not there. It’s simply not yet documented anywhere yet.

It is now time for the developers to begin estimating the user stories that are presented so far. There are several ways to do estimation. For this project we elect to assign points to each story. The number of points assigned to a user story is an indication of it’s size. A user story with 2 points is estimated to be twice as large as a user story with 1 point assigned to it.

Using the abstract notion of points has a few advantages over simply estimating the time it will to take implement a feature:

• How long something will take is dependent on who is doing it. A team’s ability to perform may change several times during the life of a project. Members come and go. Assignments outside of the project is competing for it’s resources. The size of the stories is supposedly not as susceptible to change however.
• It’s easier to estimate the relative size of one thing compared to another than to estimates its absolute size.
• Estimates, especially at the beginning of a project are just that - estimates. However, over time estimates have a way of being transformed into promises. By using the more abstract notion of points, it can be easier to distinguish between estimates of tasks and estimates of release dates.

Points have some disadvantages as well, the main one being that it is often a hard concept to describe to someone not used to them. “Traditional” estimation includes time rather directly, which is kind of intuitive. With points we only estimate the size of things and expect another concept, velocity, to help us get a time estimate. This may take some getting used to.

For a great exploration into the details of planning agile projects, read Agile Estimating and Planning by Mike Cohn.

Iteration Length

The team should be able to implement each user story within an iteration. This will ensure that the system contains a set of completed features that are of value to the customer at the end of each iteration. To be able to estimate the user stories that fit in an iteration, we need to determine our iteration length. For this project we choose an iteration length of one week. I’m doing this on my spare time, so I don’t expect my velocity to be very high. In a real world scenario the selection of an iteration length should be given more careful thought.

The Stories

Let’s review the user stories so far:

1. A user can send text messages to another user
2. A user can block another user
3. A user can create a chat room and invite other users
4. A user can use a display picture
5. A user can send a file to another user
6. A user can store conversations in a local file
7. An administrator can ban a user
8. An administrator can broadcast messages to everyone

Starting with the first story, let’s consider roughly what that would entail. We need a simple GUI where a user can enter text. We need to be able to discover other users in order to select to whom a message should be sent. We need to log on to a server. We need to be able to store information about users on a server. We need a protocol for discovery and message sending. Etc.

This story seems too big to fit inside an iteration, so we need to split it into smaller stories that can fit inside an iteration. Let’s imagine the team sat down and did just that. This is the result:

• A user can log on to the messaging server
• An administrator can add a user to the server
• A user can list the other users on a server
• A user can send a text message to another user

Now these seem a bit more manageable than the original story. Going through the rest of the stories, we estimate that they all have a decent size. In a real world scenario, we would probably find a couple of more stories that we have problems estimating. In addition to being difficult to estimate due to hiding too much functionality, as with the story earlier, stories may also be difficult to estimate because we don’t know enough about how to solve them. We might, for instance, not know enough about a certain technology. In these cases we might schedule a spike, a time-boxed investigation aimed to give us enough answers to give a good enough estimate.

After going through our stories so far, we end up with the following estimates:

Remember that these estimates only says that we think that story X is approximately twice as large as story Y, and that we believe roughly that we will fit at least one story in each iteration. The story with size 8 might prove to be too large. Or any of the stories for that matter. We may have to revise this later.

With this we should have enough information to start planning our iterations.

As an exercise in the mechanics of an XP project I am creating an instant messaging application. I will attempt to pay attention to the different roles and act accordingly in the different stages of creating the application. My hope is that this can be compressed into a one or two day workshop on XP later on. We’ll see. This is not intended as a description of how to do XP, I am simply trying things out in public for all to see.

First of all we need to take a look at the requirements that we have on the application to develop. Playing the customer, the following user stories where created as a first approach. They are in no way complete, and would in a real world scenario need a lot of refinement. Although I have actually seen less complete requirements in real world applications.

At this point it is important to notice that the user stories are created with no (or as little as possible) regard to architecture or other technical aspects. This is roughly the functionality the customer wants. We have yet to flesh out the details of how things are supposed to work. We will come to that later. The list abouve could be compared to the result of having a requirement workshop (albeit the participants of this workshop don’t seem to be too creative).

The development team on this project does not expect to be handed the complete requirements, ready to develop, by the marketing people. Instead we expect the stories, their priorities, and the scope to be revised several times during the project’s lifetime.

The list above is a screenshot from XPlanner. Each story has an ID, a title, and a priority. I am already feeling myself being guided by a tool. I’m not sure I like that…

Hints of an Architecture

These first approach stories are presented to the developers, who in turn will need a lot of clarification before a plan may begin to form. The features described above do provide a few pointers at the direction the architecture needs to take. A lot of this is still somewhat speculative at this point, so we stay clear of details as far as possible.

• We have at least two user roles: user and administrator.
• We probably need to have a register with all the users of the system.
• We probably need a central server where clients can log on and connect to other users.

With this the team has something to start with. The developers can begin to estimate the stories as best they can at this point, asking for details where those are needed.

I have decided to experiment a bit with the planning aspects of Extreme Programming. I will do this as a one man project, at least initially, so I can explore at my own pace, the mechanics of the planning game and those of the practices that I can manage to use on my own.

I am going to develop an instant messaging application. This is a fairly simple concept, but it is a real world application that I believe will present some challenges.

I will keep the iteration length really short, perhaps one or two days. This way I won’t get bored, and perhaps it is possible to turn this into a one or two day workshop if I can manage to compress the process even more.

I do think that using low-tech tools like a whiteboard and index cards is the best way to get a dynamic working environment in a co-located team. In this case though, I am going to use a tool, XPlanner, to help me with the planning for the following reasons:

• I am doing this from home and I think I will get one or two complaints about the mess if my better half sees a room full of sticky notes.

• Having kids around makes the risk of losing user stories sky rocket.

• At the company I work for, we are located across the world. So, co-located teams are at times not an option.

• I imagine extracting data from a tool like this makes it easier to publish how things are progressing on this blog.

I have just installed XPlanner. I am currently wearing my customer hat and am creating the first user stories, trying to really forget that somewhere deep down I am a developer.

More to come.