Why Going Agile Is Worth the Effort
Reading time: 4 minute(s) - 800 words
Many digital agencies don’t follow agile practices for their web development projects. There are business case reasons for this, but going agile is possible. Here’s how.
The sniff of new work hits the agency. The accounts team take a brief and want a quote for it. They ask the same question:
How long will it take to build?
It’s always a loaded question. Because they’ll want the lowest possible number. Days rather than weeks, ideally.
The reason? Because the agency business model runs on turning jobs over at a pace and getting paid. The other work is monthly retainer work paid for on a rolling contract. But that’s much harder work to get.
So now the development team has a nightmarish situation. They can’t assess the work needed to be done. Not without crimping off how much time they really think the project will need.
If they quote what they really think, the accounts team have to go back with a bigger quote than they were hoping. Chances are, they won’t. So the dev team have to accept a tighter deadline.
This is because agencies typically work on a day rate for development work. Which gets multiplied up depending on the time quote from the dev team. Plus or minus whatever is considered doable.
The whole situation is anti-agile. Because:
- You need a better way of estimating how much time is needed
- The agency need to trust the developers to come up with a realistic estimate
- The dev team should be cross-functional and self organising
- Self organising teams need the autonomy to decide how best to get their work done - without interference from outside the development team
Let’s be clear, though, it’s not as though digital agencies are blind to this. As I said earlier, the business model is a tough one. The business case has to be kept tight for all web projects because costs can rise quickly.
Kanban to the rescue
I’ve implemented Kanban in digital agencies in my past career. For exactly the reason that going fully agile wasn’t going to work.
Kanban is less prescriptive that trying to introduce, say, scrum. It’s easier to drop into what already happens in the agency. It also means bottle necks are easy to identify.
Once Kanban is up and going, it presents an opportunity to introduce agile practices. Maybe. If not, at least the agency has a way of working that will prevent the finger-in-the-air estimates used in the past.
Also, by limiting how much work-in-progress there is, real work gets done.
Talking of which, developers are rubbish at making estimates. There are numerous reasons for that - many of them valid. It doesn’t change the fact that accurate estimating in the agency environment is vital.
Planning poker (I’ve described the process here - Estimation and Story Points in an Agile Project - Andy Hawthorne ) is one way to get the dev team to agree how much time they need. The discussion will help to ensure the quote is realistic. The other half of the problem is easy to fix.
Training the agency accounts team to understand the nuances of web development is not going to happen. But you can train them to recognise when things are more difficult than others to achieve. Then, when they are explaining a quote, they have a way to be convincing.
Implementing agile practices needs a framework. Scrum is the popular one. But I’ve said already that it can be too prescriptive for an agency.
A hybrid of scrum and and kanban works well. You take certain parts of scrum and apply it with kanban and you have something close to an agile methodology.
Agencies don’t have fortnightly sprints. That’s too long. You can make a weekly sprint for bigger projects. But the devs working on the project need to be well supported to make sure they are hitting their targets.
Is it worth it?
In a word: yes. You have to tailor the chosen agile methodology to the given agency. But making the effort will see a rise in web project efficiency. Ultimately, it’s about getting to a deliverable. Going agile improves the chances of that happening on time and on budget.