The purpose of this whitepaper is to provide a simple roadmap and some of the key questions that one should be asking about Agile when discussing with clients, especially when the topic of “doing Agile together” is involved.

Many of these same questions are useful in agreements with vendors or subcontractors, but they are not the focus of this paper.

It’s an exciting moment when the Client actually asks for Agile to be part of their big project.  As impressive as the gains are from adopting Agile within an Agency – operational and financial improvements well into the double-digits – things can get even better when the Client is engaged and embracing of Agile as well.  It’s really them saying, “…let’s work more closely together.”

But as you might expect with new business practices involving a Client or additional parties, things will get more complex as you enter into the dance.  And it turns out that the complexity is not so much from learning how to work together, but really lies in simply understanding what each party means when they say Agile.

I was struck the other day by the similarity of this situation to an experience I had while running a large multi-national development project.  We had a huge list of issues that we were managing with our European partners – old-school style we passed this list back and forth across the ocean and then met every three months to hash out the ones that we couldn’t solve through email.  There was an issue our US team felt had become redundant – because it was dealt with in another issue, and despite the wording being very different, we didn’t need two of them, did we?  We marked it with the comment, “This issue is moot”.

Fast forward to our in-person meeting in Paris, where toward the end of the third and last day, my British counterpart noted that we still hadn’t discussed that issue.  “The one that you agreed was moot?”, I said. “Yes, let’s discuss it now while we have time”, they replied, “we agree that we do not agree on this issue….”

My head started spinning – international projects are like herding cats at times and re-opening issues is a procedural no-no.  “But you agreed that it was ‘moot’?”  We all paused and realized at the same time that “moot” might not be commonly understood as a term (this seemed to happen more often with the French, but that’s another story).  As it turns out “moot” in the US means “something that people might want to academically debate, but not worthy of discussion here or now”.  In the UK, it means “needing or worthy of debate”.  A “moot” is an academic debate, we both agreed, but obviously we differ as cultures as to the value of academic debates!

Well, “Agile” is a lot more nebulous and nuanced of a term than “moot” is…so when we use it in a discussion, we need to be very attentive to what is truly meant.  Since Agile affects the culture, processes, people and tools, it touches virtually every aspect of agency operations.  And when a Client asks: “Do you guys do Agile?” it may not be entirely clear what they are asking.  More so, when they ask: “Can we do Agile together?” even more caution and understanding is needed before answering the question or building it into a proposal or contract.

For the purposes of this discussion, we’ll assume a Client is asking you to do Agile with them, and that the project is large enough that it requires that both you and your Client provide Teams or team members.

Understanding How the Client is Applying Agile

  1. Does the client actually use Agile now?  Often the client wants to use Agile, or has used it in previous jobs, but really isn’t doing it now.  They might be hoping that you’ll show them how or help them get to the next level.  If they are using it, like many agencies, they may only be using it for development, not creative and other disciplines.
  1. What phases of the project lifecycle do they use Agile in?  A simple model for this is:

– Phase 0: Discovery, Strategy, Concepting

– Phase 1: Design and Build

– Phase 2: Deploy and Maintain

Agile can be applied to all three of these – which ones do they use it in?

  1. Related to this is the question of how much cross-functional integration they expect and have experience with: are disciplines like strategy, creative, design, copy, information architecture, analytics, and search integrated with development and test resources?

If the answer is “no, not at all” then they are not really doing Agile, and more likely, they are used to or using what is called “scrummer-fall” where creative processes are done in one cycle and then the artifacts passed to the development process for the next – essentially a waterfall iterative process.  This is easy to do, actually, but you don’t necessarily get a lot of the Agile “bang”.

  1. How does the Client manage Agile within their environment?  Do they have an “Agile PMO” that coordinates the teams both internal and external?  This is an important coordination and governance function in multi-team Agile – if they don’t have one, then you’ll want to make sure that you put one in place.
  1. Assuming that this is a large project, multi-party considerations come in: do they have other vendors (back-end, 3rd-party integrations, etc.) or other autonomous organizations (corporate IT) that they coordinate their Agile projects with, and how do they do that?  Effective cross-party integration is key to “Phase 2” success: how do we actually get the project live and in production?
  1. Likewise, the Client may have numerous agencies that they work with.  Branding agencies are commonly involved in large website rebuilds, but the whole customer experience lifecycle is fair game, with social, direct response, and even traditional roles (media) need to be folded in to achieve success.  How is this function managed in an Agile frame?

How Will This Be Contracted?

This is an incredibly complex topic and drafting an effective Agile contract is a nuanced dance between traditional expectations of the Client’s procurement and legal staff. I once spent a month in “discussion” with the Client’s lawyer on a single definition of what constitutes “change” in an Agile frame.  But there are things you should ask before even starting in on that journey. Here are a few:

  1. Will the contract be structured so as to include Agile delivery concepts?  Will there be sprints/cycles, backlogs, reviews, etc.?  This is probably the most important question and will give you a sense of whether they really are embracing Agile or just phased-waterfall (scrummer-fall) where you still have to provide all wireframes, comps, get reviews and signoffs, and get paid on traditional metrics.
  1. How will they contract collaboration?  Some of our clients are surprised at this question: most agency contracts are devoid of collaboration models – it is very hard to write collaboration into a contract without the Client taking responsibility for directing this collaboration…something that many Clients do not do well.

If you’re going to be working with other agencies, vendors, even the client’s own resources, how will collaboration be described and managed?  Without strong collaboration, Agile can be very hard to do.

  1. Who owns scope?  This is the “keystone” question for Agile contracting.  In “classic” Agile, the Client should own scope on an active basis, and the Agency should be building what both parties agree is best to build in each cycle.  In many ways it is easier to not have this be the case, but if the project is large and multi-faceted, the project will be more successful if the client actively manages scope and coordinates this scope across the Agency and its other partners and stakeholders.
  1. Ask a simple question: have they written an Agile services contract before, and can you see it?  This will tell you a lot.  If it is very different from what you’ve seen in terms of scope, change order, etc., then it is probably a real Agile contract.  And it probably means that they have an attorney (and a procurement function) that understands how to do this with you.

Getting Started

Agile projects usually start with a product, program or project backlog – a list of features or stories that reflect all of the things that could be built during the course of the project (and beyond).  Regardless of whether the Client or the Agency owns the active scoping of the cycles, there needs to be a common view of the project, in greater detail than the SOW, that all parties work from and frequently revisit.  Here are a few questions that you should ask around how to get started:

  1. Is there a program roadmap? If it exists, can we see it or get briefed?  If it doesn’t yet exist, when will it get made and by whom?  Can we be a part of that activity?
  1. How will backlog prioritization – the choosing of stories for near-term execution – be performed?  This is also called “backlog grooming”, and is best done as a multi-party collaborative activity.  Everyone should understand the backlog.

Once We’re Moving…

There are many considerations that one must deal with when coordinating Agile in a heterogeneous team environment (the teams are owned, managed, etc. by other parties), but the big ones have to do with how we make sure that everyone has a common understanding of the three main stages of the Agile cycle: Cycle Planning, Cycle Execution and Cycle Review.  Here are a few key topics:

  1. How will Cycle Planning be performed and coordinated in the multi-team model?  There are techniques like “Scrum of Scrums” that apply to execution activities, but getting the cycle started and teams all synced up is even more valuable – what is the “Plan of Plans”?
  1. At the end of the Cycle Planning, how will team capacity be determined and by whom?  This can also be a contractual issue in how the agency’s team performance is monitored and incented during the course of the project.  Will the “promise” and “stretch” objectives be established jointly, through a formula, or how?
  1. Who is our Product Owner (PO) and what interaction model will we be using during cycle execution?  The product owner is a key role in an Agile project, basically the “voice of the customer/market”.

In software Agile, the PO will often be physically located in the room with the team, actively reviewing items during cycle execution as needed.  And the other extreme can be highly functional as well – the PO is present at the start and end of the cycle, but only rarely involved during execution.  The answer to this question has bearing on the question of who manages scope – as you can imagine, an omnipresent Client-PO sitting in the room with the team can be incompatible with Agency-owned scope.

  1. How will cycle reviews be conducted and what does the Client’s internal feedback cycle look like?  The Agile review process is designed to gather feedback in a flexible and highly-efficient way.

If the client has an extended review process (needs 2-4 weeks to review with other stakeholders, agencies, and executives) you’ll want to know that and adjust accordingly.  It may be that you want to re-engineer the review process so that it is more inclusive of these other parties…which probably means that they should be involved at some level with the project backlog its grooming.

In Summary

There are many more things you should be considering, but if you are able to gain understanding in the areas listed above, you’ll have a good sense of what they mean when they use the word Agile:

  • How they use Agile and how they integrate it into their development lifecycles, functional teams & partners, and their own platform and organization.
  • How much they embrace the shift of control, risk and communications that Agile benefits from.
  • How they start doing Agile for a project, and how well they understand the current scope.
  • How they expect to work with you during the cycle processes: planning, execution and review;

All of this may sound daunting, especially if your agency is doing a good job of keep-it-to-ourselves Agile.  But the potential of a well-executed collaborative or large-scale project should outweigh these challenges. As a result of your successful project, your client will feel like you’re even more of a partner in their success, and will have built strong bonds with your team and agency.  That means you’ll be together for a while – really what both of you are looking for.