How to make agency Agile work — for you and your clients

Lessons learned from executing redesigns sprint by sprint

After publishing an interview about our Scrum-based process at Upstatement with one of our awesome clients (Harvard Gazette), I thought it would be helpful to write up a more detailed appendix for the Agile devotees out there. We’re often asked by these folks to get specific: When applying Scrum methodology in an agency setting, how does it actually work?

One personal disclaimer is that I am not an Agile/Scrum diehard believer. I arrived at Upstatement when the company was coalescing on switching from waterfall to agile framework, so I dove in to learn and helped make adjustments accordingly . But as time has gone forward, I’ve wished for longer periods for focused work (2 week sprints can be stressful) and more of a long-term plan for our projects. We’ve adjusted accordingly and continue to make smart exceptions. Since Scrum was designed for continuous software development within internal teams, we’d be destined to fail if we went by the book.

But otherwise, here it is — our scrummy secrets exposed! After a few years, we have settled on some trends in the process:

Core principles we follow:

• Work in small, multi-disciplinary, self-organizing teams. Typically our teams are comprised of a creative director, a producer, a designer, and engineer — and sometimes supporting designers and engineers as needed.
• Have short, daily standups to report what each team member worked on yesterday on, plans to do today, and if they have any blockers.
• Design and build in short, two-week cycles. This cadence feels just right to us, providing enough time to think through big problems and make meaningful progress. Rarely, we’ll adopt a one-week sprint cycle if a project is particularly short or has unique feedback constraints. One week sprints are hard (lots of meeting time and less heads-down work time), so this is a lever we pull very occasionally.
• Deploy and test as we go. We respond to feedback and fix bugs along the way to avoid a giant pile of tech and design debt at the end.
• Do quick velocity point estimates so we know the relative size of each task and what we can reasonably accomplish in a sprint. We use the Fibonacci sequence, but we don’t generally use an estimating deck of cards — I personally find them a little pedantic and goofy.
• Track priorities and tasks in on a Kanban board so the team always knows what to work on next. We use Trello, and when it comes to columns, we’ve got the classics: Product and sprint backlog, in progress, for review, and accepted. Many projects also have a “bugs” and a “to be prioritized/icebox” column for when the product backlog is a particularly long beast.
• When a sprint is planned, it’s locked. No new tasks come in. We’re not 100 percent religious about this rule — occasionally we’ll accommodate mid-sprint feedback if it’s efficient and helpful, but it’s a good expectation to set up early on.
• MVP, MVP, MVP is our mantra, especially in early sprints. We work hard to define the simplest version of each feature with our clients, starting with broad and basic coverage of what is absolutely necessary and leaving designy tweaks or nice-to-have enhancements toward the end. This is a big communication lift, which is why our clients are in Trello and Slack with us every day — no weekly status emails around here. One tactical piece of advice I can give on this note: Avoid starting with the homepage design of a website. Work from the inside out (article pages and components) to build up functionality while avoiding the political, emotional thicket of a homepage.
• We deploy functioning code at the end of each sprint (and only then) No hot fixes on production. We make an exception after/around a launch, when we set new deployment expectations: usually once a day, and no more.

Our Agile adaptations. (…Agiletations? No?)

• Our Orientation and Research & Strategy phases don’t follow the sprint process at all. Every project starts here, and these weeks are organized loosely waterfall style, with some fairly known steps and deliverables planned along the way.
• The Product Owner comes from the client team because they know the project and priorities best. This probably creates the most trickiness around the true Scrum method because we can’t guarantee how involved or educated our Product Owner will be. But we do a lot of education around the role — setting up expectations of how much time it will take, subsidizing Scrum training, and doing our best to advise on how to make this process work. The client Product Owners are named in our contracts.
• We do design comps — lightly True Scrum doesn’t account for the politics and emotional balancing act of redesigning a website that is very special to a large group of people. We avoid the velvet curtain reveal of pixel-perfect design comps by conducting mood boarding exercises and developing high-level look and feel during the vision phase. Once sprints start, we move into code very quickly, but sometimes more sketching is necessary. We essentially only make flats to nail down content hierarchy, define general look-and-feel, or quickly get buy-in on a tricky topic — and this is usually confined to the first sprint or two.
• Sprint priorities are determined by the whole working team. Our clients are experts in their internal priorities, but they’ve hired us to be experts in website-making. So while they’ve set the big picture priorities, we make heavy recommendation on the work we tackle from sprint to sprint. This is always up for discussion with our client Product Owners, but it diverges from true Scrum where the product owner alone determines priority. Our process is much more collaborative.
• We are not extremely formal about our backlog and acceptance criteria. For example, in sprint review, we quickly demo and talk about each and every Trello card in the “for Review,” column but they aren’t plotted to highly specified pre-planned user stories. However, we do browser and accessibility testing as we build each feature, and we always spin up new cards if our Product Owner wants to accomplish more before calling the task complete.
• We don’t create burndown charts. We tried it, but none of the automated tools worked that well for us, and there were always some human elements to explain about how the chart was looking. Sometimes, a burndown chart can cause alarm where no alarm is necessary — or vice-versa. Our producers (like me) do the work of keeping an eye on sprint progress and reporting it out. Too much documentation is annoying.
• We don’t write everything in the form of a user story. We used to try, but it got so crazy and obfuscated that people didn’t actually know what they were supposed to be working on. It is annoying to write “As a user, I want to sign up for the newsletter, so I can stay up to date with this company” when we know the task is really “integrate mailchimp form” Importantly we are definitely still very user-focused in our work, and try articulate our tasks as such. For example, if a client asks “can that button be bigger?” We dig deeper to find out why, and might end up writing a card that says “Explore ways to increase clicks to email signup” if it’s a core user action.
• We have weekly mid-sprint check-in calls, and often provide a peek behind the curtain to show in-progress work. These mostly help us answer questions we’ve encountered since our Product Owner isn’t in-house, but they also relieve the tension of seeing fully deployed work only once every couple of weeks.
• We have no sprint retrospectives or formal Kaizen cards because we’re wary of too much process when we’re on the clock and like to have our heads down working. We always try to get better as we go, but there’s not formal structure around it. Also, no Predicted vs. Actual velocity estimates — again, it feels like extraneous process that doesn’t yield enough real value.
• We’re on a timeline. Scrum is designed on infinite internal product management, but we sell our work in a time-and-materials style contract. Our clients buy Upstatement’s expertise for a set number of weeks, so the sprints are on a ticking clock. We sometimes mitigate that by sketching lightweight sprint themes (for instance: Focus on articles in Sprint 1 and recirculation in Sprint 2), but otherwise we just basically stop working on the backlog at some point. And yes, that is hard.

Our version of it, anyway

There are plenty more details, but that’s the highlight reel. I’m eager to hear from folks practicing a version of Scrum in a similar setting, or folks who want to rip me apart/provide suggestions to the process we’ve landed on. Part of why we love the Agile approach is because it bakes in adaptation, and we can learn as we go. Let the sprinting continue!