We are officially two full months into Agile, and I want to share how it’s going and how we did it to this point.

Full disclosure: no one here on the Big Sea team is properly trained in Scrum or any type of Agile methodology. So everything we’re doing is learned from reading just about every post available on the internet, quite a few books, listening to podcasts, and bouncing ideas off other agency owners who’ve been through the process.

We are focusing on the manifesto. We’re embracing the mindset. The approach we’re taking will, I’m sure, change drastically as we slowly close out the projects started prior to this conversion, and we take in more clients who don’t really want to be that involved in their project once we get rolling. And that’s ok!

We’re taking an Agile approach to Agile implementation.

A lot of trial and error. A lot of Trello. And a lot of finding what works for our people and projects. We’re not limited by anyone else’s rules about how we should be working, and I think that’s important. We are making Agile work for us.

So how did we do it?


Our team structure

We were already operating in essentially two teams, so we just made that a little more official.

Marketing Team

We are currently running with one marketing team that includes our Content Director, marketing coordinators and search strategist. We have a PM who serves as Scrum master too. She joins our stand-ups and coordinates sprint planning and retros.  She also helps keep our Trello boards organized and keeps us in check with regards to client deliverables and budgets throughout the month.

Design & Dev Team

The other team includes our designers and developers (a mix of front and back-end). This feels pretty temporary as I think we’ll break this up into two smaller teams soon, but for now, it’s working. They actually have two PMs, one that works as Scrum Master (she also runs the Marketing Scrum), and one who is dedicated as an account lead.

Our sprint schedule

We actually run on two different schedules, which is working wonderfully.

Because our marketing contracts are paid monthly, we decided to run our marketing team with half-month sprints. So we do sprint review and planning meetings twice each month.

The first was crazy. No one had anything prepared properly and we spent almost 5 hours organizing what we wanted to do for each client, deciding how long it would take, and then creating cards for our backlog. That didn’t happen again.

The second spring planning went really well because we had the foresight to build the prep time into our current sprint. We set aside an hour or two for each account that included a call with the client to review numbers and campaigns, then to plan and schedule what we needed to do over the next sprint (or two). Agile at it’s finest!

The design and dev team are working in one week sprints. They meet every Friday afternoon to review what they worked on and do a brief retrospective, and every Monday morning to do their sprint planning. The PMs, as “product owners”, organize what needs to be done for each project or client on Friday afternoons.

Cross-team work assignments

We weren’t sure how to approach this so we have mostly stuck with what we were doing, which is assigning into each team whatever we need. If the marketing team needs design or development, we make sure to create cards in their Master Backlog that get pushed into the next sprint.  We use due dates on Trello cards to help the team understand their importance, and they reach out if they need clarification or re-prioritization.

Our Content Director is actually scheduled across both teams, so we plan her time accordingly (for instance, we usually plan 10-12 hours of her time in content strategy for web dev projects, and 10-12 hours for each week in marketing).  This is, so far, working well, but she attends a lot of meetings.


We started exploring Jira but decided that we wanted to first get comfortable with our processes, then find tools to fit the processes — not the other way around.  And so we’re using Trello with the Scrum for Trello plugin and the Harvest power-up that gives us a nice view of the hours estimated on each card, the actual hours worked against that card, and the capacity for each team member’s sprint (and the master backlog).   This is actually working pretty amazingly.

As an example, this is a snippet of our marketing team’s board.  The number in parentheses next to each team member’s name is their capacity for this sprint (taking into account any planned PTO time, holidays, etc.).  The light blue number is the actual time tracked to the cards in the column; the dark blue number is the amount of work estimated across the cards in the column (ideally, it equals their capacity at the start of the sprint).  The light blue and dark blue numbers on the cards mean the same as they do at the top of the column, but for that specific card.  Any colored bars on the card also have specific meaning, like perhaps they’re internal projects (unbillable) or unplanned work that had to be thrown into the sprint.  This gives  us a nice visual reference and the ability to plan better next go-round.

trello for scrum

Lessons learned so far

  • Sprint planning needs to take place on the first day of a sprint, not the last. Particularly important when monthly reporting is a part of planning of each client’s work. We need a full month’s numbers to be able to finish their reports, and to be able to pivot on our tactics if necessary.
  • Don’t forget to include reporting and admin in your sprint planning. We keep a separate Trello column with a card for each client where we track any stray Admin or project management time that is not tied directly to a specific task or deliverable. One particular client had 10 full hours of phone consulting, a strangely long in-person meeting, and a whole lot of email back-and-forths this sprint. That’s a huge chunk of time that is almost impossible to plan for, but will help us adjust how we include that time in sprints in the future.
  • If you’re using Trello for everything, don’t rely on emails for notifications. They lag, and can be filled with 10 useless notifications so you end up skimming over the one where you’re tagged and actually need to pay attention.
  • Make a card for each planned tactic prior to the sprint planning meeting. Making cards takes a long time, so build that time into the previous sprint and make them ahead of time. Then, it’s just a matter of estimating, prioritizing, and getting to work!  (This shaved two hours off our sprint planning meeting ?)

So far, this transformation has been relatively painless — and it keeps getting better.

Our clients are loving the frequent touch-bases and constant forward progress; our team is embracing the detail and accountability of the process; and our entire agency is more efficient, productive, and profitable.   I’ll keep you posted as we continue to hone what we’re doing and why — I know agency transformation stories were incredibly useful to me before we started this journey so I hope this is helpful for you.