How does agile work in an agency?

In my time working in an agency, I've seen a lot of projects and a lot of discussion around how best to plan and run various projects in the agency environment. Distinction's 2020 brand repositioning to the strategy agency that's all about the action led to some interesting discussions and changes in the way we think about and plan for projects.

It's been clear for over two decades now that the old way of planning and managing projects, known as the Waterfall methodology, just doesn't cut it in today's world of high-speed change. The COVID-19 pandemic and the changes that came with it (and continue to come) show us, beyond a doubt, that even the best-laid plans are meaningless in the face of a world that changes so rapidly from one day to the next.

So why do agencies continue to present rigid, up-front plans to clients? Why do clients continue to insist on having a contracted scope and budget for their project up-front?

This way of thinking from clients to sales teams leads many agencies into adopting a waterfall approach from the start of their sales process and this can make it very difficult to transition into a more agile approach for project delivery since all of the estimates are already seen as "fixed" by the client. What do you do as a project manager or developer when you're asked to produce more detailed estimates and they end up being more than the estimates that sales used to win the project? It puts project managers in a difficult position and invariably ends up in some very uncomfortable conversations with both the agency leadership and the client.

So how do we avoid this?

Getting started

Firstly we need to move the conversation from features and more towards goals. This is a subtle but important distinction to make. A feature is "how it's done" whereas a goal is "the outcome we want". Once the client is talking about their goals the "how we get there" is much more flexible.

We can then begin to refine the client's high-level goals into more actionable requirements. These then form the high-level epics of the project and the next step is to get the people that will most likely be doing the work to give these high-level epics some estimates - but not time estimates.

Time to play poker

A good way to estimate these high-level epics, and my personally preferred method, is to use "Story Points" based on the Fibonacci sequence. Get the delivery people in a room (real or virtual) and play a game called "planning poker".

Timebox each epic - 5 minutes for example - and allow the group to discuss it and ask questions to the people that worked with the client to define it. At the end of the 5 minutes, each person that will be involved in the delivery makes a secret "bid" of story points from the sequence below.

Everyone reveals their bid at the same time and if they are all the same that is the estimate for the epic. If there are differences you just discuss the outliers and come to a consensus quickly. Any discussion at this point should also be timeboxed - the idea is to estimate quickly and move on.

These estimates will give you an idea of the complexity of each epic and while these points don't translate directly to time at this point, they are useful in determining where the majority of time will likely be spent.

Once you've estimated all of the epics look for any that have been awarded the highest value allowed in your sequence. These estimates typically come from a lack of knowledge or something that is too broad in scope. Each of the epics at the top end of the estimate range should be discussed separately to determine why the estimates are so high with a view to either getting more information from the client or breaking them down into more manageable pieces. Eventually, you should end up with a list of epics where each epic alone doesn't feel like a big daunting piece of work and you feel like you have all of the information you will need to produce it.

Going to MoSCoW

Now that you have a list of well-defined requirements and an idea of how much effort each will require to deliver each, it's time to go back to the client and talk about priorities.

I like using the "MoSCoW" system for this as it helps the clients to prioritise their requirements without getting bogged down in too much detail. Ask the client to mark each requirement as one of the following:

• Must have
• Should have
• Could have
• Would like to have (but not this time)

This process helps to define the intended scope of the project. Everything in the "Must", "Should" and "Could" categories should be considered as "in-scope" at the start of the project.

Items in the "Would like to have" category can be kept in the project backlog as "stretch goals" but it should be clear to all parties that those items will not be planned into the completed project or worked on unless everything else is complete.

Prioritising items in this way helps us to understand the order in which features or stories should be completed. Ideally all of the "Must have" items would be completed before any "Should have" items are started, and so on.

Expect the unexpected

No project ever runs to completion without something changing. Whether it's a new requirement, a change in the client's business priorities, delays from third parties or just that one of the requirements ends up being more complicated than expected.

In these cases, the conversation with the client is much easier to start because they've been thinking about priorities all the way through so far. When that new priority comes in or the big "must-have" feature takes longer than expected we can talk to the client about either extending the budget/timeline or dropping one or more of the lower priority items from the project to take account of the change in circumstances.

Since, in an agile project, you'll be talking to the client much more frequently than you would in the old waterfall method, they can be made aware of these things sooner avoiding any surprises towards the end of the project.

What about the time and money?

It's a fact of business life that clients will want to have some assurances of both when they will get what they're paying for and how much it's going to cost them. In established agile teams it's relatively easy to estimate a timeline for a project based on the team's velocity (number of points completed over time) on previous projects. This is much harder to do in an agency where you may not be working with the same team members for every project.

It's also a fact of software development that there will always be surprises in any project. There's no way that we can know all of the ins and outs of a clients business processes at the start of a project. There will always be things that only come out once we start actually building the project and, most of the time, the project can cope with them but there are those occasions where a feature turns out to be far more complicated than originally described.

The answer is to change the question. Rather than promising fixed scope and a fixed budget to clients, just pick one. You know your client best. Which is more important to them; the budget or the scope?

Make sure that they understand that you will do as much as can be done well with the time/budget available. Things lower down their priority list may need to be dropped from the scope to achieve that. Most clients will be fine with this in the early stages of discovery and development and, if it becomes an issue later, you have set expectations early and at that point, the client can choose to either drop a low-priority feature or add to the budget so that it can still be completed. In most cases they will drop the feature since getting the project to market will be more important.

It's better to get it to market and then improve on it than to never get it to market at all.

The other side of this is where the client must have all features to make their product viable. In these cases, they must be prepared to increase their budget to cover any surprises, or to be more flexible with the scope to allow lesser implementations of their features in version 1.

Overall, communication with the client is key.