With all the buzz surrounding Agile software development, lots of people are looking into the process and discovering how easy it is to apply the concepts to projects that don’t involve software at all.
Agile breaks a project into small pieces so priorities can be adjusted to suit a changing environment without derailing the project or throwing away work that’s already been done. Agile projects show constant progress even with continuous (but controlled) changes; the methodology provides a way to see in-process work that allows adjustments with minimal impact. These techniques are particularly useful in the marketing world where the landscape can change daily.
In a nutshell, here’s how Agile works:
- You pick your top priority tasks say, every two weeks
- Work on them without changing the in-process work list for the whole two weeks
- Show what you’ve accomplished at the end of the two weeks, and
- Pick the next set of tasks
Instead of one big ball of requirements you have small sets of real deliverables and can re-prioritize anything not in the current in-process list. Not too tough, right? Now, a little more detail…
In Agile the project ‘divisions’ are called sprints or iterations, not phases. They’re time bound and exactly the same length of time every sprint – let’s use two weeks as an example.
You have the big list o’ tasks for your project – but these are broken into the smallest reasonably implementable pieces and called user stories. The big list is called a backlog and it can change any time with no penalty.
A user story needs to be a separate entity that can be tracked and implemented on its own (if it feeds into other stories you can see how this one turns out and adjust the rest); however, user stories that hang together to make up a larger entity can be gathered into a group called an epic so you can see the whole lot of them at once.
Putting Agile into Action
You have to know about how long each user story will take to complete in order to know what will fit into a sprint, so make a rough estimate of all the user stories in your backlog; if new ones are added, estimate them right away. None should take longer than your sprint time (they should all take considerably less or you haven’t broken them down enough).
Take a look at the backlog and its priorities at least every two weeks and make changes as you need them. Prioritize the backlog in order of importance – each priority can be used only once so you have an ordered list of tasks. Re-prioritize as often as you like.
At the beginning of your sprint, call the team together, pick the top priority user stories off the top of the backlog until the estimates add up to the number of hours you have available in your sprint (people * 8 hours/day * # days in the sprint), assign each story to a team member and get started.
You can’t add stories to or remove stories from a sprint, or change priority once they’re in the sprint — but the sprint is so short that you shouldn’t need to. This gives you some breathing room on the ones currently in process.
Everyone Joins the Party… Every Day and Every Sprint
Every day, the whole team should get together for a few minutes in a ‘stand-up meeting’ where each person says what they did today, what they’ll do tomorrow and what blockers have shown up. The team addresses the blockers and goes back to work (it’s called a stand-up meeting for a reason – it’s not long enough for anyone to need to sit down!).
At the end of your sprint the team gets together to move any in-process stories to the top of the next sprint, do a show-and-tell of the completed stories and throw any user stories not started back into the backlog.
And… you start it all over again, running sprints until your tasks are all done or you feel you’ve reached completion of the project for other reasons.
On your mark, get set… Start your sprint!