Posted by: Craig Harding | August 19, 2009

Why not make AGILE agile?

So you have been asked to manage your first AGILE project. You have done some training and research but are still unclear about iteration duration or “time boxing” and “just-in-time” requirements. Should you go with two, three or four week iterations? Well, why not keep AGILE agile?

The whole premise of AGILE methodology is to be flexible and lean. “AGILE offers bare essential high-level requirements and the creation of detailed requirements just-in-time. This can be used for design and development within each iteration and can also be applied to the iteration duration or “Time Box” itself.” Some AGILE purists stay to the tried and true method of picking a constant duration for all iterations.

I have tried this and find that quite often you are trying to make a set of integrated functional requirements fit into a predetermined duration of development. Often, this is like trying to fit a square peg in a round hole; either there is not enough work to fit nicely in the allotted timeframe or there is not enough time.

So, why not make your “Time Box” flexible for each iteration such that it fits the work package that will be delivered? Your first iteration may be three weeks to allow you to deliver the functionality package, but your next iteration may require four weeks to complete a delivery. Give it a try.

You may be surprised how well the flexible AGILE methodology applies. Just be careful not to make your iterations too small. There is a significant amount of overhead in each iteration for deployment and code management. You also need to leave enough time for your business analysts and testing team to run the current iteration and prepare the detailed requirements and test plans for the next.

What experiences (good or bad) have you had with AGILE project Management?

Cheers,

Craig

Advertisements

Responses

  1. A classic black swan event.

    Unfortunately, there was a time when suggesting a plane could fly into your building was dismissed as not-a-risk because it was so extremely unlikely. But like an infectious disease, once you identify a risk, you have it forever – it may remain dormant (extremely extremely unlikely) but you can never ever remove it from your risk map. It just moves to one of the corners and sits there.

    Trevor Levine
    http://www.riskczar.com

    • Hey Trevor,

      Excellent point, we have to be more and more creative when identifying risks for our projects and allowing for related contingencies. Thanks for the comment.

      Craig

  2. My company has its own flare of Agile Project Management. Iterations are kept to the minimum amount of time to complete what is needed (develop, verify, validate) so we can revisit, see what works, and then build upon what we have. We look at a project as having a number of phases and each phase can be broken down into iterations. If possible we try to get some iterations out to beta clients. This allows for client feedback so as to ensure we build something that is wanted rather than something we think is wanted. It works well.

    C

    • Hey Dave, client feedback early and often is certainly one of the main benefits of any Agile approach. It really reduces those “gotchya” moments late in the delivery process. Thanks for the comment.

      Craig

  3. Everyone praises Agile and how flexible it is, but Agile has its limitations, it does apply well to the software industry because of the constant change requests flowing in from the client/stakeholders. As for the other industries, Agile may not be the best solution.

    As for the length of the iteration, there are many writings on the topic, but as you said, it should be subjective, but it should never be too long.

    • Thanks for the comment from the PM Hut. Your post on “Agile has its limitations” clearly points out that not all companies are necessarily ready to jump into Agile projects just to be on the band wagon. There are alot of buy-ins required from staekholders and a shift from existing methodolgies required to make it work effectively. At the end of the day, Agile may not be the best approach for some organizations.

      Thanks again

      Craig


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

Categories

%d bloggers like this: