Our journey into Agile, pt.1
In November of last year (2009 if you don’t have a calendar to hand) we started to seriously look into using Agile methodologies to better manage and run our Web projects.
The crunch came when we realised that in many cases we weren’t delivering what we had promised to do, we were snowed under. We took a day out to evaluate where we were and to our horror we discovered that we
- were working on over 20 projects concurrently.
- were not moving very quickly on any of them.
- had a backlog of over 120 projects, which we estimated would take around 13 years to complete if things continued as they had been going.
Something had to change. We had to change. We needed to stop saying yes to everyone about everything and we needed to find a way to more efficiently and effectively plan and manage our projects.
That’s when we turned to Agile for assistance.
Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams
Definition of Agile from Wikipedia
Agile is something that we’d looked into a couple of times in the past. It struck a chord with us: iterative, incremental development was something that we did anyway. We often practiced pair programming, we were using something akin to a Scrum task board, we had a daily stand-up meeting each morning, at times we would have ‘customers’ sit with us to iteratively work through a design.
Simply adopting certain methodologies doesn’t make you Agile though, but it was a good start. Iterative and incremental, if you like.
Almost Agile, even.
Oh, hang on …
One of the things that we struggled with most was how to run multiple projects using Agile. Because everything we read talked about the importance of running only one project at a time. Everyone that I spoke to from commerce or business about it stressed the importance of running only one project at a time, and everyone from higher education I spoke to stressed how impossible it was to run only one project a time.
Then I discovered this paper from Karl Scotland, formerly Development Team Leader at BBC Interactive: Agile planning with a multi-customer, multi-project, multi-discipline team (DOC, 225 KB) who gave me the confidence that it could work. In this conclusion he wrote:
The team is able to manage the various complexities of multiple customers, projects and disciplines by working in a way which allows them to treat the work as if there were only a single customer, project and discipline. Thus they work on a single pool of stories which are shared by all the different customers, projects and disciplines.
So we could run more than project at a time, if we were careful. We got planning.
Next week I’ll explain what we did next…