From zero to agile – iterations

I wrote in the past several posts around the agile software development and project management. Now I would like to dig deeper in it,  presenting which ones are the core agile principles and best practices, with examples from several models as scrum, Kanban or Lean.

The idea is to show how a hypothetical company could transition to an agile model from zero (either no process in place or a traditional / waterfall one).
The transition should be gradual (a big bang introduction of a new methodology is never a good idea), therefore introducing a new principle every week (the time frame can vary, it’s just an example).

The situation

You are a software house existing for several years and with some projects already executed and a couple of products on the market. Now you want to create a new product (or a new generation of an existing product) that will use a new technology (which you don’t know entirely) and the scope is also not completely defined (you have a network of partners which are supposed to use the product – a sort of platform, and everyone has slightly different business needs).

You have done a first analysis, you have an initial scope and a clear target (let’s say you used the methods described in the series PM).
You know that will take more or less one year for your development team and normally you’ve previously done your projects in a waterfall mode: first design and clarify all requirements, write the specifications, then develop the modules, test every module when completed and at the end integrate everything and perform a final system test.

Because there are risks in the project (scope and technology) you decide to use an agile approach that allows you to involve the partners in the development process and provide feedback to steer the project.

The iterations

Let’s start with probably the most important improvement from a traditional/waterfall approach: making the development iterative, which benefits I described previously.

Therefore you prepare a rough roadmap which will contain all the topics (high level requirements) that you want to develop in this year; remember that you should be able to adapt the path during the development, so you don’t describe them into every detail immediately (no big up front design).
The goal is to have a list of high level requirements, everyone with its priority (this is very important because you want always to know what is the next topic to work on) and a draft estimation, which are then laid on a roadmap which says when more or less the requirements will come (this is always requested / very much appreciated by top management 🙂

The roadmap / list of requirements should be divided into pieces (the iterations). Deciding on the iteration length is an art on itself: you can start with one length and adapt it when you proceed if you realize it’s too long or too short but you should try to keep the length fixed to allow the team to reach a rhythm.

Let’s say we start with monthly iterations, i.e. our year-long development will have 12 iterations.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s