The web project project I’m working on is delivering but not without some hiccups along the way, probably all caused by me. These hiccups caused friction in the team, some stress and some late nights and weekends for me, all of which we could have done without. I’m not going to describe these hiccups in detail but what I am going to do is detail how I will approach the next project to ensure things go smoothly, incorporating things I do now, things I will do differently and things I will try to improve in the current process. I hope you find this process or parts of it useful for your projects.
A key to working with agility and responding to change is to ensure a small feedback loop. Getting something in front of the customer that they can play with and comment on in the shortest amount of time ensures that we spend the maximum amount of time delivering what they really want. Until the customer can use new feature X then the need for and the current shape of feature X is speculative. Speculation leads to waste, waste leads to less time for the other things and we start to spiral down from there, into a bog of stress and unhappiness.
Our feedback loop is an iteration of two weeks (10 days) where we work on stories and deliver them to the customer before the end of the iteration. Other teams I work with have an iteration of one week. Being able to discuss a feature in a time frame where the customer can keep all the details in mind and see it delivered with those details still fresh would be ideal, so I will try one week iterations in future. Taking a user story from a card to working software that the customer can actually use in an iteration means that we need to make sure we don’t bite off more than we can chew and this is where incremental development comes into play.
The quickest way to do anything is not to have to do it but since we want to please the customer and they are unlikely to pay us for not doing stuff, we need to work out what to do. To do this I borrow from the Story Board approach, developed by the Walt Disney studio in the 1930’s. The idea is to draw scenes on separate sheets of paper and pin them up on a bulletin board to tell a story in sequence. Our scenes are the actions, processes and UI the user will follow and use in our application to fulfil a customer story. A story being a function that yields business value to the customer. I will take each story and with the customer we will discuss the story and create a story board. Since most everyone can draw on a whiteboard quicker than they can code this is the quickest way to get an understanding of what is required in a story and how that story will manifest itself in the application.
A story board is an efficient way to visualize a story but it doesn’t help us quantify small chunks we can deliver in an iteration. To do this we need to identify the smallest and simplest thing we can deliver that can be used by the customer and that we can add to in a subsequent iteration. By incrementally adding functionality to a story each iteration we focus our efforts on delivering without waste and a high level of focus. Anything that isn’t used immediately by the customer or is not mandatory to perform a function is a waste of effort in this iteration. To arrive at the smallest but usable deliverable for the iteration we need to continuously remove things until the customer says they can’t
perform their function without it or the application can’t function. For example, consider the parts of an application that maintain a list of contacts and what properties a contact must have to be usable. If the various properties of a contact are not currently used by another part of the application then they should not exist until they are. Laying out these properties on the UI for input takes time, time that
should be used elsewhere in this iteration. You might be thinking this is YAGNI on a micro scale and you’re right.
With the story board in hand, the minimal set of features and data we are ready to do our story. You may want to have a new story for each increment or you may want to have one story as an umbrella for all increments to the same story. I think we will go with the later option of an umbrella story. We will be continuing with a Test Driven Design and we will use a Behaviour Driven Design tool (jBehave, rspec, gspec) since this helps keep the language and behaviour tight around that used for the domain.
The loop isn’t complete until the code can be Continuously Integrated and I can’t stress enough how important CI is. Every time I have chosen to set up and use CI later in the project I have regretted the decision. I’m not keen to make this mistake again and CI is going to be in use from the word go. Our loop will include the CI of code every thirty minutes with an overnight deployment to the Test environment and an iteration end deployment to the customer preview environment. Essentially we are trying to get a story in-front of the customer on a weekly basis and keep that a regular occurrence. Continuous Integration isn’t the final piece in our loop as the loop must include customer feedback and our review of the iteration. This feedback piece is very important and will be included as a regular iteration start and end exercise on the chosen day. I haven’t discussed a release cycle since this is very project and customer specific.
A final important piece is to review the above after each project and adjust it accordingly. The process may need some adjustment during the project but I think that unless it is causing some friction then the process should be used for a few release cycles before being adjusted to give enough time for an adequate sample to be taken and a worth while alternative found to try next.