Most of my career to date has been spent within organizations, and for several years much of my time has been spent building, running, or coaching Scrum teams. Since starting an agency three and a half years ago, we've needed to apply Agile principles and Scrum to client projects.
Using Agile methods on client projects should be a win-win, but to succeed, agencies need to understand that clients don't always come with extensive knowledge and experience. Just understanding the difference between Agile principles and Scrum as a framework is an important step.
In this post I'm sharing six things I've learned that should help smooth the transition to collaborative creation of more valuable products in an agency-client relationship.
1. Explain it
This sounds obvious, but a lot of problems arise from the fact that clients just don't understand Scrum as a way of working, and therefore they have no context in which to place your sprint demos, requests for stakeholder involvement, or working software.
Before starting an Agile project, you should ensure that the client understands both Agile and the particular framework that you'll be using (for us, normally that's Scrum). If they don't, then the onus is on you to help them develop a clear picture of how you'll be working and what level of involvement you'll expect from them in order to make the project work.
, we kick off every project with a discovery phase during which we learn everything we possibly can about the client, their users, and their business needs. But that's not all that's going on during this period. We're also introducing the client to our way of working and helping them develop confidence that the methods we use will deliver the value they're looking for.
Getting off on the right foot here saves a lot of potential pain later on.
2. Create a clear vision
As well as a shared understanding of the method, it's also vital that you and the client have a shared understanding of what you're building. Without a clear vision for the end product, it's likely that different actors within the development effort will end up hampering rather than helping each other.
I've mentioned it many times before, but Roman Pichler has devised an excellent method for developing a shared product vision via the Product Vision Board
. It's a simple yet powerful way of aligning everyone's thinking, teasing out differing views, and defining the greatest benefits/challenges/risks of a project.
3. Know why you are using an Agile method
The point of using Scrum isn't to be Agile. It's to deliver more value to the client more quickly than you would using traditional software development methods. If you're obsessing with trying to "do" a specific method rather than focusing on delivering value to the customer, then you can no longer see the forest for the trees.
Which leads neatly to…
4. Be a pragmatist -- inspect and adapt
Agile methods like Scrum give a framework and some practices for how to conduct your development projects but leave you plenty of scope to find your own ways of working. The reality is that your relationship with your client consists of many shades of grey. It's a living, breathing thing, and inevitably it's messy and hard to encapsulate.
It's important you use the tools Scrum gives you (such as the retrospective) to help create a pragmatic approach to delivery where ongoing improvement is a focus.
When it comes to obeying the structures and guidelines of any particular method, it's important to remember that their purpose is to make for a better client-agency relationship and better software.
5. Have an Agile contract
I've been to quite a few Agile for Agencies meet-ups, and this question arises time and time again: How is it possible to draw up a standard contract when you're delivering with Agile?
Often a contract specifies a list of deliverables, whereas Agile means that you're striving to deliver as much value as possible in a set period of development. This can obviously cause problems when, even though the project has been successful from a value perspective, not all the features certain stakeholders requested have been delivered.
The answer is twofold. First, effective communication of the value delivered is crucial. Second, you should not try to fit into the template of a standard contract.
It's a learning process that will be different for every agency, but it's imperative to come up with a way of concretely describing what you're delivering without explicitly contracting for specific features (this is, after all, one of the original tenets of the Agile manifesto).
On the plus side, this forces you to have those conversations with the client about exactly what Agile is and how you'll be working before any work is undertaken.
6. If you can tell it won't work, don't do it
We've all been there. You know this particular client just doesn't get your agency or the way you work. But can you walk away from a contract this big (or strategically/personally important)? Yes. Yes, you can.
If you know it isn't going to work out, then walk away -- you'll save yourself a lot more pain than you'll get from leaving the revenue on the table. Not only do failed projects take up a lot more time and energy than the headline price accounts for, but leaving them behind means you'll doubtless free up your agency for work of a more lucrative and fulfilling nature.
Possibly the hardest lesson to learn, this one, but it's definitely valuable.
Successful client-agency relationships are built on foundations of trust and mutual understanding, no matter the method you'll be using to complete the work. If you put in the time and effort up front to make sure you and the client are entering into the project with eyes open, a clear product vision, and reasonable expectations of each other, then everything that comes after gets a lot easier.