Design templates in Databox, complete with the data sources, metrics, and visualizations that you need, and save them to your account so that they can be used for any client in just one click.
Using Databox | Mar 30
Mark Long on October 6, 2017 • 18 minute read
This has led to multiple interpretations of what the “Agile transformation” really means. Many teams will say:
“We do a daily standup in the morning; we are an Agile shop”.
If you’ve worked in an Agile environment before, you know that is pretty far from the truth.
The biggest problem is that agencies ‘don’t know what they don’t know’. They roll out Agile by diving in all at once. Then, they get frustrated when they hit barriers. They don’t know how to get themselves out of this situation. The entire process gets derailed and they go back to square 1. Or, they get 33% of the way through and say, “That’s good enough, we’re Agile, let’s start talking about that in our marketing pitch.” But, the team has not taken full advantage yet.
Most agencies start with the Scrum framework first because it is the most popular Agile approach and provides a set of well defined “guard rails” for the team to work within. It is a common starting point for teams that are just dipping their toe in the water.
Scrum is simple to understand but difficult to master. Agencies will say:
“We just have to have these meetings or look at these charts. We just need to talk about things in terms of stories and story points and then we will be good to go!”
In reality, there are a lot of subtleties and pitfalls that agencies fall into.
That’s where my consultancy, Limbr, comes in. We help agencies implement Agile and Lean methods throughout their operations and avoid the common pitfalls. At the end of the day, they have a system that makes them more effective and efficient and they are able to get to that point much more quickly and with less pain than if they did it alone
This massive guide will cover 5 specific reasons that agencies struggle to solve their problems with Agile. I will also share the processes I use to help teams overcome each one. Let’s jump in!
The problem: The most common problem I see is that the leadership team doesn’t want to (or isn’t able to) fully commit to living and breathing Agile. Or, they are bought in, but they don’t understand exactly what being Agile really means.
For example, I’ve dealt with agency leaders that set a mandate for their teams:
“We have to be Agile in order to stay competitive. If you are producing inbound content or dealing with the customers, we want you to start following Scrum by the book.”
But when these leaders want something done, they go around the system, tapping their employees on the shoulder and effectively saying:
“This request just came in from our most important client, I need you to have it done by the end of the day. I know the team already decided on your priorities for the Sprint, but I’m the boss and I know what’s right.”
This isn’t done maliciously — they just don’t realize how severely this type of interruption undermines the team’s progress in adopting the process changes. They don’t truly understand concepts like:
Because they don’t have a proper grounding in the concepts and they’ve never done it before in practice, they inadvertently sabotage the team’s hard work. The team slides back into their old ways because that is what the leadership team encourages them to do.
Why this is a problem: A Sprint is a timeboxed team effort to accomplish a certain number of tasks. They are usually 1-2 weeks long. The Sprint encourages focus. The team names priorities for the Sprint and they make a commitment to do their best to get that particular set of work done. As soon as they are forced to deviate from that commitment, the team incurs “switching costs”. They have to:
Every time this happens, there is a significant productivity loss that occurs. If you have a leader that practices “tap on the shoulder” management every day in a two-week sprint, the productivity of the team might decrease by 25-30% solely due to the switching costs.
Morale drops for the team. They spend a lot of time planning a two-week sprint, analyzing client needs and prioritizing their backlog. They make a series of data-driven decisions on how to best use their time. They do not appreciate when someone from outside the team who did not participate in the planning process demands that they change priorities on a whim. They will feel that this new work will not actually be more useful for the client.
Instruction from outside sources damages the team’s perception of how the planning and prioritization process should work, and causes them to question how much autonomy they actually have.
The solution: I have the agency leadership team form a Scrum team and execute the planning portion of our engagement using the Scrum process.
They face the same learning curve that they’ve asked the rest of the agency to navigate and experience first hand the impact that sidestepping the process has on their own ability to deliver on their commitments. By the time the rest of the agency is expected to start practicing Agile, the leadership team is much better equipped to lead by example rather than issuing well-intentioned but misdirected feedback from the ivory tower.
The problem: The agency does not re-design their organizational structure to build proper Agile teams. Most of the benefits of Scrum originate from forming permanent (or at least fairly stable) teams of skilled individuals, aligning them to a single set of shared goals, giving them the autonomy to self-organize to meet those goals, and holding them jointly accountable for their results.
For example, a team might be responsible for a particular client or group of clients. Agency leaders need to give the team the resources and environment they need and then get out of the way. Teams need to know:
Agency leaders need to answer those questions and staff the team with the right people and the right skills to do the work effectively. Then let them get to work.
Those teams will mature together over a period of time and figure out how to best:
Why this is a problem: One problem is that many agencies attempt to construct these teams, but they are teams in name only. Agency leaders will assume that because a group of people now physically sits together or attends the same meetings, they will immediately function like a real team.
However, each team member is still tasked with different goals and will be measured by different outcomes. Because they are not holding the team accountable as a unit, team members have no source of motivation to collaborate and support each other – they simply work independently, in the same old silos, while sitting together as a group.
Another common problem is that agency leaders don’t give the teams enough breathing room to really go through the stages of team formation. It is very common in an agency environment for teammates to be pulled off of projects and moved over to other projects. Perhaps a hot new client comes in, and agency leaders pull a designer off of a team and onto this new shiny opportunity.
If team members experience this sort of constant shuffling, they don’t get enough time to go through the team formation process and learn how to work together. They will never reach a high-performing level.
The solution: During the planning phase of the agile transformation, we spend a lot of time considering the composition of the new Scrum teams and analyze a number of factors to reduce the possibility of having to shake up the new teams too soon after they launch.
For example, we take the client portfolio and determine how many clients each team can reasonably service while maintaining a high level of quality. Typically there are too many clients for each team to handle a client apiece, so we end up with multiple groups.
Once we group the clients together, we ask, “What skills are necessary to do the majority of the work that we have committed to do for each of these clients?” These skills usually include client services, copywriting, design, development, and other specializations like PPC or SEO. We assess the capabilities that each team needs to have independently of thinking about individual team members.
Then, we look at all the employees in the agency. We go through an exercise of trying to identify the right person for each seat on each team:
It’s a very conscious effort to determine who should be grouped together to meet client needs.
Then, once we make a decision and put teams in place, we must resist the urge to change things up too quickly. Take a step back and give the teams ample breathing room to go through the formation process on their own. Give them support when they ask for it, but otherwise get out of the way. Resist the urge to micromanage and let them self-organize to meet their assigned goals.
The problem: Agile centers around working in an iterative and incremental way, where larger work items are broken down into small, well-defined slices that the team can start and finish in a short period of time. This approach often doesn’t match what agencies are used to. Instead, they might say:
“We’re going to publish an eBook. It needs to be done in 2 months, and it needs to address this topic and buyer persona and drive leads to this funnel offer.”
While the team understands at a high level what the finished product needs to accomplish, there is a lot of ambiguity in terms of how the work will get done. Team members bounce around between numerous tasks, and no one is quite clear exactly where the team is in terms of progress or what needs to happen next in order to push the eBook closer to completion.
When starting to practice Agile, teams often don’t quite know how to best slice up these larger deliverables into logical bite-sized chunks that they can tackle effectively in their Sprints.
The solution: To set their teams up for success, agencies should invest ample time early on determining how to best break down common deliverables into iterative and incremental slices.
While every eBook is different, the steps for driving every eBook from idea to published content are similar enough that the agency can roughly standardize how the work should be broken down in a way that maps well to working in time-boxed Sprints.
For example, the first step of creating an eBook is usually to write the copy. This step involves both incremental and iterative work: the team first writes an initial draft (an increment), sends the draft to the client for feedback, and then undergoes one or more rounds of revision (iterations) to address the client’s feedback before the copy is considered done. Each increment and iteration is represented by a user story so it can be allocated to a Sprint and worked on by the team.
The next step is usually laying out the eBook in a designed PDF. This step also includes both incremental and iterative work: an initial design comp (the increment) and one or more rounds of revision based on client feedback (the iterations). Each slice of work will be represented by an individual story.
Once the design is done, we need to have a story for setting up the “thank you” page, landing page and follow-up email in HubSpot. We also may need a CTA and a workflow.
The team wraps up all of these related stories in a collection called an epic to keep track of their progress against the larger deliverable, the eBook.
Different agencies expose more or less of this work breakdown structure depending on client appetite for the details. Most clients only care about the epic – they just want to know, “When am I going to get my eBook?”.
The team benefits internally from the additional clarity offered by small, well-defined user stories.
The client benefits from the team’s ability to better manage their expectations in terms of:
The problem: When agencies move to agile, they only focus on short-term planning, especially in the early days. They only look at what they need to accomplish in the next week or two weeks. They determine their priorities for each Sprint based purely on looming deadlines and the most recent client demands.
When agencies get stuck in this short-term rhythm, they never step back and start (or resume) planning at a more strategic level. In Agile, we have higher-level planning mechanisms like themes and initiatives, and we conduct strategic roadmapping sessions to make better decisions about where teams should invest their time in order to deliver better inbound marketing results for clients.
Rather than looking solely at the punch list of things directly ahead, agencies need to take a step back and use all of their data to make better decisions about bigger picture initiatives for the client. Bigger picture goals need to go on the roadmap. They should dictate what the team works on next week and the week after.
The solution: Typically, on a quarterly basis, team members should sit down with the client and revisit the client’s marketing goals and business needs. They look at changes in the business from last quarter, and expectations for next quarter.
For each of the client’s areas of focus, they should define a broad theme for the upcoming quarter. Each theme must have well-defined objectives following the SMART criteria so the team and the client are on the same page about what success means and how it will be measured.
Then, the team needs to develop one or more strategic initiatives for each theme that spell out how the team will achieve the stated objectives. Each initiative will be comprised of a handful of marketing tactics. In the case of a content marketing campaign, one tactic might be developing an eBook. Other tactics would be complementary, such as blog posts, social media promotion, maybe some keyword optimization.
All of these tactics are broken down into Epics and Stories that go into the team’s backlog and will eventually be worked on in sprints during the next quarter. Every week or 2 weeks, the team pulls from that list to determine what they need to do next to deliver on the strategic initiatives they agreed on with the client. The client’s priorities might change somewhat after the roadmapping session, and the team can change their backlog in response. But, generally, 80% or more of the pre-planned roadmap drives upcoming sprints.
Advantages of this approach: The best thing the team can do is to listen to the marketing data. In the roadmapping session, the team might have hypothesized that the best way to reach the goal for this quarter was an investment in PPC. So, they designed a PPC campaign and started to execute it.
But, they looked at the results and maybe they are nowhere near what they anticipated. Rather than repeating this for rest of quarter, they can revisit the strategy and try something different. They can experiment with a different ad network, or change up the configuration of the ads. That is the agile process. Try something, learn from it, and use those learnings to make better decisions on what to do next. Here’s a guide on how to adjust inbound marketing plans in real time, if you would like to learn more.
Other changes can surface too. Maybe during a roadmapping session, the team decided to spend a lot of effort on marketing the customer’s new product launch. Then, maybe the client decides they are no longer going to launch that product in Q2. Now, the team can use this new information from the client to reallocate budget to a different theme in order to respond positively to the changes in the business environment.
You can use a dashboard like the one below to track the success of marketing initiatives on a weekly basis. This dashboard looks at which sources of traffic create leads in HubSpot.
The problem: Agile adds value over time because it encourages you to self-reflect on how things are going. You must experiment with changes in your approach and processes in order to make things better.
You should finish every Sprint with a Retrospective to frankly discuss what’s going well, what’s not going well, and where to take action. In your upcoming sprint, you can try something different and measure the resulting improvements (or not) in terms of productivity, work quality, and whether your team is happier at work.
Teams tend to glaze over the retrospective. They focus too much on the tactical, day-to-day grind of getting things done. If they do not make the retrospective a priority and make reflection part of the process, they will never reach a level of high performance.
Similarly, agencies are accustomed to coming up this a plan and sticking to it for long periods of time without reflecting on whether the plan is still relevant or appropriate. It used to be normal for an inbound agency to commit to a one-year contract with clients in which the agency would identify all of the individual tactics in detail that they would produce over the next 12 months.
The team would then treat the contract as a to-do list and blindly stick to it even in the face of new, better information. It didn’t matter what the actual marketing data said. They weren’t using results to change up the plan, even though they knew a lot more 6 months in than when they wrote the contract.
The solution: Agile frameworks like Scrum strongly encourage the team to focus on continuous improvement. If a team follows the Agile planning approach described above, they will look at the data, gain insights from the data, compare that to what they thought would happen, and use those lessons to make more intelligent decisions into the future. This type of reflection and response is the number one thing that will improve inbound marketing results for clients.
The same thing holds true for internal culture. If, every single week, your team bangs their heads against the wall and says, “Man, this was really hard because I faced this obstacle!”, and then says, “Oh well, maybe it will get better next week!”… that is the definition of insanity. The construct of the Sprint puts the Retrospective process front and center, giving the team a structured approach for identifying problems in their process and experimenting with actionable changes that lead to incremental improvements.
That is a lot to handle at once! As you can tell, Agile is intimidating because it requires you to rethink every process. But, you can only achieve the consistent quality associated with Agile through the dedication of the whole team.
You can start Agile in your agency with the leadership team, as suggested in section 1. Try it out with top decision-makers and see if it is a good fit for your agency’s culture. If it is, then you can decide whether you want to take on the transition yourself, or work with a consultant to help you roll it out smoothly.
Using Databox | Mar 30
Agencies | Mar 5
Agencies | Oct 8 2019