Project management:How to apply Agile principles and succeed

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

How can you implement agile principles into traditional project management processes and succeed? We discuss how.


Michael Wood | 17 February 2017

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.

  5. 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!

    Related blogs

    Be the architect of your Project Management career

    Digital Transformation- A Key Role for Project Managers

    Benefits of earning a Project Management certification

    12 steps to ensure a successful project

    How to get into Project Management


QA Training | Michael Wood

Michael Wood

Learning Programme Manager

Michael has been teaching at QA for 12 years and is the lead trainer for MSP, managing successful programmes. Before this he worked with the public sector to implement initiatives such as the egovernment agenda. Michael has also project and programme managed many large scale implementations in the construction industry and in web technologies and ecommerce, as well as enterprise resource planning (ERP) solution for some well know utility and communications organisations. Michael believes in teaching in a down-to-earth style, using everyday real examples and injecting a bit of humour!
Talk to our learning experts

Talk to our team of learning experts

Every business has different learning needs. QA has over 30 years of experience in combining the highest quality training with the most comprehensive range of learning services, ensuring the very best fit for your organisation.

Get in touch with our learning experts to talk about how we can help.