Get certified - Transform your world of work today


6 Ways to Make Using Agile on Client Projects Easier

Top tips for agencies practicing Scrum

13 August 2015

Jim Bowes
Manifesto Digital

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.

At Manifesto, 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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 5 (1 ratings)


Robert Day, CSM, 8/18/2015 10:08:15 AM
All good points, Jim.

I'd bet that we've all often had a client (internal or external) who hasn't got the point of Scrum, and who's asked "Why are you going to deliver the project in stages when we won't be able to use it until the last stage is delivered?" (In other words, "Why aren't you using Waterfall?")

To my mind, the best answer should be:

"1) This way, the product can be incrementally tested so that when it's deployed, you can have certainty that the functionality has been thoroughly tested before you start using it. *
2) You'll be able to introduce key users to the application in advance so that it doesn't come as a total surprise to them on Go Live Day and they'll be able to think about how it integrates with legacy systems."

* Which of course implies that the UAT will actually be done by your client or someone taking their role. And it also should not be taken to mean that the product will be 100% perfect on Day One, because no software product ever is. Nothing survives first contact with the Real World unscathed!
Oscar Correia Junior, CSM, 12/8/2015 7:22:53 AM
Hi Jim Bowes, congrats for your article, is a material very good and dont fing this kind of explanation in none agile book.
Meghan Robinson, 3/17/2016 4:14:49 PM
Would you be okay with us highlighting this article on our new AgileCareers Blog?

You can view the blog here:

I look forward to hearing your response! Thanks.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up