You can’t get away from Agile these days, it’s everywhere. I sometimes put my Local Gov hat on and go to events where you get surrounded by Agencies telling you that Agile is the best thing since Mr. Hovis started wielding a knife. It’s as though it’s some secret which only they know and which no-one in Local Gov could possibly have heard of. But times are changing, particularly after the work at GDS which is being seen as a role model in Public Sector Agile delivery. Many people in Local Gov are using Agile and using it very successfully. However, there’s a time and a place for Agile and often agencies get clouded into thinking that it’s not just the default way to deliver projects but the only way.
The project I’m currently delivering is using a combination of Agile and Traditional project methodologies. This may sound like a recipe for disaster but there’s logic behind it and it’s proving to be quite successful.
Firstly lets define what we mean by Agile and Traditional project methodologies. By Agile I’m referring to delivery features such as:
- daily scrum meetings
- sprint planning and reviews
- storyboards and backlogs
- close interaction between users and developers
For traditional delivery I’m referring to:
- upfront planning and gantt charts
- structured milestones
- clear delivery phases
- well defined requirements before development
Agile is strongly suited to projects where:
- the requirements are not clear and changes are expected
- teams of 5 to 8 people
- projects can be delivered incrementally
Traditional delivery is more suited to projects if:
- there is a clear understanding of what needs to be delivered
- strict order of delivery
- small number of people working on the project
So what have we been doing on our project? We’ve been migrating an existing site to a new platform. It’s not quite a strict like-for-like migration as we’ll be taking the opportunity to make some improvements on the way. However the existing system is well liked and well used so we’re not looking for dramatic changes. Also keeping the new system similar to the existing will reduce the impact on users and the costs of training.
After reading that you’re probably wondering why we’re doing the project at all. The reasons are that the existing platform is unsupported, very expensive and hard to maintain or enhance. Migrating to a new platform fixes these issues and builds a platform for future development.
We’re following the GDS project delivery standards by producing Alpha and Beta releases. Our approach has been to deliver using a traditional project methodology for the early stages moving to Agile delivery later on. The reasons behind this are:
As the existing platform is well known and largely popular the requirements are generally well understood. (We’re migrating because of reasons other than functionality). Our users are busy and while they are very interested in the project they don’t want to be involved in every detail. The initial stages have required delivery of the infrastructure and base functionality neither of which require much user feedback. We have a small delivery team often with just a single person working on the project at a time
As a result we’ve produced our Alpha release in a very short time frame using a traditional project delivery. We defined all the requirements up front and delivered them. This provided a working version with the base functionality.
We’re now moving to a move Agile delivery where we will be determining the additional user requirements and delivering them with much closer user involvement.
So, you can mix and match project methodologies within the same project. There’s a time and a place for Agile and Traditional project methodologies and to work exclusively with one or the other can limit your delivery.