Making Agile work for the client

Working Agile in the client-vendor context is not always an experience filled with joy and achievement. It can be daunting, frustrating, expensive and unrewarding - as much as it can be productive, useful, involving and successful.

Working with Agile with internal teams can be challenging enough, but if there’s buy-in from all parts of the organisation, it can be truly awesome to be part of a functioning Agile team. I have seen the results of our coaches working alongside teams to create smoothly functional and effective teams. Effective Agile can revolutionise your workplace - in a good way - if you let it.

However as a client, or Product Owner, even a client who knows what it is and has worked Agile before, working with an external agency has numerous challenges, particularly for smaller (3-6 week) website projects.

I have been the Product Owner for numerous projects over the last few years, ranging from large (up to nine months of development) to very small (four weeks) and I’ve encountered a range of issues, some of which I’ve gone into a bit more detail with below. I’ve also started a checklist - some of the key things that you as a client should consider when you’re about to embark on an Agile client-vendor project (see end of this post).

Their expectations of you - the client

Availability

Presumably you’re not working onsite with the team. So you won’t be privy to the various discussions that happen throughout the day about your project. Be aware that your availability is an important factor in determining the success of the project. With Agile you don’t toss your requirements over the fence and wait to see what comes back, you’re in there as often as possible, keeping up with what’s going on and making decisions constantly to keep things moving.

It will also be your responsibility to make sure the product backlog is in a good shape by writing user stories and giving direction throughout the project.

When you get started, be sure to have a conversation about how much time you’ll be required to put into the project and at what points throughout the sprint you will need to be present - either physically or by Skype. Be sure to book these times in your calendar and give them priority. If you can’t make it, let them know.

If you aren’t available to the team you will lose touch with the project, impede progress by not making decisions in a timely manner, and make it impossible for the team to succeed.

Communication

Aside from the standup meetings you attend as well as the sprint planning and retrospectives, there will be times when the team needs you to answer questions. Be clear with them about what kind of communication works best for you. If you’re already inundated with emails, make sure they know that you’re not likely to see their urgent requests for information if they email you. If you are always on Skype, let them know they can IM you a quick question. Or if you prefer a quick phone call, do that.

You will also require updates on progress to pass up your chain of command (if you have one). Set the expectations for this up front, have a conversation about what kind of detail you require in a report. Set goals or milestones or dates that work for you.

Knowledge

If you have not been a product owner before, or have not even worked with Agile before, it’s going to be important that the vendor provides some clear guidelines for what is expected of you in this role. Or you could upskill yourself with a Product Owner course (here’s one we prepared earlier).

You need to realise that this is not a way of working that you’ve experienced before. You’ll need to be a lot more present throughout this project, you’ll need to be part of the team and you’ll need to undertake a fairly steep learning curve about what Agile is and what it means for you.

The agency needs to be sure not to make you feel like an idiot, not to imply that their bad practices are in any way your fault. But you’ll need to be aware enough to see that coming.

The other kind of knowledge you may be lacking (through no fault of your own) is about technical literacy, or how website development works. I can’t stress this enough, but if you don’t know about a particular aspect of the project - say so. If you need further explanation - ask.

There will be assumptions about functionality or aspects of the site that you have not directly specified and which may not be clear to you at the time. This may come out down the track when things don’t work quite the way you expected them to, at which point getting things changed may not be as simple as it could have been.

The way they work

As we have all experienced, everyone has their own interpretation of what Agile is or how they choose to work with it. As a client going into an Agile project with an agency, it’s important to understand how they are going to run things. If you’ve worked Agile before you may find that this agency has a different approach. Chances are you’ll have to work the way they do, but if you’ve got different ideas, talk about them up front.

Some agencies will approach your web project as a partnership, together you’ll keep an eye on the big picture, leave room for creativity, trial and error, and doing the right thing. In these cases your outcome will evolve into something that is likely to be better than you could have imagined. The collective wisdom of the team works in your favour.

Some agencies take a more factory approach to their Agile practices. They’ll do what you ask, run Scrum by the numbers and be strict in their application of how things work. In these cases you might get what you asked for, but you don’t get the collective wisdom working for you, there is a lot more pressure on you to have all the answers ready, and when it goes wrong it’s your fault.

You will have a hard time knowing up front which kind of approach your agency takes. So ask for references, ask other people they work with how their experience has been, and be specific about the people you have on your team. You will need to get on with them, you’ll be working together - a lot.

The makeup of your team will also influence your experience. If your project is small you might just have one or two people on your team - if those people are devs they might do a great functional job, but will they suggest alternative options to you, will they keep the big picture in mind?

The contract

As a client who understands how Agile works I get that a contract can be tied to a budget, or a timeframe, or scope - but not all those things. As a client who works in Government I have a pretty hard time convincing my powers-that-be that this is normal and OK and it will come right in the end. But this is what the client needs to accept.

One common approach is to tie a contract to a number of sprints, which equals a timeframe and an amount of money.

The agency needs to understand that the client, particularly in Government (but also commercial businesses), will have allocated a finite amount of money to the project. If that project needs more money for whatever reason, there’s a long and complex process of getting more budget allocated. It’s important that the agency provides the client with tools for this process (ie sound justification in business language), because what usually happens is that Agile gets the blame and the client will have a hard time convincing people otherwise.

----

These issues will not always come up, and things will go wrong on any project, some of these are quite frankly a result of bad practices within the agency. But as an agency it’s important to know that the client has to come with you on your journey, that they’ll have their own pressures, limits and expectations, and you need to be aware of those throughout your relationship.

For Agile as with any project, a good relationship between client and vendor is one that has clear communication and trust. Competence helps too.

Checklist for Product Owners / Clients

Availability

• Are you able to be at the daily standup, even via Skype? Will you be available for sprint planning meetings? Do you have time to continuously write and refine user stories?


• What kind of availability do you expect from the scrum master, or the team - if you have questions?

Communication

• How are they going to be communicating with you throughout the project - phone, email, skype?


• How quickly do they expect you to respond?


• What kind of information do you need for your reporting requirements?

Knowledge

• Will they upskill you, be clear about what your role involves, forgive you a learning curve?


• Can you take a course, read a book, upskill yourself about Agile and what it means to be a Product Owner?


• Where are the limits of your technical knowledge - are there people on the team who will explain things to you, can you trust them to be clear and honest?

Way of working

• How does their process allow for creativity and imagination, particularly in early stages?


• How long are their sprints, how do they approach stories within each sprint?


• Who’s going to be on your team?


• Is your vision clear - to you and the team?


• Is someone there who will suggest options to you, propose new ways of doing things, alternative solutions - or will they just do as you ask.

Contract

• What is the basis for pricing the project?


• Will there be a cost/sprint, is it time and materials based?


• What happens when the money or time runs out and the main goals haven’t been achieved or there is more critical work to be done?


• How are bug fixes handled?


• How long will bugs be fixed for?


• How will you manage disputes?


• Who’s paying for the launch party?

Finally, good luck!

Being a client working with an Agile vendor can be a great experience. There are many influencing factors, including which agency you work with, but hopefully armed with some preparation and clear expectations you can enjoy the experience and have a successful project! It is possible :)

What experiences have you had?

What else should go on this list?