So you want to be an Agile agency? Start with the manifesto.
Stop me if you’ve heard this one: if you want to execute projects on time and within budget that actually deliver value, especially digital projects, your only hope is to adopt an Agile approach. It’s unlikely that anyone who has spent significant time working on digital projects, whether as a developer, designer, manager, or client, has been able to avoid confronting this mantra sooner or later. And there’s a good reason for it, namely that anyone who has spent time in these roles working in a more traditional waterfall framework — with all its up-front planning and documentation — has seen those projects bust timelines, go over budget, and not deliver their intended value. You’ve heard this before because making the case against a traditional waterfall framework is easy. I attended a webinar recently that as far as I can tell was intended as a pitch for adopting agile processes at the agency level, but which spent the entire hour explaining why waterfall projects are so inefficient.
The thing is, I think we get it. I’d argue that most reasonable, intelligent people confronted with executing complex projects intuitively appreciate the alternative that an Agile perspective provides. (It’s not my intention to recap that here, as many have done an excellent job doing so.) I don’t know about the other project managers out there (digital or otherwise), but I don’t need more evidence about why locking scope, budget and timeline together isn’t efficient or ultimately valuable. What I’m most interested in at this point is how to really put those Agile principles into practice in an agency environment, and avoid falling into old habits.
Notice I didn’t say ‘product and project managers.’ The reason for that is I think working with Agile frameworks in an agency environment imposes some significant structural challenges that organizations working on internal products or projects don’t face. Not that product-oriented organizations don’t face challenges — especially if they’re large and have been around for a long time — but I’d argue that any company or organization working on a single product or solely with internal teams that hasn’t explored using Agile frameworks … is a bit nuts. And I’m not just talking about digital projects. Jeff Sutherland’s excellent 2014 book Scrum gives ample evidence that this isn’t just a tech question; it can really be applied to any complex project, and the results are there in plain sight.
But if there’s a lot of consensus around the idea that there has to be something better than Waterfall and all its, er, pitfalls, there seems to be much less consensus on what Agile methodology to follow (Scrum, Kanban, Lean, etc.), and how to transition to its actual practice. (There’s no shortage of people willing to take your money to help you do this though!) And this is where things get sticky for digital agencies, who are often the most vocal and visible when it comes to championing the latest, slickest tech solutions — whether we’re talking about pixels or process. The dirty secret is that actually functioning in an authentically Agile fashion is much harder to do when you have half a dozen different clients with different expectations and ways of working. It’s common to hear something like “the client needs to be entirely on board as a product owner,” to use a Scrum example. But what happens when your client (who always pays well and on time), isn’t on board? Or what happens when you do have a client on board, but you’ve also got legacy clients who expect more of a waterfall process that rely just as much on your resources and team? How do you reconcile the two under one agency roof?
The same kinds of questions apply to the internal teams as well. Often you’ll hear that in order to be Agile you need to find a way to suddenly turn every designer and developer into rule-abiding ceremony-attending participants. But what happens when you’ve got four projects on the go at various stages of production, and team members with ingrained habits and personal process preferences?
If you’re waiting for a panacea for these problems I’m sorry to say I don’t have one to provide. What I can say however, is that it’s not a bad idea to start with the original Agile manifesto. That may not be the most exciting answer (and it’s certainly not the latest and greatest with the manifesto having just celebrated its 15th anniversary), but the best solutions are often the simplest ones. (I think it even says something to that effect in the manifesto’s principles…)
I wish I could say I came to this conclusion before trying a lot of other things and trial and error experimenting, having mastered ‘the art of maximizing the work not done,’ so-to-speak, but that’s not the case. At the agency where I work, it wasn’t until we were on our third incarnation of stand-ups (company weekly, company daily, project-specific daily) that I realized we were effectively applying an Agile approach to implementing Agile. And sure, that sounds a bit meta/cute, but I also think it makes complete sense. If you want to transform into a company that works around Agile principles, why would you then go and make a Waterfall plan to do so?
What I found interesting is that as soon as we started to internalize the actual basic principles of the manifesto, the need for some of the tools and touchstones that the existing Agile methodologies provide started to make themselves apparent organically. It wasn’t long after we improved our stand-ups and communication in general that we started using Trello internally to better track the way we now viewed projects. (If anything we use a process that’s probably closest to Kanban right now, but it continues to evolve.) What began as a modest experiment with a small, self-organizing team on a single project has turned into a tool that killed our antiquated bug tracker, our internal use of Basecamp, and added a whole layer of project management oversight that we never even had before. We use Trello on all our projects now, both internal and external. It’s still a work in progress (and not everyone here loves it), but again, that’s the point. When work isn’t ‘in progress,’ it’s either done, or dying.
But make no mistake, this is not a “Trello solved all our problems” piece. It just happens to be a tool that’s been helpful at this particular stage of our evolution. And we’re careful to ensure that we continue to prioritize ‘individuals and interactions’ over whatever ‘best board practices’ we’ve come up with so far.
We’re far from all the way there, but after a few months of slowly — and yes, iteratively — introducing changes here at Plank, I can say honestly say that even if we’re not a pure-bred Agile agency, we’re a lot more agile than we once were. More importantly, we’re doing better work, and getting it done faster. Now, if only we could get clients to worry more about collaboration than contracts…
Published inThe Agency- curated by Crew. Check us out to get started working with the best designers and developers on the web.
Over 10 million people have used products made on Crew. And over 3 million people have read our blog. Join them here.
