Sunday, October 25, 2015, AM | Leave Comment
Most people understand that the days of the huge monolithic project are over – and have been for some time. The better approach is to break large projects into a set of smaller, easier to manage projects.
Short projects are easier to manage than large projects. There are fewer things that can go wrong, fewer people involved, less time for scope changes, etc.
The Agile model
The Agile model takes this to an extreme by stating that even the days of the six-month development cycle is over, as is the three-month cycle and maybe even the one-month cycle.
Partial solutions should be up and running in a very short time, with very short iterative cycles designed to deliver working code that is built up to a final solution.
The Scrum model
In the Scrum model these short iterations are called “sprints.” The term “sprint” gives you the impression that the team runs hard for a short period of time, and then catches a quick breath before undertaking another short sprint.
Agile iterations implement complete functionality for a set of selected customer requirements or “stories”.
The selected functionality within the iteration is not worked on sequentially.
Instead new functionality is worked on as team members are available, meaning at any given time there may be one or more stories independently going through analysis, design, construct, test and integration.
Each iteration is compressed to a few weeks or even a few days. In the extreme, the product is updated, tested, integrated and delivered on a daily basis.
Obviously this takes a large amount of discipline and rigor.
On the other hand, you generally don’t want your iterations to take longer than 30 days.
If the iteration is larger than 30 days, it will start to look more and more like a traditional iterative project and has the potential to miss many of the benefits of the short iterative cycle.
Shorter iterations are generally better than longer iterations, and 30 days is probably the longest that you want an iteration to last.
Shorter iterations tend to squeeze out inefficiencies and overhead processes.
For example, you may choose a 30-day iteration because you have a one week approval process at the end of the iteration.
If you force the iteration down to two weeks, it will also force this review process to get shorter as well.
When you are first adopting Agile, you may need to have a longer iterations as you deal with the culture change required for Agile projects.
However, as you get better and more comfortable with the Agile model you would expect that the iterative cycle can be reduced.
It is important that each iteration stay the same length so that your team can develop a steady rhythm of work.
If you chose a 30 day iteration, for instance, you need to make sure that each iteration is delivered in exactly 30 days.
You don’t want some iterations taking 35, 40 or 50 days. If that happens the Agile discipline breaks down and the project moves more toward a traditional model.
Agile teams deliver complete and functioning code within short iterations. This is one of the defining characteristics of an Agile project.
Iterations can be anywhere between 1 day and 30 days. More mature Agile teams will tend to move toward shorter and more frequent iterations.
This column is © copyright to www.Method123.com and originally appeared in their weekly project management tip newsletter.
Use the best project management process in the world. Method123 Project Management Methodology (MPMM) is used by tens of thousands of customers around the world.
Take a test drive with the free trial download.
Buy MPMM today – NOW with extra program management and IT development modules.