The Transition - Scrum in an agency environment
Transitioning from waterfall to Scrum requires shock therapy from the very top down. You need to forget what you know, and trust that the process will work. You need to make no exceptions to the rules - start with a strict implementation so that you don't end up doing Scrum But… - if you don't do a strict implementation, you'll never be able to identify what does and doesn't work about the process for your agency. You'll struggle to figure out whether the exceptions caused the problem, or the rules did.
Your first Scrum project
If you've decided to undertake a Scrum project as a pilot program, ideally choose a client that comes with a very trusting relationship on a project that is a series of updates to an existing product. Scrum's Achilles heel in an agency is trust between client and agency. Particularly when you haven't done it before! The process is so transparent that you can't pretend that you do it all the time if you haven't done it before. You're better off being totally honest, finding a client that trusts you, and embarking together with the new process that promises so many positives.
Slow it down
Scrum can move very quickly - particularly for clients. When we first picked it up, we used a three person team not including the Scrum Master. The team had
Designer 2 days a week, backend Developer 3 days a week, and frontend Developer 2 days a week, Scrum Master 3 days. When you create your team, just set the weekly time based on a rough proportion of work you would expect from waterfall.
This should allow you to stretch your budget for a longer period than a few weeks, and let you deal with smaller volumes of work using the process.
The initial Scrum framework
Choose a framework that keeps with the strict principles of Scrum in order to see how it runs.
We ran weekly iterations, maintained a strict "User story" approach using points to estimate collective team effort. No stories were broken down into tasks beyond discussions amongst the team.
We started with a backlog of items that were reasonably clear, but not fully fleshed out. A list that was between one and two months of work for the team - so they could see the light at the end of the tunnel.
We had the client attend Weekly showcase, retrospective, and planning that we bundled into one meeting - it made it easier for the client to be available, and was good hands-on time with the team.
Who should be Scrum Master
The Scrum Master is an important role, but one that is inherently powerless. The Scrum Master needs to be humble, stand up for their team, listen to advice, and defer to the team for decisions. If you've come from a big Waterfall agency, your Senior Producers or Project Managers will find it much much tougher to fit into this role. They are used to making every decision, taking personal ownership of the project, being in complete control - they pride themselves on it.
There are two good options: firstly an account service member with almost no Project Management experience - give them a lengthy session describing the nuts and bolts, and ensure they get coaching through the process from someone more senior. Secondly, if you can spare it, one of your actual team-members will be dedicated to getting it right - the benefits will sit closely with them.
Your first Scrum project's results
Our first Scrum project achieved a few things by it's conclusion at 6 weeks - mostly around the organisation seeding the right ideas. It introduced a new sense of empowerment and collaboration into the team, the team understood the idea that they controlled and evolved the process itself, the client saw huge benefits of being closely involved, and the organisation saw that it was possible and scalable.
It's important that your first experience is positive, because there are a million Scrum but… stories where the process loses it's reputation. Keep it low risk, and slow it down.
Continued evolution of your process
Run a retrospective on the process where an assessment of your approach is considered. Have the Agile manifesto up, and be very conscious of the principles at the core: empowerment, collaboration, collective effort (not estimates from individuals), evolving solutions, etc, etc.
Run a few more projects with partially resourced teams to gradually increase the pace of your teams.
Pitfalls to look out for
Your transition has built some steam. Here are some things to look out for:
- Make sure you stick to the key principles. Don't let someone tell you a deliverable like a set of wireframes is necessary - and if they do, keep it intentionally lo-fi - whiteboards or sketches.
- Avoid Fixed Scope, Fixed Cost projects at all costs when you are transitioning - you need flexibility in either scope or cost in order to see the benefits of the approach, so doing a fixed scope / cost project will just make it look bad, and you won't get any of the benefits.
- Keep it with clients you trust. Be careful implementing your new approach with new clients, because there is typically a high level of uncertainty early-on in Scrum projects, which can be VERY challenging for new client / agency relationships.
- Listen to your team. If there's something they hate which doesn't impose on the key principles, let the process evolve. Ultimately it should be theirs.
Upcoming: Dedicated teams and larger projects
Dedicated teams are clearly where Scrum hits it's stride in terms of efficiency. You'll see throughput increase, quality of work improve and overall the team may be more satisfied with their output.
When you get to dedicated teams and bigger projects, a few key challenges will arise that are particularly relevant to agency environments:
"We need to concept, review, amended, approve, and implement this feature - all within a week!?"
This means quite a significant re-engineering of the teams typical working practices - often developers want something to be completely finished before they start coding, and often designers want to have the final pixel placed before handing over to developers.
You'll find that carefully challenging the team's long held beliefs using the "five why's" during weekly reviews will lead to some innovative and interesting spins on finding ways around this problem. It can become a case-by-case for each story - When can we start to build? When does design need reviewing? How many client stakeholders need to see it? What does design approval mean for this story? How crazy a concept is the Product Owner expecting?
I'll be writing a post that covers this, and other challenges we've faced, and some of the things we tried.
"Where do we start when we don't start with requirements?"
Once you have mastered the process of managing a team, the next big challenge is starting a product or a brief completely from scratch. I'm going to write an entire post on backlog management and product visioning, which can be exciting and daunting in an agency environment.
"You're spending how much in a month!?" (amongst other client concerns)
A team of even two members with a Scrum Master can see money burnt very quickly compared to waterfall. A timeline that used to be 3 months is now 5 or 6 weeks. It can be a lot for a client to see a monthly bill that high (depending on your client obviously).
The client needs to know this, understand the benefits of Scrum and buy in from day 1. Discovering that time really is money can be quite a realisation for some clients, but will make for a much stronger client / agency relationship overall.
How you engage your client is a really important part of success of your projects. This will be the topic of my next post!
