How do you manage projects now?
I don’t know about other agencies, but we’ve always struggled with project management. From a resourcing and software perspective, there’s a ton of choice out there. You need only look at the near bi-weekly ‘What PM software should I use?’ threads in the HubSpot Partner LinkedIn forum to get a sense that many agencies are still trying to figure this out. And, from a pure software perspective you have tons of choices. Of course they all work a little bit differently, but apparently they mostly require a blue logo.
When hiring a PM, we often expected that they’d come in with a wonderful fully-baked plan for how to whip our shop into shape, but that’s proven to be difficult. We needed to step back and examine how we did things, and worked with an Agile consultant who helped us understand what we do well, where we needed help and what role the PM software plays in the overall mix.
How Kula made the switch and why
But first, I want to take a step back and explain what led us to begin investigating agile in the first place. A few years back, we had brought on a large web build with a crazy deadline. They were a client we knew we could get significant ongoing work from, so we at least wanted to see if it was possible to meet the deadline.
But, it was also a complex web build. It started with a geolocation dealer finder with over 250+ dealer pages that had to be manageable by those dealers, a location specific rebate system, and integration with a tire size lookup engine, plus an intranet among all the regular website features and it needed to be ready in a very short period of time. Less than half of what it would normally take us, and it’s not like we could just stop doing all the other work in the shop.
So, we knew that if we were going to pull off this build, we’d have to do things a bit differently from our normal way of working.
We broke the project down into groupings of simple tasks. Then, we put small teams on each task. These teams composed themselves, based on what was required for each task. So, they’d make design or dev or content heavy groupings, execute the hell out of their task, test it and then move on to the next piece. Each task was setup as a To-Do in Basecamp. Our PM kept a list of what needed to be done and what was completed, and also kept an eye on the overall project integration. As we got into the project, we realized what tasks needed to be grouped for optimal efficiency and we also delivered better work because there was a big enough team on each piece to be able to quickly iterate ideas and make the site interactions better.
We actually managed to ship the site just before the deadline and it had fewer bugs than any site of that scale we’d built in the past. The team were happier with the product and loved how much quicker it had gone.
What is agile project management?
Since that project went so well, we went looking to see if what we had done had a name. When we did, we found something called Agile, and more specifically the Scrum genre of Agile. Check out the primary ‘rules’ of scrum:
- Split your organization into small, cross-functional, self-organizing teams.
- Split your work into a list of small, concrete deliverables. Assign someone to be responsible for that list and to sort the list by priority. The implementation team estimates the relative size of each item.
- Split time into short fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code demonstrated after each iteration. (this is called Timeboxing)
- Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.
- Optimize the process by having a retrospective after each iteration.
So, it’s not that different from what we had done with the Tirecraft project. From there we set out to get more intentional with our Agile planning. First though, we had to learn the methodology.
What the hell is a User Story?
As with any technology, there’s a ton of buzzwords that go with agile. Let’s have a look at the main building blocks starting from small to large:
- Story points: our unit of measurement for effort. We disassociate these from billable hours. For us, a blog post, for example, is worth 3 SP. Our marketing retainer clients know that they are buying x number of story points per month. The more they buy, the cheaper they get them. We stole that idea from Paul Roetzer at PR 2020. We still track time internally, but clients never see it. We simply use it to make sure people are putting in a reasonable amount of billable hours (we don’t want to burn them out). We also use it to see if we’re screwing up and over investing in a task. Plus, in my experience, clients want budget certainty and divorcing yourself from billable time allows you to get a step closer to value based billing.
- User Stories: A description of a single piece of functionality or content. As a _____, I want to ______, so that I can _______. Each story is estimated to be worth an approximate number of points, and each also contains acceptance criteria, essentially the definition of done. Just like with personas, for bigger projects we’ll do user story workshops with clients, their customers and other stakeholders during the strategy phase.
- Sprints: A group of user stories that are time-boxed, at the end of which a piece or pieces of functionality will be completed. Usually lasts up to a few weeks.
- Epics: Takes several sprints to complete an epic (overall large chunk of a build, campaign or plan)
- Backlog: Stories that are good ideas, but you just haven’t got to them yet. This could be a huge list, or it could be a few next phase items that you just haven’t had time for yet.
- Burndown: a chart that shows how many stories have shipped vs time remaining in the sprint. We don’t really look at these.
- Stand Ups: A very short all-hands meeting where everyone explains what they’re currently working on, what they accomplished in the past day, and what may be blocking them. These work better with smaller teams. We used to do agency wide stand ups until we hit about 12 people, then they started to take too long. So now, each team does their own, and we do a full agency stand up on Wednesday that we call ‘Hump Day Nooners’.
- Product owner: this could be your account manager, inbound producer, whatever. They’re the person that speaks for the client/product. We’re still figuring this position out.
- ScrumMaster: This is generally your project manager. They traffic work through the shop, manage the backlog and keep oversight on efficiency. If you do scrum right, your Scrum Master’s ability to do capacity planning is off the charts.
Basically what you have is a small group of experts, managed by a scrum master who load up their week with a block of user stories. They work together to ship those story points by the end of the week (or whatever sprint they’re working towards)
A few Kula tweaks to scrum
Aside from the buy more pay less model we borrowed from PR2020 (try doing that with billable hours!), we’ve added a few other things to our scrum model—as I mentioned, everybody bastardizes this.
- Our Agile planning boards are the main deliverable in our strategy engagements. They show the tactics that will be employed to execute on the strategy.
- Business value ratings: our clients can go into their planning board and rate the tactics that are in the backlog using TShirt sizes (XS-XL). This way we can prioritize the work according to what matters to the client. This doesn’t mean we’ll stray from the strategy, but it may mean we skip a blog post (why is it always blog posts that people want to skip?) in order to deliver a political win.
- Our Dashboard gives our management team quick access to stats on how the shop is delivering on a day by day, story by story, person by person basis.
- We use agile for planning our own marketing too, but we need to up our game here.
Implementing Agile for your agency
There’s definitely way more to agile than we’re doing with it. It can get ever-more complicated, but I think there are a lot of reasons to pick the parts of Agile that could work for your agency and start experimenting with them on a small project. We’re also not a pure software shop, and because we work with traditional deadlines, we have had to deviate somewhat from ‘pure’ Agile.
In terms of software, you really should look at either an Agile plugin for your current software, or a dedicated solution like Jira or Planbox. You can use a spreadsheet to track stories, but that can quickly get out of control. In our shop, our Scrum Master and Inbound Producers enter hundreds of tasks a week into Jira. However, the increased efficiency, responsibility and reporting that we get back as a result have really been worth the investment in time and learning.