Wojtek Biela is documenting his progress as he helps implementing agile practices in a project that is in pretty bad shape. Will be really interesting to follow.

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.

I saw an interesting news report on Swedish TV tonight. Kids in the first grade learn to read by pairing up and writing stories for each other using a computer. It seems that writing is easier to learn than reading. Handwriting, however, is too hard for children to start with, and by using a computer they don’t need to focus on the complicated act of forming letters. That can come later.

I see similarities between this and the agile approaches to software development:

• The creative ordering of what to learn first can be compared to how user stories can be switched around as they are considered independent of each other.
• Starting with the simplest thing first. At first one thinks that one has to be able to read before one can write, but as writing according to this theory is simpler for the children; move that first. This can be compared to the idea about “doing the simplest thing that can possibly work” in XP. In some of the more traditional approaches you almost automatically design bottom up, e.g. starting to design database schemas and protocols because that stuff “just has to be in place first.”
• The children wrote in pairs, seated at one computer, one child writing a story to the other. That’s pair programming for you.
• The children had a lot more fun producing stories, complete with illustrations, than they would have had if they had used the more traditional approach.

A writeup of the news report (in swedish) can be found here.
After some googling, I found out that the method was developed by Arne Trageton.