Thursday 27th May 2010 by Deborah Cordier

Agile is the all encompassing word used to describe project management methodologies which are empirical.  So from the point of view of a project this means that in an Agile project, some of the definition of what will be delivered is done during the project - and based upon observations and experiments within it.   

There are many different Agile methodologies, for example Scrum, DSDM Atern, XP (Extreme programming), and RAD (Rapid Application Development).  Generally the approach of all of these methodologies is to make a start on delivering some parts of the project, and then define the rest of it once you’ve seen something.  The variation between the approaches tends to be in the vocabularies used (for example the names of roles in the project team, or what you should call a phase of work that is being delivered), and then in delivery - around how much planning is done ahead of starting working on something, and how long you work at it before stopping and showing / using it.  Communication is really encouraged by using these methodologies, as good team collaboration is the key to making it work.  

The more traditional alternatives to Agile project delivery focus on the definition and design all being done upfront, rather than being empirical – often described as a ‘waterfall’ approach due to the nature of one phase leading / cascading to another.  The key phases in such a project are generally definition, design, build, test and deliver/deploy.  The best known example of such a methodology which uses this approach is Prince II.

Currently the use of Agile is very popular now, with it being hailed as the way to ensuring projects deliver better.  Whilst not without its problems at the time of launch, Heathrow’s Terminal 5 was an example of an agile project which was delivered on time and on budget – often compared to the build of the new Wembley stadium which was more than a year late and went over the original budget by more than 100%.  However a word of caution for those who believe it’s a cure-all for all the things that have gone wrong on previous projects which have been waterfall.  If the requirements of a project are really clear and easy to agree at the start of the project, and if the technology being used is very familiar to those delivering it, then a waterfall delivery will actually be the most cost-effective.  

Where Agile approaches can prove more cost-effective is when there is either uncertainty around requirements (whether this is that they’re not understood, will take too long to work out, or the end users can’t agree on them), or there is uncertainty around the technology – i.e. where the circumstances around delivering the project are such that it would be fair to assume that if a waterfall methodology was used, then there would be a lot of change control (read: additional budget) needed later in the project, which clearly in the case of a huge construction project such as T5 or Wembley would be the case.  

Here at SiftGroups we advocate Agile Project Management – i.e. we change our approach to delivering the project depending on both the nature of it, and the project team (including the client team) that we’re working with.  Our Project Managers work with their project teams to come up with and agree the best approach.  

So for example a lot of clients we work with are already using the Prince II framework themselves, so they’re keen for us to do the same.  In this case we will therefore follow the guidelines of Prince II, however we will introduce some good practice from our Agile project experience - for example showing the external client team our work in progress as we progress through the build work (rather than waiting until the end), and ensuring that the communication is open and honest in order to establish good working relationships.   

In more Agile projects, approaches which we have found successful are: 

 

• Time-boxing the work (so delivering highest priorities first within a given timeframe, before agreeing the next highest priorities for the next timeframe).
• Delivering small sets of features in fairly fast interations; allowing later iterations to be shaped by the earlier ones, or abandoned in place of changes / new features which become higher priorities as the project progresses and before releasing the work live.
• Delivering agreed featuresets of work in larger phases (where work will go live at the end of the phase), where the 2nd, 3rd and 4th phases are only defined after the preceeding ones are finished – however each phase is delivered using a waterfall approach.

 

We’d love to hear about other people’s  experience of more agile projects, what worked well and what didn’t - so please do share any thoughts.