Keep Agile When You Are Doing Agile

Posted on by Michael Orr

Tim (Cloudspace's agile director) and I spent most of last week in San Francisco kicking off a very cool new client project. It is a big, well thought out idea and there are a lot of different pieces and parts that have to work together in certain ways to enable the product's special sauce. Under a rigid agile structure we couldn't have possibly discussed all the nuances and subtlety to the idea before landing the job. It would have simply taken too much time and we would have been giving our work away for free.

There is a very interesting Agile idea called an Iteration Zero. An iteration zero can be used in many different ways. You can spend the time setting up the code and project management by getting ticket and milestone management, source control, build scripts, deployment scripts, testing frameworks, and integration processes into place. Or it can be used to identify, estimate, and prioritize features.

I think its really important to remember that it is called "agile" development because it is adaptable. We didn't exactly end up doing an Iteration Zero sprint week but did meet with Iteration Zero goals in mind. We did a few pair consulting days to flesh out our understanding of the system, create charts showing the flow of information, and talk through the technical aspects of many of the components in detail. We were able to take notes that will enable us to break the components down into small sized tickets. We also identified several small areas that we needed to do some research to fully understand their impact on the project. We even took one complete component and broke it down into tickets, all with estimated complexity ratings of two days or less.

Keeping the whole process "agile", we're going to do a few more pair days at the beginning of the upcoming week. We'll be breaking up more of the components into tickets to help our new client and ourselves to get a handle on where we think complexity lies within the system and build out a road map for getting to a basic beta.

The most basic goal of agile development is to provide the most business value possible at every step. By planning down to a level of granularity that we are already familiar with (two day or less tickets) and identifying risky areas of the development process for this specific system we are able to provide a good high level view of the time line for the first stage of development. Based on this information we can then shuffle the tickets and add or prune features to make sure that release one tasks include only the essential pieces to achieve our client's product dream. That is the most business value we could ever provide.

 
comments powered by Disqus