Most people understand that the days of the five-year, 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.

Characteristics of Agile Iterations

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.

Implement Complete Functionality

Agile iterations implement complete functionality for a set of selected customer requirements. This includes the complete mini-lifecycle of analysis, design, construct, test and implementation. The selected functionality within the iteration is not worked on simultaneously. Instead new functionality is worked on as team members are available, meaning at any given time there may be one or more requirements independently going through analysis, design, construct, test and implementation.

Implement Holistically

Each iteration is compressed to a few weeks or even a few days. Short iterations are the result of a holistic set of characteristics of the Agile model. It is not easy to deliver in very short cycles if you pick some of the Agile techniques and ignore others. For example, one of these characteristics of an Agile project is that the product owner is integrally involved in the project and is empowered to make decisions in short timeframes. Obviously you cannot run two week iterations if your product owner consistently takes a week or longer to answer questions and make decisions.

Create Short Iterations

Each team should determine the length of an iteration for its specific project. 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.

Keep Iterations Consistent

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 sprints taking 35, 40 or 50 days. If that happens the Agile discipline breaks down and the project moves more toward a traditional model.

For many years, those were your choices. But now there is a different choice for IT development – Agile.  Calling them methodologies is probably too broad a word. It might be better to refer to them as approaches for doing development, or even philosophies.

There are four general beliefs that light methodologies have in common.

Develop in short cycles. Agile “sprints” usually take no more than 30 days each – or shorter. Partial solutions should be up and running in a very short time, with very tight iterative cycles designed to deliver continually working code that is built up to a final solution.

Value the people. People should be valued and treated with respect. Managers should trust them to do a good job and get out of the way. Agile teams work on a challenging but steady pace that can theoretically be sustained indefinitely.

Involve the client. If you are going to achieve the rapid results, the client must be an integral part of the project team. In fact, they should be assigned full-time and co-locate in the same physical space as the rest of the team.

Strive for simplicity. The basic thought is that if you have a choice between building something in a sophisticated way or a simple way, choose the simple way. Requirements should be simple, design work simple, and the coding techniques should be simple.

Over time, the Agile model has evolved to co-exist along with more traditional thinking of project management and development activities. You can also adopt hybrid mixtures of Agile and more traditional development approaches. This has made the movement more mainstream and safe for most organizations.

Can it work – yes! Can it fail – yes! I have spoken to companies that are highly successful and have cut development times dramatically. I have also spoken to organizations where Agile failed miserably. The bottom line – I think all IT organizations should have Agile projects. All projects are not candidates for Agile, but many are and every organization should probably be doing some Agile work or at least experimenting so that you see how it works.