If you've ever been involved with a large web design or software project you'll know that, even if initially it seems every last detail is covered in the specification, once under way there is almost always a need for change of some description. A desire for additional features and customer feedback can change requirements midway through a project.
In the past this has been dealt with by using change requests, leading to extra billable work. This often meant overworked teams and clients unhappy at the extra costs involved for ostensibly small alterations.
“Agile” aims to accept the fluctuating nature of software development and actively attempt to make change a part of the process.
The Agile Method
One of the points of Agile is to deliver working solutions early within a “sprint” - a two week stretch of intense, focused work. At the beginning of each sprint a clear goal is defined. Goals are derived from “user stories”, which are simple statements or descriptions that cover a single task or need of an end-user.
Addressing a user story goal could involve delivering a new feature or improving something that already exists, but at the end of the two weeks there is always something tangible delivered.
A benefit to working in two-week blocks is that we can review often – dropping things that don't work or double down on things that do – increasing the efficiency of the project as it progresses.
As a client you can see the progress that is being made; you are able to shape and steer the direction of the project, instead of being locked down into a specification. This puts more control in your hands. Product backlogs and prioritisation keep you involved all the way through, allowing you to have a voice and a say, as part of a flexible system.
To reap the potential benefits from this approach requires energy and effort from all those involved: our team, your team and especially you. You need to be part of the team for this to work.
Responsibility
You are purchasing an ongoing, iterative process – not a single, finite chunk of time to build a predefined product.
As well as our responsibilities to the project as the agency, you also have responsibilities. You will need to be available throughout the sprint and sprint planning sessions. And ideally part of reviews, so you can help prioritise user stories.
Our Approach
We prefer to run our projects in an Agile fashion, but making this work in an agency environment can be tough – multiple clients with different deadlines makes running full team sprints difficult.
We receive new client requests daily and, as conscientious designers and developers, we want to act on these as quickly as we can. But this can mean being pulled away from our main tasks – already scheduled in for the week. In being seen to be quick to respond to some clients, this might mean we're in danger of neglecting others.
Agile with a Little 'a'
From the perspective of an agency with a number of projects and small teams, diving head first into Agile isn't feasible, but that doesn't mean we can't incorporate some its philosophy into our current processes.
Using only a few aspects of Agile can improve the efficiency and motivation of teams. Mixing sprints, reviews, user stories and burn down charts into a more traditional waterfall approach brings an openness and flexibility into our work that you will appreciate and we will enjoy.
We can run sprints alternating between teams. While one team is able to focus on a project exclusively for two weeks, another team is working on a variety of projects for other clients, fixing issues, working on retainers or addressing internal tasks.
This is agile but not fully “Agile”. Understanding the differing requirements expected of us as an agency means we can implement processes allowing us to run both traditional waterfall and agile approaches side by side.