Skip to content

Engaging your agency with an agile methodology

Tristan Bottrell Technical Director (AsiaPac)

Man on a tightrope

Whether it’s the flavour of the month or the new standard, agile methodology is definitely the talk of the town. It addresses the major concerns that traditional waterfall run projects have and allows an organisation’s team to show the fruits of their labour quickly and frequently. Now, this isn’t a typical “Hey everyone, how cool is agile?” post, as I’m sure most people reading this will have a basic idea of what an agile methodology is all about. What I will discuss is how you can engage your agency to work with an agile project.

This all starts at the beginning of course.

Typically, most organisations put out tenders or fixed project briefs to agencies. This makes perfect sense for the company, because by writing a document that captures all their high level requirements and gathering a fixed cost, they minimise their risk. Stakeholders know exactly how much it’s going to cost and when it’s going to be delivered, and all their requirements have been documented so they’ve done all they need to do, right? Bring on the agile!

Well, not exactly, as you see this process is high risk for the agency, especially when we’re talking agile.

In a waterfall approach we follow the usual process:

  • Discovery phase to flesh out those requirements
  • Design/Build
  • Test
  • Deliver
  • Feedback

The problem here is, the feedback is too late. By this point that fixed budget and timeline has probably gone out the window and you’ve now realised the three basics for any web based project:

  1. You can’t possibly gather every single requirement prior to starting development
  2. Requirements WILL change through the project life cycle
  3. As time progresses you’ll realise that there will always be more work than your budget or timeline allows

Agile addresses the points around requirements, but what do we do about the time and money factors? How do you engage your agency to address these three issues and work with your internal team through agile? There are three options that can reduce the risk to both the agency and the organisation. Your individual needs may force you towards one option more than the others but that’s for you and your team to decide.

Option 1) Time and materials
Most agencies work on a time and materials basis. You’re effectively paying for man hours, a daily or hourly rate which is agreed on and usually billed monthly. Minimal risk for the agency but high risk for the organisation as there is no fixed budget to measure investment.

Option 2) Fixed price MVP (nope, I’m not talking about Most Valued Player)
A Minimum Viable Product is a fully functional and tested product that meets the documented requirements. It may need some enhancing and additional phases to bring the product to the ideal level, but it provides all the necessary features. Providing a fixed price and timeline is indeed possible and will keep the stakeholders happy. It’s recommended to keep a little budget aside for some enhancement work that will be billed as time and materials.

Option 3) Block of work quotes
The idea is to work with your agency to build up a project backlog over a few months, breaking the program of work into smaller projects that can be estimated for. The agency will work with you to then produce a sprint backlog. I’d recommend a three month period, as it’s long enough to get work out and short enough to not blow out the budget. As the agency works through the sprints you can assume agile will work its way and requirements and scope will change. Bear this in mind as your sprint plan will inevitably change and some of that three months’ worth of work will move to the next block.

You will have noticed in the third option I mentioned working with your agency. This really is key to making sure any agile work you do with your agency is a success. You don’t need to be in the same office but face to face time is always important including sprint review/planning meetings. Give your feedback, listen to their advice and at some point, you’ll need to decide when the flexibility of an agile project needs to come to an end and a product needs to be delivered.