was successfully added to your cart.

Agile In The Agency. Is It Possible?

By 17/04/2017General
Managing Agile projects in the agency

Managing agile projects in an agency setting can be challenging, but it’s definitely possible.

As a Project Manager, you have to be willing to adapt, knowing that the agile process won’t be perfect. But that’s ok because it’s all about individuals and interactions over process anyway.

You won’t always have the time or budget to do daily stand-ups. Some days you’ll have to make do with posting stand up notes via Slack. You won’t have a true product team – with a Product Owner or stakeholders that are fully engaged. Sometimes you will, but most of the times you won’t. It will present challenges and you can’t be too rigid.

That’s the agency agile ground rule to never forget. Don’t be a robot.

At O3 World, we’ve adopted agile methodologies into our process over the last 5 years. We, like many agencies out there, struggled at first with trying to do Agile within an agency setting. At first, it was just a buzz term that clients brought up during the new business process. It was a term that CMO’s heard from their business associates and started putting in RFP’s.

Most of the time though, the people requesting Agile don’t understand the amount of time and people it takes to run a truly Agile project. They’re not willing to pay for time and materials contracts – or commit to more than a few months at a time. We can’t expect those who’ve never built a digital product or website to understand.

That will probably never change, so we started to extract some of the key methodologies from Agile and injecting it into our process. In doing so, we’ve adopted a Scrum-like process that works for us. Here are some of those key elements we’ve been able to incorporate.

Check out:  Put others first

4 Steps To Successfully Manage Agile Projects In An Agency

1. Be Flexible With Your Stand-Ups

Rather than doing daily stand-ups, we tend to do them every other day. 15 minutes. What you did in the past couple days, what you’re working on and do you have any blockers? Our PM acts as the scrum master. Sometimes clients attend, but most of the time they don’t.

2. Start Sprint Planning From Day 1

We don’t start development on day 1. But, we do sprint planning. As soon as the UX / requirements are in a place that the team (and client) feel comfortable with, we can begin development. No formal approval. Each feature gets broken down into tasks and estimated in hours. This mitigates risk because we can tell every sprint if we’re on track or not. While we don’t release a feature at the end of every sprint, we do demo our work. Our PM’s again run sprint planning, with the full project team involved.

3. Define Requirements To Keep The Team (And Client) Aligned

Because there are clients involved, we do need requirements. We use our Wireframes and Functional Outlines as the basis for the requirements. While they evolve throughout the life of the project, they’re important to ensure we’re on the same page as a project team.

3. Create A Backlog And Prioritize With Your Client

Our PM’s own the backlog and prioritize it based on the project scope and clients needs. All backlog cards include user stories. We work with our clients to prioritize.

4. Don’t Forget To Demo And Run Retrospectives

At the end of each 2 week sprint, we do demos and retros with the product team. Again, sometimes the client attends. Most of the time they don’t. Retros are extremely important to continue improvement and fine tuning the process.

Check out:  10 tips for project success: stay positive

It’s all about being flexible, involving the entire project team from the start, and overlapping design and development to gain efficiencies and increase collaboration.

How To Manage Agile Projects With Fixed Budgets

The biggest question we get is, but how do you do this without a true product team and T&M budget?

The way we handle this is by doing a T&M with a maximum number. We estimate our projects and provide a range of hours/pricing based on that. The range accounts for the finite details in that scope, stand-ups, meetings, etc… It’s a range to account for the typical project changes that happen on every project or some relatively low-risk unknowns at kick off.

There is no way to know how many screens need to be designed at the beginning of a project. Or how many rounds of revisions a client might need. By providing a range we give our Project Managers the flexibility to run an Agency Agile process, while not straining the client relationship by holding them to a strict scope. Any major changes to the scope outside of the range will result in a Change Order and we try to identify them upfront (major unknown 3rd party integrations are the typical one). But, the minor changes no longer cause delays and stress for the relationship.

We keep our clients updated on those hours with weekly burn reports.  By taking the best qualities of Agile and injecting it into an agency setting, you can achieve the efficiencies that people love. A little bit of flexibility will go a long way in your client and internal relationships.

Check out:  When you are about to tell the client you are going to be late with a deliverable, but they email you first and tell you that the launch date was pushed

As a Project Manager, you can run the project the way you want. You can give a little to improve your relationship with your client, while still holding them to the same approvals and process we’re used to.

What do you think?

Have you had success managing agile projects in your agency?  How did you make it work? What do you find works, and what doesn’t ?I’d love to hear how you do it.

Justin Handler

About Justin Handler

Justin Handler is the Head of Accounts at O3 World, a digital product design and development agency in Philadelphia. Justin has been instrumental in forming the O3 project processes and has lead the management of diverse projects, including enterprise product builds, mobile applications, sales tools, eCommerce websites and much more. Justin brings over 9 years of experience in project management to inform his expertise in managing the O3 team of Project Managers and overseeing high-level strategy for all clients.

16 Comments

  • Jesse says:

    Hey Justin. I think these are great tips – many of which our agency has also adapted in a similar fashion. How do you typically handle clients when they say that they need a fixed cost though?

    • Hey Jesse,

      Thanks for your question, it’s a great one. It’s pretty common that our first engagement with a client is requested to be a fixed fee. That said, we begin setting expectations pretty early that future work will not be setup like this. I try to reference situations from the fixed fee project that aren’t great, such as a PM having to say “no” a lot more than we want in order to conform to that scope. It definitely takes some trust, and proving to that client that it’s mutually beneficial. After doing one t&m type project, and seeing the level of transparency, as well as flexibility for their scope, they’re usually very satisfied with the structure.

      Happy to continue the discussion if you shoot me an email.

      Thanks!
      Justin

  • Heather B says:

    Hi Justin. This is good perspective on what I think you have rightfully called out as a buzzword that has been crammed into RFPs for too long. One thing I struggle with is explaining that we can’t do the whole process in this agile-ish manner. We still do discovery and design work as part of a waterfall project plan, since we do tend to need approval on one before the next can begin. Do you also only work in an Agency Agile approach during development?

    • Hey Heather,

      Great question. We will do Discovery as it’s own process because agile really doesn’t make sense. That said, we will do our agile process when we get to design. We try to let design get 1 or 2 sprints ahead of development, even though it’s against the book. We had to adapt to what worked for us. Personally, I prefer to have a good amount of the UX and requirements before starting those development sprints. Even if they’re not entirely “approved” they should be far enough along that starting development gains efficiencies rather than re-work. Once Wireframes and requirements are in that spot we’ll start our dev sprints. Then, the remaining UX and UI get worked into those as well.

      Happy to continue to conversation via email.

      Thanks!
      Justin

  • Danie says:

    Hey Justin,

    Some notes from how we implement this. We tend to take the exact same approach but manage to speed things up even more. We start backend development as soon as the technical docs been approved. Tech doc and Wireframes happen at the same time the former normally much quicker. Which allows us to start design and backend dev almost same time or earlier. By the time we start with the frontend (viewport) work we are far enough with design and backend to actually start trowing things together. But this all depends on scope and client feedback as you can imagine.

    Easy,
    D

    • Thanks for the comment, Danie. We’ll do the same thing if the situation to expedite work presents itself. We often will do a dev “sprint 0” which allows us to start some of our back-end work before getting to heavy into feature development. Same thing with us, if the tech docs are approved we can get rolling.

  • Jason Ojukwu says:

    Great article and some very useful insights. Will apply and see what happens.

  • This is one of the few articles I’ve found that speaks to agile for agencies–Great job. Curious how you guys handle running multiple agile teams from a single resource pool, and how you’ve adapted forecasting. With waterfall you know how many hours of X person you’d need, but with agile it’s only a weekly forecast.

    • Thanks Justin. There’s a couple ways we look at this. 1) Ongoing Retainers – We understand what resources and how much time can be allocated for an extended period of time. This allows us to forecast out even more than week in advance. 2) Singular projects – This is where your question gets tricky. We treat these as hours based as well, so we are able to forecast out the work. But, it can get tricky as things shift week to week as you’ve noted. It takes a LOT of collaboration on the Resource Plan and flexibility from all parties involved. Another key point is that while we do our best to keep the project team together, sometimes people have to tag in and out of projects in order to lend a hand. It has increased our collaboration and allows multiple people to assist on projects.

  • […] lá! Este artigo publicado em inglês revela a experiência de uma agência americana na implementação de princípios ágeis. Veja, […]

  • Jean-Luc says:

    How do you handle clients, that “live” the waterfall and request milestones for the project from the very beginning – maybe to match their own internal plan?

    • Hey Jean-Luc, thanks for the question, it’s a good one. Milestones are totally fine in our process. We can provide those up front, but I always set the expectations that dates are tentative. I let them know that there are factors that can change those dates: response times, feedback loops, approvals, etc… I’ve found that as long as I set those expectations and provide updates on those milestones in our weekly status calls things generally run smoothly. If there are major milestones we cannot miss, then those become the dates we work backwards from. It gives me leverage as a PM to backlog requests and hold the client even more accountable to fulfill their side of the project. If you have any more questions feel free to email me at handler@o3world.com.

  • Matt says:

    Great article on running agile in an agency. As a DPM that has worked in agencies attempting to both sell agile as a buzzword AND attempt to legitimately pair the approach to the right project, it always has it’s challenges.

    The biggest challenges I’ve found:
    – Finding the right work cadence when team members on a project are often “time-sliced” and working on multiple projects.
    – Effectively communicating and getting buy-in from the client that they have bought into a framework that will provide the flexibility to deliver maximum value (and not to a list of finite deliverables defined on the front end of the project).
    – Getting clients to commit to the “overhead” of being more actively involved in the process.

    In my experience the sales process is an extremely critical time to both determine if the client will be a “good” agile client AND set expectations for the working relationship.

    Great post and thanks for sharing!

  • James Birchall says:

    Hi Justin,

    I think the Agile process works best when you start right at the very first part of the Business Development cycle and go from there.

    What do I mean by that?

    IMHO, the key to agile is to break projects down into doable increments.

    There’s no reason the PM process only has to start once the contract is signed and the requirements have all been negotiated and there’s nobody left to deal with except the developers. In fact, if that’s the process, I don’t think they’re reaping the benefits of Agile at all: they’re doing something called, “Watergile” – which just dresses up the implementation phase of Waterfall with Agile paraphernalia.

    Instead, as soon as there’s an RFP/Quote to bid on, start putting epics on the board, estimate and order them.

    Your first project sprint is the “Response Sprint”.

    The deliverable of the “Response Sprint” is to get the response documents together and out the door to the customer. The architects should be breaking down your bid into priceable pieces (ideally, using SKUs from your product list that are doable by a person in a single sprint’s time) and each of those deliverable line items is an epic. The order and intensity that you propose to do them in is your prioritised backlog, proposed team structure and initial project plan.

    If you’re a well-tuned shop, the SKU’s on your pricelist used to pitch will be based on average durations in your agency’s past. If you do that, you’ve “pre-estimated” how long each epic will take and there’s much less guesswork in the response (BTW, the purpose of “prototyping” is to create a cost structure and details for a new SKU).

    The rest of the game to delivery is just iterating on that as the team learns more about the problem and the client and things change.

  • Justin Handler says:

    Thanks James. That’s a really interesting way to approach projects from the get go. Ultimately what we’re doing at O3 is not strict Agile by any stretch. It just wouldn’t work based on the setup of our agency and clients. But, we do what works best for us. I’d totally be down to try this approach to new business. Would be a great way to get clients comfortable with the process. Thanks for your insight.

Leave a Reply