Choose your language:
July 11, 2016
By Kelly Martinez
At the end of last year, TEKsystems needed to upgrade its CMS platform, and in the process realized we also needed to rebuild our entire website—basically from scratch—in order to make it work. TEKsystems' digital marketing manager led the charge to complete the upgrade—as well as the rebuild and unplanned redesign—in just four months. How did her team achieve this? In addition to working hard, the team was able to flex, prioritize and accomplish more because they adopted Agile project management practices for both the back and front-end teams. In this post, Kelly Martinez takes you through our Agile marketing journey.
As a digital marketer, I have two teams: front-end and back-end. Our back-end web development team in Montreal, part of TEKsystems Global Services, has used Agile development practices for many years. Yet, I had not considered it for the front-end marketing team.
At the 2015 ClickZ conference, a speaker discussed adopting aspects of the Agile methodology to manage digital marketing initiatives across multiple channels. At the time, I was finding it difficult to stay on top of all the projects my team was working on (e.g., SEO, social, website) and I thought this might be a better way for me to keep up with the details and changing circumstances on a more regular basis. Since half my team was already using Agile on a daily basis, I thought, hey, why not give it a try?
Getting started with Agile marketing
In September 2015 I began incorporating the Agile methodology and principles into the daily operating rhythm of our front-end digital marketing team, which includes the following roles: digital marketing manager (me), social media specialist, SEO specialist and CMS administrators. We opted for Scrumban-like approach. We got a large whiteboard and divided it into backlog, research, in progress, in review, blocked and done categories.
We put up any open projects on our collective to-do list to get a feel for what was currently in flight. At first, there were no backlogged items. We also didn’t try to break larger projects down into multiple stories—we just wanted to get used to the cadence. Because of the specialized roles individual team members have, we decided that we wouldn't put up tasks without attaching a team member to it; everyone would have to own their work. Also, day-to-day activities or responsibilities (e.g., monthly reporting) didn’t need to go on the board; only tasks that directly related to our strategic priorities for the year went up.
We set up daily 15-minute stand-up meetings. Each person would have a few minutes to explain their items on the board.
Lessons learned—some quite quickly!
Almost immediately, we realized we needed different colored Post-its for each person to make it easier to track our individual stories.
Initially, we tried sizing stories—i.e., estimating whether they were extra-small (less than four hours of work), small (4–8 hours), medium (8–16 hours), large (16–40 hours) or extra-large (multiple days). After a couple of sprints, we realized sizing the stories didn’t really help us understand our work any better, or move things along any faster. Since that practice didn’t work for us, we removed it from our operating rhythm.
Our daily stand-ups evolved as well. We found ourselves needing to remind each other to not just move the task across the board without saying what the story was and why it was being moved. At first, we had a tendency to just say “Oh, that’s done.” Eventually someone asked, “What is that?”
Stand-up meetings provided a chance to identify potential roadblocks and ask questions. Team members were able to collaborate more quickly and without a manager’s guidance: problem-solving on their own. Multistep projects were handed off between people more easily as well. Team members reported feeling more aware and informed about the work the entire team was doing.
I wanted to get a better understanding of how our work was aligning to my team’s strategic priorities for the year. I wanted to track how much work was getting done, how much was tied to our strategic priorities and how much was potentially unaligned busy work that wasn’t advancing our most important goals.
So on the next sprint, I wrote down everything that was on the board (regardless of stage), tied it to one of our strategic priorities and notated the point person. I shared this with the team so they could see how much of their work over the past two weeks had been dedicated to one of those priority areas. This helped me understand what work was really being done and by whom. We continued like this for several months until we all naturally become more familiar with the work being done and how to prioritize.
The frequency of conversations, questions, decision points and resolutions helped us “fail faster” and test more new ideas. Eventually I stopped documenting work as it became clear the team had adopted a more efficient cadence. As we started to build out the backlog we got better at breaking the stories down into smaller parts so we could see what steps had to happen first in the process and so forth.
When it came time for us to rebuild our site on a very short deadline, our new operating rhythm really paid off. Our front-end team was able to respond faster to SEO needs so that everything was ready for our back-end team when they needed it. Our design and front-end developer teams were able to communicate daily on graphics and UX needs so hand-offs were smoother across functions. Not only that, but when it came time for all hands to get on deck to help build content pages, our regular day-to-day work was so streamlined that it allowed us to all take on more and push to that finish line.
What we’re testing now
More recently, we realized we were missing an opportunity to tie items from our back-end development team’s Agile process in Montreal to the front-end development work our CMS team was managing, as well as our SEO, SEM, social and email work.
We decided to divide the Kanban board into two sections: CMS/web work and SEO/SEM/PPC/social/email work.
We hope this will give us a more comprehensive view of what’s being done, what’s coming up and how the projects all tie together. We can align work we might have to do in advance of back-end development, and vice versa. For example, if our development team is building new pages, we need to add SEO meta data to the queue so it can be ready around the same time, thereby preventing unnecessary delays. If the project stalls, we can then put the meta data project into the backlog.
Find what works for your team
If you are familiar with Agile software development, you recognize that our team has adopted some practices but not others. For example, we hold daily stand-up meetings and have a Kanban board to track progress but don’t use a formal documentation process, like a burn-down chart. I did some research, we tested some things out and the result is an Agile operating rhythm that works for us.
Beyond my having a better handle on how my team allocates their time and our resources, we’ve also experienced greater productivity and efficiency, enhanced communication and delivery of higher-quality services. I don’t think we would have been able upgrade our CMS platform—plus the rebuild and unplanned redesign (we’re nothing if not ambitious!)—in just four months without our Agile-light process. The buzz has caught on in the Marketing department at large as well, and we’re testing using a Kanban-like board to track cross-departmental projects at a high level to keep the entire team aware of progress.
Quickly brush up on Agile marketing best practices and terminology with our Agile Marketing: An A to Z Guide infographic
As the digital marketing manager for TEKsystems, Kelly Martinez is a passionate student of her industry and how technology can enable superior customer experiences. When she’s not reading up on digital transformation or content marketing, you’ll find her knitting socks or debating GOT time travel theories. #ItsAllBransFault!