Getting Stuff Done: What is the "Agile" Approach and Why Should You Care?

I’ve been looking forward to writing this post. For the past three months I’ve been working in a programming team working according the “Agile” project management approach. To put it bluntly, it’s the best way of getting stuff done that I’ve ever encountered, putting my previous years as a project manager to shame. Historically, Agile has been used for software development, but it’s gaining traction as a method to be used in the business world, and I contend that it is also fantastic for entrepreneurial work, and potentially any project you’ve got going on in your life.

I will begin by mentioning that about a year ago I was given a reasonably detailed explanation of Agile (something like a two hour talk). At the end of it, my reaction was pretty much “meh”. This was an error on my part. **Part of the reason for this is because a lot of project/time management “speak” sounds very similar, so it can be difficult to realize that subtle nuances make a vast difference. The other issue is that Agile was developed in California by geeks with a tenuous grasp of reality, and is, as such, riddled with absurd Disney-esque vocabulary. One needs to overcome these obstacles.Hopefully in this post I will help you understand the value of Agile. In order to do this, I have divided this post into three sections:

I. Agile Background.

II. Breakdown of Agile Components.

III. Brief example of an Agile project: setting up a business website.

I. Agile Background

The Agile Manifesto introduced the term “Agile” back in 2001. Its key pillars are:

• Iterative incremental development/work.
• Self-organizing, multi-talented teams.
• Time-boxed work periods.

Agile was originally created as an approach for software development, and is now widely used in the tech world. The reason it grew out of the tech sphere has to do with the rapidity of change in that environment, combined with the vast costs of software development. Furthermore, when working at the bleeding-edge, attempts to innovate easily result in unexpected problems. It is therefore important to constantly be checking if the product being developed meets the requirements of whoever is footing the bill. Yet the above reasons are often found in other walks of life, indeed, the rapidity of change in the world is something of a constant, making Agile widely applicable.

For those who are interested in “schools of thought”, Agile is the undulating, flexible river, while Waterfall and Prince2 are concrete, straight roads.

II. Breakdown of Agile Components.

In Agile, a working period is called a “sprint”. A sprint is typically about two weeks long, though could be between one and four weeks long.

The team responsible for the work in a sprint is called a “scrum”.

The work to be completed in a sprint is broken down into chunks called “stories” (I know, the name’s are bullshit, but just deal with it).

Before a sprint begins, a “sprint planning” meeting occurs. In this meeting, each story is presented to the team. There is a formal process where the “product owner” (who understands the motivations behind any given piece of work) explains what the “acceptance criteria” are for a story (i.e. what would constitute completion). Crucially, in this meeting each story is “estimated”. This has two components – story points, and hours. Hours is easy to understand – this is an estimate for how long a story might take. Story pointing is more difficult to explain but it roughly has to do with how complex a story is. A full explanation of story pointing and its pros/cons is beyond the scope of this post.

Every sprint ends with a “retrospective” where successes/failures are documented. What this means is that the scrum has a damn good idea how much work (how many story points/hours) it is capable of doing in a sprint. This means that in the sprint planning meeting, the scrum will agree to complete a highly realistic amount of work. Indeed, when done right, Agile scrums should always complete stories.

Okay, I’m getting a bit carried away here…

SUMMARY: Complex massive projects are broken up into two week chunks. The work in the two week chunk is broken up into little tasks which are checked for requirements and difficulty and then assigned to team members.

Once a sprint planning session has taken place and the sprint has begun (typically right after the planning), then NO MORE work can be agreed to. The sprint is now locked down.

Everyday of the sprint, the scrum has a “stand-up” which is a very quickmeeting (my stand-ups are rarely longer than 10 minutes, and we literally stand up for them)where everyone explains what they did yesterday, what they are doing today, and any unexpected problems. That’s it. Very few other meetings are necessary. You have no idea how wonderful this is. Another day I will post about my deep hatred of long meetings, and how the vast majority of meetings occur because people are too lazy to think.

At the end of the sprint, when every story has been complete, the team checks that the work completed matches what the client/business/whoever needs. If it does not, then new stories can be added to the next sprint.

SUMMARY: If something goes wrong, you only waste two weeks.

Numerous complementary techniques feed into the Agile framework. My favourites areKanbanand burn down charts.

Anyway, I appreciate that all this can seem a little vague, so it’s time for me to put together an example.

III. Brief example of an Agile project: setting up a wordpress.org blog.

Imagine you want to create a website using wordpress. This could be a step in a much larger project, such as setting up a business. Setting up a business could be a six month project, with a bunch of steps, each of which might be worthy of a sprint like:

• Secure business funding
• Setup website
• Create product pilot
• Decide upon manufacturing approach
• Conduct product marketing

etc.

Now, each of these steps could be a sprint, or multiple sprints. Let’s pick one to unpack as an example: “Setup website”. If you decided you would complete this task in one sprint, you would probably create the following stories, and assign them the following hours/points:

1. Buy domain and web hosting: (3 points, 2 hours)
2. Install wordpress and useful plugins: (5 points, 5 hours)
3. Sign-up to Google Analytics (1 point, 1 hour)
4. Create custom graphics and logo (8 points, 12 hours)
5. Create written content for your site pages (5 points, 7 hours)
6. Create pages for your site, including all styling and content (13 points, 18 hours)
7. Write Javascript for any dynamic page elements (13 points, 15 hours)
8. Test key site functions such as shopping cart (5 points, 8 hours)
9. Test site look and feel (3 points, 4 hours)

For one person this would be about a sprint’s worth of work, obviously less if you had a team (you would assign stories depending on team member skills).

Each story must have an acceptance criteria so you know when it is done. For example, story 6, “Create pages for your site, including all styling and content” might have acceptance criteria like this:

Pages must include “About me”, and “Products” – with each page to include written content from story 5. Both pages should be styled so they have a right hand margin, and a main navigation menu across the top of the page. The website logo should be visible in the top left of every page. There should be no footer. A visual mock-up of the preferred page coloring is shown here [some photoshop estimate].

You now know exactly what you’ll be working on for the next two weeks, when you’re falling behind, and what you’re aiming to achieve. In a way it’s obvious, but so few people/organizations actually behave this way. It takes time and effort…but damn it’s worth it. After the two weeks was up, you’d check with whoever was the “boss” if the website you’d created was what the business needed. If it wasn’t, then worst case you’ve wasted 2 weeks. More likely, you’ll have to make some adjustments in the next sprint due to unexpected changes in the business landscape – this is the iterative approach.

Working in an Agile team is one of the best things I’ve ever done. If you ever get the chance, I would recommend it. Even if you don’t, check out the concepts, and apply them elsewhere. If you want to get projects done, then I don’t know a better way.