Agile by stealth: How to apply Agile principles and succeed in projects

So you’ve attended a course on Agile, or read a book (“Agile for dummies” is very good, by the way) or you’ve seen something online. You’ve gone to your boss and said “Hey, we should use Agile here” and been told “we’re not using any of that new-fangled nonsense, we’ll stick with what we’ve got, thanks”, and you’ve come away downcast and got back on with your company’s waterfall method, which is fine, but you can’t help thinking that Agile would help…

Well, the good news is, you can still use some of the best parts of Agile, without calling it Agile!

In this blog, I will discuss some of the main features of Agile, and show how they can be implemented into a Waterfall (or “traditional”) approach. Although by the way, don’t get me started on “traditional”… Agile is not new, it’s been around in some way shape or form for a hundred years, but as I say, don’t get me started…

The way we’ll approach this is not to try and adopt any framework or lifecycle (after all, Agile approaches are quite light on frameworks anyway, that’s the point), but instead concentrate on the principles of the Agile Manifesto, which, I hope you will agree, can be applied to any project.

First off, let’s get one thing sorted; Agile project management is NOT a method (there is no method called “Agile”, you can look it up… I’ll wait…) there isn’t a method called “Waterfall” either. There are methods such as Dynamic Systems Delivery Method (DSDM), which is an Agile approach, or PRINCE2, which is primarily a waterfall approach, but that is all. Agile, like waterfall, is a way of thinking, and as such, doesn’t mean you need to prescribe to a specific process to be Agile, or Waterfall for that matter.

The Agile manifesto is the guiding star for Agile, all approaches that call themselves an Agile approach adhere to it. The Agile manifesto, put together by some of the great luminaries of software development and its methods, was created in a ski lodge in 2001 (if the stories are to be believed), you can see it here. It has four key values, and each one can be applied anywhere, without going around saying “I’m doing Agile” and freaking out your bosses.

1. INDIVIDUALS AND INTERACTIONS over processes and tools

In Agile, this means getting your teams and suppliers to deliver by (gasp) TALKING TO PEOPLE, so how about sitting down with your team on a regular basis (say, once a day) and discussing it with them? A “roll call”, or “morning stand-up” with your project team will meet this need, and it only needs to take 20 minutes, and can be done whether you are “using Agile” or not. You are also much, much more likely to deliver a successful project, so get out of your chair and go and talk to people.

2. WORKING SOFTWARE over comprehensive documentation

For Agile, this means getting our hands dirty quickly and getting working stuff out there ASAP – it excites the customer and gives us something to work from. In a waterfall approach, if you plan the project so that you get basic requirements from the customer and create proofs of concept (simple mock ups of what you will deliver), or carry out feasibility studies, then you are giving yourself the opportunity to show the customer what you can do early on, just like in Agile. If you create a high-level specification, then define the further details later through supporting documentation and processes by working with the customer, then you are following principle 2 of Agile, but still in a Waterfall approach!

3. CUSTOMER COLLABORATION over contract negotiation

As with the first principle, (gasp! Again!) TALKING TO YOUR CUSTOMER. You can hide behind your Project Initiation Documentation, or Project Product Description, or Requirements Specification or whatever, but instead, talk to your customer regularly (say, once a week on a short project or once a month on a long project). If you get out from behind your desk, go to the customer and ask them what they want then, guess what, you are applying another Agile principle! You are also much more likely to deliver what you need to deliver, and have a happy customer.

4. RESPONDING TO CHANGE over following a plan

This is a not-so-subtle dig at Waterfall, where the impression from Agile fundamentalists (and never trust a fundamentalist – Agile and Waterfall both have much to offer) is that in a Waterfall environment you are completely inflexible, and everything needs a change form, in triplicate, before you dare move. In reality, change is happening in Waterfall projects all the time, it’s just that it is done in a more controlled manner, and when the cost of change can be huge, such as in a construction project, this makes sense. If you want to apply this Agile principle, however, it can still be done. You could ask the customer to talk to you (as above) about what they want, then do a quick analysis and discuss the potential implications of the change on the spot (and Agile does all this too), and then do a quick email exchange to agree the change, then get on with it.

One final point here, is that with all this flexible change approach and doing what the customer wants can lead to deadlines being missed and budgets being overrun, well guess what, if you don’t do what the customer wants, that will happen anyway, as they won’t sign off what you produce!

So, applying Agile without calling it Agile essentially means talk to your teams constantly, talk to the customer constantly, streamline (a bit) your paperwork when it comes to change, and plan your projects so that you deliver quick wins and early functionality rather than leaving it all to the end... Simple!