PART 4
PRACTICES
Daily Activities for Achieving Lasting Agility

Productivity is never an accident. It is always the result of a commitment to excellence, intelligent planning, and focused effort.

PAUL J. MEYER

WHEN I WAS WRITING this book, it was hard—really hard—to avoid jumping straight to this material. The specific team-level practices described here hold the keys to so much amazing transformation that I wanted to write about it right away. I have, however, a very good reason for writing about practices last. Practices are powerful, but without the other supporting components their impact will be severely limited.

I see it all the time in teams trying to adopt Agile ways of working. They want a change, so they start implementing some of the simpler practices they know about from Agile. Usually that means putting some stuff on a board, and maybe having daily standup meetings (fifteen-minute check-ins that usually happen first thing in the morning). The problem is that they haven’t tried to approach their work from a different perspective. They haven’t changed their mindset; they haven’t adopted new shared principles; they don’t even understand why teams take the time to visualize their work on a board or talk together for fifteen minutes every day.

Without the infrastructure behind them, the practices don’t seem to work. The board gets cluttered, nobody updates their cards, people start feeling resentful that another tool has been foisted on them, and eventually its use dies out. Or daily standup starts off strong, but then people realize they don’t really work that closely with some of their teammates, so they stop paying attention to those people’s updates. Pretty soon the meeting becomes a rote status report resented by its attendees, and again the practice withers away.

These sad deteriorations are not only frustrating and a waste of the team’s time; they can also sour large groups of people on agility in general. “We tried that Agile thing,” they’ll sometimes tell me, “and it just didn’t work.”

What they really tried was bolting a handful of Agile practices onto an otherwise traditional system. That’s ineffective in the long run, and it’s not what anybody wants for their work life. So yes, the practices are the shiny manifestation that makes everyone ooh and aah. But as we discussed in the early pages of the book, even the sexiest-looking car disappoints without a good engine. Take the time to build a good Rimarketing engine. You may be able to do that simultaneously as you adopt some of the practices from this part of the book, but don’t try to get by with practices alone. Your car might look cool, but it won’t get you anywhere.

Practical Advice for Agile Marketing Teams

Most of the practices in this chapter focus on the execution team, because that’s where the daily magic happens in Rimarketing. As you’ll recall from Part Three, the execution teams are responsible for the How part of Rimarketing. Most of the What Cycle is completed during annual and quarterly planning activities; the rest syncs up with the schedule established by the execution teams, what I call the Execution Team Cycle (see Figure 18).

If you’ve been part of an Agile environment, some of what’s covered in this part of the book may sound a bit familiar. I’m borrowing practices, activities, and in some cases cadences from existing Agile frameworks like Scrum and Kanban, and I want to fully acknowledge the debt Rimarketing owes to these early incarnations of agility. However, what I’m proposing here is a new iteration of the Agile framework: the Ri version. It builds on, and yet breaks away from, existing options.

FIGURE 18
Execution Team Cycle

Rimarketing Framework^® AgileSherpas.

FIGURE 19
Flow + Iteration

Rimarketing Framework^® AgileSherpas.

Let’s start by establishing the cornerstone of the Execution Team’s How Cycle: choosing between flow and iteration (see Figure 19).

Rimarketing execution teams have the flexibility to decide on the precise mechanism they want to use to manage their work, choosing from these two options. When a team is in flow they’re working and delivering continuously without reference to any particular timebox. This is the default operating mode for a Rimarketing execution team. But at times they will need to create focus on a subset of the work in their queue. In these moments they begin a series of iterations, which will last until the identified subset of work is done. An execution team may choose to conduct a single iteration before returning to flow, or they may need several consecutive iterations.

Before Beginning Flow: Visualizing Work

Before a team can begin managing work within either the flow or iteration state, it must first visualize the way that work gets done. Creating visibility aligns with the Rimarketing principle of radical transparency, and it also allows the team to gain insight into what really happens as they attempt to complete various pieces of work.

Making the progress of work more visible doesn’t have to be enormously complicated; kanban boards will be our tool of choice because they’re simple to create and yet convey huge amounts of information (see Figure 20). Tools like Trello have made this kind of visualization very common, so chances are you’ve seen something like it at one time or another.

While they are simple in theory, kanban boards are also easy to get wrong if you don’t understand the guiding principles behind their configuration. First, a good board is an information radiator, which means it provides a lot of insight in a small space without making the observer do a lot of mental work to understand it.

FIGURE 20
Kanban Board

Rimarketing Framework^® AgileSherpas.

Next, the board is very much a team artifact. Team members are the ones who decide how it should be set up. But it will also help stakeholders, other teams, agencies—and anybody else concerned with what the team is doing—understand what’s going on. A quick review of a kanban board should tell a complete story of what work is in progress, what’s gotten stuck, and what’s been completed.

You’ll notice that the board illustrated above, while simple, has moved beyond a single “In Progress” column, and that is deliberate. The sooner you can get more specific about what’s actually happening while work is “in progress,” the better. Most marketing projects have multiple phases; they need help from copy, design, email, social, automation, etc. So if all we have is a single progress column, a piece of work could hang out there for weeks. Then we don’t know which stages of work are taking a long time and which ones the team is flying through. Without this insight we can’t intelligently cross-train people, make the case for hiring additional resources, accurately predict delivery of work, or address bottlenecks in the workflow.

On the other hand, you don’t want a board that’s overly complicated. If you find yourself with more than ten columns, take a hard look and see if they’re all providing important insight. If so, that’s great, but don’t let your board balloon to a massive width. You need to walk a fine line between a board that’s detailed enough to provide insight into the individual phases of work and general enough to function well for the tasks a team is responsible for.

Speaking of avoiding overcomplicating things, each execution team should have only one kanban board. A team might be tempted to create a board for each project or each person, or to place strategic campaigns on one board and business-as-usual work on another. But splitting things up in this way provides only a fragmented view of what’s going on with the team. And making intelligent tradeoffs is hard when you can’t see all the work side by side. Remember, in order to enhance focus and limit the pernicious practice of context switching, we have to maximize the amount of work not done. The only way to do that is to get a holistic, complete view of the team’s activities.

If you need to break down your visualization into different components, there are ways to do so without splitting into multiple kanban boards. Horizontal divisions, also known as swimlanes, deliver greater detail on certain aspects of work without requiring a new board. Figure 21 contains an example.

FIGURE 21
Kanban Board + Swimlanes

Rimarketing Framework^® AgileSherpas.

Swimlanes may represent different projects, strategic initiatives, kinds of work, or even people. Their labels depend on what additional information the team or its stakeholders need to glean from the kanban board.

Every execution team needs to visualize its work, but not all kanban boards will look the same. As with all aspects of a Rimarketing system, we’re committed to continuous improvement. Your first board design isn’t likely to be the best version, so be prepared to iterate on it over time.

One final note: in the spirit of entrepreneurial behavior, each team member is responsible for updating the board with their current activities. If I start a new work item, I’m the one who moves it out of the queue. If my item gets blocked, I’m the one who adds a marker to indicate that status. The team lead doesn’t own the board; it belongs to the team, and they should care for it and its contents.

Tools for Visualizing Work

Because an initial board layout isn’t going to be perfect, I recommend using a physical kanban board for your first few tries if at all possible. If most of your team is in the same location, find a wall or whiteboard somewhere, and make it the new home of your kanban board. Even if you have a handful of remote employees, you can still use a physical board. Each remote employee just needs a board buddy who moves their cards for them. The remote person sends an instant message to their buddy, who moves the card the next time they’re at the board.

If you’re mostly distributed, however, a physical board may not be feasible. In that case, go for the simplest tool that will still deliver your team’s early board goals. If vertical columns are all you need, Trello may be your best bet. As of this writing it’s easy to get a free board up and running, and it includes useful features like adding members, due dates, checklists, color coding, and other helpful ways to keep the team organized. If you think you’ll need swimlanes soon, however, Trello doesn’t currently offer that functionality. A more formal Kanban tool will be the way to go.

What you don’t want is to shell out a ton of money for a fancy project management tool (even if it’s an Agile one) before you truly know what you need. Lots of great options exist (Aprimo, CoSchedule, Workfront, and Wrike are currently trying to serve the Agile marketing audience, and the space is really taking off), but until you know your requirements you won’t be a very intelligent software buyer. If you can get started in an analog way (or by using a simple free option), you’ll learn a lot about your workflow needs very quickly. Then, after a couple of months, you can explore the market with a more informed eye. You’ll be far more likely to buy a tool that really helps you, rather than getting one up front and trying to force the team to conform to it.

Creating Focused Effort with Work-in-Progress Limits

The final component of an effective workflow visualization is one of the most simple, counterintuitive, and powerful Agile practices: work-in-progress (WIP) limits. In every workshop I run we do at least one exercise to demonstrate the power of WIP limits, because in all honesty they sound like a ridiculous concept if you’re unfamiliar with them. Their guiding principle is that by doing less at any given time, we can ultimately accomplish more.

Most of us believe that the sooner we start on something the sooner we’ll finish it, but study after study has proven this common assumption wrong. In fact, the more things we’re working on at any one time, the longer all those items take. If I have twenty things to accomplish this week, I may feel very productive if I start them all on Monday. I can also tell the ten stakeholders that I’m working on their project, which should make them happy with me. The problem is, when Friday afternoon rolls around, none of those twenty items will be anywhere close to finished.

If I continue to try to tackle all twenty simultaneously, I may need another full week (or more!) to complete them. I’ve been jumping back and forth between twenty tasks, which means I haven’t had much time to devote to any of them. I’ve also wasted huge chunks of time trying to force my brain to switch gears and think about different projects. Our brains crave focus and completion; they don’t like all those jumps. As discussed in Part Two, context switching is the price we pay for task hopping.

The simplest way for me to accomplish all twenty to-dos is to work on only a few at a time. I tried to finish twenty tasks in five working days, but it actually took me ten days. My lead time for twenty items was therefore ten days. To reduce that lead time to the five days I originally planned for, all I have to do is cut my WIP in half. So rather than trying to do twenty items at the same time, I’ll work on ten until they’re done and then move on to the next ten. This means that the second half of the tasks won’t get started right away, which can be hard for stakeholders to stomach. They want to believe that I’m working on their project RIGHT NOW. But in fact, they’ll get it much sooner if I focus on fewer projects at a time.

As you can imagine, this kind of focused effort means that we need a high degree of confidence that we’re doing the right work first. (We’ll get into the practices for queue creation and refinement shortly.) Data are all well and good, but there’s nothing quite like a real-life experiment to drive things home—especially when the concept is as counterintuitive as this one. If you or anyone around you is still skeptical about why or how WIP limits work, try the following quick exercise. In both rounds you will execute the same task: writing the sentence “I will limit work in progress” several times.

Round 1: No Limit on WIP

In this round we’ll operate in a traditional model: working on lots of things at the same time. To make the experiment as realistic as possible, think about how many projects you’re currently working on, and use that as the number of sentences to write. If you’re miraculously not working on a bunch of projects right now, you can use the number five.

When we have no limit on our WIP, we jump from project to project, so in this round you’ll write one letter per sentence before moving on to the next. If five is your number, you’ll write “I” five times because it’s the first letter in the sentence. Then you’ll write “w” five times, once in each sentence. Then “i,” and so on until you’ve finished them all. Time yourself, and note when you finish one sentence as well as when you finish all five (or whatever your number is).

Round 2: WIP Limits in Play

Now let’s do the same experiment with a WIP limit of one. In this case, you’ll work on one “project” until it’s completed. For our purposes that means you’ll write one sentence until it’s finished, and then move on to the next, and so forth until all five (or whatever your number is) are done. Again, time how long it takes you to finish one sentence as well as all five.

It’s counterintuitive but true. Limit your work in progress, and you’ll accomplish more in less time.

Basic Best Practices for Wip Limits

Limiting work in progress is one of the most powerful ways to complete more work in less time, and there are several different ways to do it. Depending on your team size, specialization, and board design, you may find it helpful to limit WIP in one (or more) of the following ways:

• ■ by person

• ■ board-wide

• ■ by column

• ■ by individual cell

If you have individual contributors with specialized skills who don’t do much collaboration or engage in many handoffs, limiting WIP on a per-person basis may be all you need to do. In this case each person agrees to work on only a small number of items at a time, and they’ll keep themselves and one another accountable through the team’s kanban board. They may even use the simplest form of visualization, with columns for just Queue, In Progress, and Done, because each person’s workflow varies too much to allow for further details about what “in progress” really means. A team of five might appear to have a lot of work in progress, but a low per-person WIP limit will keep things moving. If you’re using individual WIP limits like this, keep them really low. Two per person is a good starting point, and three is about as high as you can go without dulling the impact of the limit.

If per-person WIP limits seem too granular (or too much like micromanagement), you can create limits that govern the entire board. This works best if the board is fairly simple—that is, with a maximum of two or three active columns. For example, a team of five whose board includes Queue, Creation, Publishing, and Done might establish a WIP of eleven for the whole board. Sometimes there might be eight items in Creation and three in Publishing. At other times Publishing might hold most of the work. The idea here is to give the team flexibility around where the work falls while still creating a system that helps work flow quickly.

The board-based WIP limit works best when you aren’t concerned about finding or mitigating bottlenecks in the system (or if you have a very simple system). Since the system is flexible about what stage work is in, you won’t be able to see if work is stalling out at a particular stage or with a particular person. Sometimes that’s okay; at other times you’ll need more specific WIP limits to help uncover issues that need attention.

One of the more specific ways to regulate work in progress is through the traditional use of WIP limits based on columns on a kanban board. Here we set the maximum number of items to be worked on for each stage. So if our board’s columns are Queue, Copy, Design, Publish, and Done, each of those phases (except Queue and Done) would have its own unique WIP limit. This approach lets us manage workflow in a much more focused way, because we can dial the limits up or down based on the phase of work. So if our board without any WIP limits looks like Figure 22 much of the time, it becomes clear that we need different WIP limits for different phases.

FIGURE 22
Kanban Board without WIP Limits

Rimarketing Framework^® AgileSherpas.

The phases with less overwhelming volume can get a lower initial limit, maybe just two, while the ones that are always overloaded will need to be higher, maybe five for Copy and three for Design (see Figure 23).

Finally, we can go even further with this column-based WIP limit if we’re using swimlanes in our workflow visualization. When we add these horizontal dividers, we create cells on the board, each of which can get its own WIP limit. Taking our previous example, we might add horizontal lanes for three separate initiatives. This means we can establish distinct WIP limits for each phase and each initiative, as illustrated in Figure 24. Doing so helps ensure that the team focuses the right amount of work on each subset of activity.

FIGURE 23
Kanban Board + WIP Limits

Rimarketing Framework^® AgileSherpas.

FIGURE 24
Cell-Level WIP Limits

Rimarketing Framework^® AgileSherpas.

Initiative 1 might be the most valuable and might deserve most of the team’s time, but they can’t neglect the other two. In this case they’d establish a higher WIP for all the cells in the Initiative 1 lane. They get the benefits of achieving more in less time through the WIP approach, but they also create additional focus on completing the most impactful work. And if a new threat or opportunity arises around one of the other initiatives, they can always adjust the various limits temporarily or permanently to reallocate their work.

Two final notes on WIP limits and best practices: your WIP limits should be painful, and you probably won’t get them right the first time.

First, to achieve their goal of helping you stop starting and start finishing, WIP limits need to be set as low as possible while still keeping the team moving forward. A WIP limit that doesn’t actually limit work isn’t doing its job. On my personal kanban board I have a strict in-progress limit of two, and I bump up against it practically every day. Time and again I’d like to start on a new task, but I’m already working on two. Per my WIP-limit rule, I must finish one of the tasks before beginning another. It’s irksome but effective.

A good rule of thumb is to start your WIP limit a bit higher than it probably should be and work your way down. You can try an initial WIP limit of twice the number of people who can work on that task. For example, I’m the only one who can perform the tasks displayed on my personal board, so my WIP limit is two times one, or two.

As with all facets of the Rimarketing system, be prepared to test, learn, and iterate around WIP limits. If you’re new to the idea, you won’t do it perfectly on your first try, but WIP limits will become a powerful productivity tool if you keep them in place and adjust them until the team is constantly cranking work out.

Advanced Visualization Techniques: Buffers and Pens

As you grow more comfortable using your board, chances are you’ll find areas where you need some additional strategies for making work flow smoothly through the system. When that happens, you can explore two advanced options for visualizing work: buffers and pens.

Buffers are most useful once you’ve identified the bottlenecks in your system. A useful way to mitigate a bottleneck is to ensure that every team member always has valuable work to do, which is where the buffer comes in. A buffer column doesn’t have a WIP limit, and tasks placed there aren’t actually being worked on. They are simply hanging out, ready to move into the next phase of work.

For instance, if publishing work is the bottleneck of our execution team, we need to make sure there’s always work ready for the publishing people to grab. The faster we can push tasks through the bottleneck, the faster the whole system will go, so we don’t want team members waiting around for valuable work to do. To avoid that problem, we create a “Publish Ready” buffer column (see Figure 25), which should never be empty. Whoever gets things ready to publish will ensure that something valuable always sits in that buffer column, waiting for the publishing folks.

FIGURE 25
Kanban Board + Buffer

Rimarketing Framework^® AgileSherpas.

Another practice that can be useful for teams who often find themselves waiting on other groups is including a “Pen” (short for holding pen) column on the workflow board. As discussed, WIP limits keep work flowing across the board, but if an item is out for review with another team, we don’t want it occupying our WIP limit and slowing down our flow. We can’t actively work on it, but if it hangs out in an active column, we are unable to start new assignments once we’ve hit our WIP limit. And we absolutely don’t want to artificially inflate our WIP limit to accommodate this out-of-team work, because that will slow the entire system by increasing the number of items in progress. To remedy this situation, whenever a task leaves the execution team’s control, we place it in the pen (see Figure 26).

The great thing about the pen is that the team can still see the task; it doesn’t disappear from the board entirely. This delivers on the Rimarketing principle of radical transparency by showing us how much work we’re waiting on others to complete. It also keeps the team informed about the volume of work that may come back to them. They won’t be shocked when outside groups return tasks that need to be reincorporated into their workflow.

And speaking of returning to the workflow, we need one more column to make the pen work as well as it can. I call this the “Ready” column, but you can label it however you like. Its purpose is to show the team which items have left the pen and are ready to be worked on again. We can’t just reinsert those tasks into an active column, because that could potentially violate the WIP limits. It also pushes work onto the team rather than allowing them to choose when they start on it, a surefire recipe for context switching.

FIGURE 26
Kanban Board + PEN

Rimarketing Framework^® AgileSherpas.

Instead, items move from the pen to “Ready,” showing that additional work is available to be taken back into the system. The team should have a policy for how to deal with these returning tasks. Usually that looks something like an agreement to check the Ready column whenever there’s capacity, and to move work from there into an active column rather than take on something new from the queue.

It may be beneficial to track the amount of time a work item spends in the pen. This data point will help the team know which groups tend to take the longest to review work so they can plan accordingly.

Shared Practices: Queues

Whatever the board structure and WIP limits a team puts in place, they need a queue to fill it. In both flow and iteration states, the queue is the engine that powers a Rimarketing execution team. To function at the highest level, a queue should be well PACED:

Prioritized: There can be no side-by-side priorities in a Rimarketing queue. It must be ruthlessly prioritized, meaning there is one top priority, one second priority, and so on to the bottom. The execution team will always pull work from the top of the queue, so the most important tasks should be listed there. Team leads, through their prioritization activities, guide the team in doing the right work at the right time.

Accurate: The content of an item in the queue should accurately reflect the current understanding of that piece of work. If new information emerges after an experiment is run, the item needs an update. If we thought it would be due next month but the delivery requirements have changed, they need to be reflected on the card.

Current: The queue is not a “set it and forget it” tool. We don’t refine it once a quarter; we update it constantly as new information comes to light. Whether a team lead chooses continuous queue refinement or recurring weekly meetings (see below for more on both of these), the queue should never be out of date or stale.

Educated: A major part of the team lead’s job is to hunt down requirements and specifications for the work their team has been asked to do. Some of the essentials will come out during big-room planning, but others will need to be collected prior to work beginning. When we accept that we can’t create a perfect plan up front, we also have to embrace the practice of continually adjusting projects in response to incoming data. All these activities should be reflected in the contents of the queue.

Detailed: Items look different depending on where they fall in the queue. The execution team will start working on things at the top very soon, which means those tasks need a much higher level of detail than tasks at the bottom. In fact, spending a lot of time chasing down information on low-priority items is a form of waste, because some of them might never make it to the top of the queue. Although the queue represents (nearly) all the work for an execution team during a quarter, we also welcome and plan for change. As things change, low-priority items may get pulled. They may also get delayed by emerging opportunities. In either case, we don’t need to worry about collecting detailed requirements for tasks until they break into the top quarter of the queue.

Building and Refining Your Queue

If you’re in a smaller organization where outlining the flow from executive leadership to teams at a great level of detail isn’t necessary, you can generate a queue simply by listing all your upcoming marketing activities and ruthlessly prioritizing them. Remember, a queue includes not just big, strategic projects but also recurring business-as-usual work, at least as much as is relevant at this level.

This execution team backlog contains team-sized work that will take a couple of people a couple of weeks to complete, which means tiny tasks like “schedule social media sharing for the week” will be far too granular for the quarterly queue. So before they actually start work, the team will need to further break down items from the quarterly queue into their team queue. When in flow this will happen at whatever cadence the team chooses; when in iteration it happens at the beginning of each new iteration.

It’s easy to get hung up on achieving exactly the right level of granularity for each stage of the queue, but not every work item has to be the same size. We place tasks into queues to gain visibility into all the work we could be doing, which then allows us to prioritize things against one another. Queues also reveal the true scope of work that a marketing team is tackling, allowing them to fend off external requests when necessary. We can achieve both these outcomes without precision in work item size.

Don’t worry about getting things exactly right. Remember why you have a queue, and aim to create practices that help you complete the items it contains. As a starting point, listed below are some best practices to guide you. But be prepared to discuss your work items and their sizes in retrospective meetings and to make adjustments where needed.

Accepting Work into the Team’s Queue

It would be amazing if marketing teams could sit down, plan their work for the next quarter, and then go off and do that work without any interruptions or dependencies. Unfortunately, we don’t live in a fantasy world. Instead, we’re beholden to all kinds of stakeholders and internal customers who have a say in what we do. This means we need a system that allows us to take in requests from outside the team in a way that accommodates everyone’s needs (the team’s and its stakeholders’).

We need to strike a delicate balance here, because we don’t want random hallway conversations dictating the work of the team and derailing our focus on strategic, planned tasks. On the other hand, we don’t want to end up with massive briefs or requirements documents dictating every aspect of the team’s activities. Consistency is the watchword for walking this tightrope.

If anyone—and I mean anyone, from the CMO to the newest hire— wants a Rimarketing team to do work for them, they should follow a designated process. That might be sending an email to a specific address, filling out an intake form, or creating an index card with agreed-on content. Whatever the system for accepting work, it needs to be the same across the board. It also needs to meet the team’s definition of “ready”: the criteria they’ve agreed on that determine whether they have all the information needed to start a task.

Each team will have its own, customized definition of ready. Yours might include:

• ■ What audience segment or persona is being targeted?

• ■ Is there a due date?

• ■ Any preferred channels or tactics?

• ■ What metrics should we track to determine success?

• ■ Does this work align with our team’s stated goals?

Anytime a request comes in that doesn’t meet the criteria, the team lead should refuse to accept it into the team’s queue. Otherwise an unclear item may end up at the top of the queue, and the team will lose valuable time chasing down its owner to answer the above questions (or many others). The team lead should spend a large part of his or her time ensuring that new items meet the definition of ready before they get prioritized.

Filling the Queue with the Right Work

Agile systems like Rimarketing deliver outstanding results for many reasons, but two of the most powerful are the combination of customer focus and speed. By providing customer value early and often, Agile teams create strong connections to the groups they serve. But to achieve this rapid delivery, each marketing team’s queue must be filled with work that’s designed to delight its customers in the short term while also meeting marketing’s long-term objectives. For most execution teams, this means drastically changing the way work is designed.

Traditional marketing teams favor Big Bang campaigns, an approach that aligns with the waterfall style of project management. When doing work this way we spend a lot of time up front designing a perfect plan, and then proceed from stage to stage until the entire campaign is complete.

For marketing teams this may mean spending several weeks (or longer) on each stage, such as research and strategy, copywriting, design, editorial review, publication, amplification and promotion, etc. Not only do these kinds of projects take forever to complete; they carry huge risks. Because we receive no outside feedback until the entire campaign is finished, the whole thing could fail, and we won’t know it until we’ve already devoted hundreds of hours and a huge chunk of our budget to getting it done.

When traditional teams who are used to running projects like this get introduced to Agile, they often mirror their old style of project management in the way they design work. They look at the stages of work and decide to spend a couple of iterations on research, then a couple on copy, a couple on design, and so forth. This approach is known as horizontal slicing, and it doesn’t accomplish tasks much faster than traditional waterfall project management. Instead, we want to get accustomed to slicing projects vertically, as illustrated in Figure 27.

FIGURE 27
Vertical vs. Horizontal Slices

Rimarketing Framework^® AgileSherpas.

Using this approach, we identify the minimum viable campaign or minimum viable project—in other words, the smallest number of things we could do and still meet the objectives for the work. We grab the highest-priority or highest-value tasks from each column and focus only on that until it’s done. When finalized and delivered together, these items form a single useful increment that can be finished far sooner than if we completed all the work from one stage, then all the work from the next stage, and so on.

Estimating Effort (Not Hours) for Your Work

Once we’ve identified the subset of work that will form a minimum viable campaign, we need to go about the business of fulfilling it. But the obvious next question is how much can we truly accomplish in a set amount of time? To figure this out we estimate the amount of effort required to complete each item, then track how much work the team can tackle in a set amount of time. Once we have this body of data, we use the historical record to predict when certain items from the queue will be done.

Traditionally, only Scrum teams, those using recurring iterations, would estimate the effort for each item in their queue because they’re concerned about accurately committing to completing a set amount of work in a sprint. Rimarketing teams, however, can make use of estimation whether they’re in flow or iteration. As with most other components of the framework, we combine the effective parts of measurement from both traditions to create something unique for Agile marketing teams.

For those unfamiliar with estimation, it’s worth reviewing some basic best practices here. If you’ve never estimated work before, take your time going through this section; many pitfalls lie in wait that can undermine your data’s accuracy.

First of all, we estimate effort, not hours. Estimating hours is tempting because we can easily track and report on them, but it’s precisely because they’re so trackable that we avoid them. Hourly estimates are just too easy to manipulate and game. If I estimated for my editor that writing a chapter of this book would take me twelve hours, but through some spectacular inspiration it entailed only nine hours, chances are I’ll still tell my editor it took twelve. I don’t want her thinking that I slacked off, or that every single future chapter will only require nine hours. A stroke of luck allowed me to write that one chapter quickly, but the others might take much longer. I’m incentivized to be less than truthful about my hours.

But if we’re estimating based on effort, I’m less prone to misrepresent the situation. My chapter required the same amount of effort, regardless of whether I exerted that effort over nine hours or twelve. Estimating based on effort helps capture more insight about the level of difficulty represented by certain kinds of work.

My preferred method of estimation is to use the Fibonacci sequence (don’t worry, I’m not about to ask you to do advanced math). This is simply a series in which each third number is the sum of the two before it. It goes 1, 2, 3, 5, 8, 13, 21, and so on to infinity. The concept has emerged as the best way to estimate effort because the gaps between numbers increase as you go higher. If we use a regular, incremental series of numbers (1, 2, 3, 4, 5, 6, 7, 8, etc.), it becomes difficult to tell the difference between a four and a five. Even a six and an eight may be difficult to choose between. But when we jump several levels between options, it’s easier to make a call. There’s a big difference between an eight and the earlier numbers—it’s four times harder than a two, and eight times harder than a one.

A creative director recently told me that her team “isn’t into math,” and was struggling to use the Fibonacci sequence for estimation. In cases such as these, a commonly used alternative is T-shirt sizes, such as small, medium, large, extra-large, and so on. The downside of this method is that we can’t add things up to determine the average amount of work the team can complete in a set amount of time. If we did four smalls and an extra-large this week, but next week we’re working on all mediums, how do we determine how many mediums we’re likely to get done next week? With Fibonacci, however, we know that if we did four twos and a twenty-one this week, our throughput is twenty-nine. Then next week we can confidently predict that we’ll complete four fives and one eight. The obvious workaround here is to equate each T-shirt size with a number and do the math after estimation is over, but in that case you might as well just estimate numerically.

Estimation remains a controversial topic in the Agile world, partially because humans are quite terrible at doing it accurately, and partially because it can take a lot of time. The former problem can’t be entirely eradicated, but it can be mitigated as the team gains more experience in estimating. The latter problem, on the other hand, can be dealt with via some clever techniques that have evolved over the years. The first and most commonly used is known as planning poker. When used by an in-person team, the person running the estimation meeting reveals a work item and asks each team member to give an estimate of how much effort the task will require. Each member has a deck of cards (or sticky notes or whatever) with Fibonacci numbers on them, and they simultaneously show their choice. They do it at the same time, rather than one by one, so that no one gets anchored on a particular number. If I go first and vote that an item will require thirteen points of effort, everyone else is likely to be influenced by my choice. If everyone’s choice is revealed simultaneously, however, each person can make their own judgement call. When there’s general agreement about how hard something is (i.e., we all vote three or five), we don’t need to discuss or debate it. The facilitator marks the level of effort with the most votes, and we move to the next item. Only when votes range wildly—that is, one person votes two and another votes thirteen—do we stop and discuss the work in greater detail. This approach lets us size a large amount of work quickly and (relatively) painlessly.

Planningpoker.com achieves a similar objective for virtual teams. Work items are loaded in advance and shown to team members via the website’s interface; each person then votes on how much effort they believe is involved. No votes are shown until everyone has voted. At that point you can see if there’s consensus about size or if discussion needs to happen. In both versions, in-person or virtual, teams who use planning poker can quickly estimate a high volume of work without debating every item individually.

Another option, known as affinity estimation, requires everyone to be in the same room. You create a sticky note for each potential work item, and then ask the entire team to move them around, ranking them in order from smallest to largest. They do this silently, again to avoid anchoring on a particularly vocal or persuasive team member. Each person can touch each sticky note as many times as they want. As with planning poker, the idea is to avoid talking about every single item. Those that nobody is worried about—the ones that get placed somewhere on the spectrum right away and are left alone— don’t need to be discussed. Only those that keep getting moved around by two or more people require a debate.

After we have an agreed-on order, it’s time to assign Fibonacci numbers. Each number in the sequence gets its own new sticky note, and then the team puts the sticky notes containing the work items into the category they believe best represents the item’s level of effort. Tasks on the left or small end of the spectrum will go into the one, two, three, or five list, while those on the right are more likely to land in the eight, thirteen, or twenty-one lists.

As with the first step, the team proceeds in silence and can touch each sticky note as many times as needed. When agreement happens quickly, we assign the number and move on. When disagreement is clear, we can discuss the differing opinions and come to a compromise. I’ve seen a room of more than fifty people estimate over a hundred work items in half an hour this way. It’s a remarkably efficient means of estimating without losing hours to the process.

As a final note about estimation, avoid the temptation to streamline the process by designating a team lead or other individual as the estimator. No single person knows everything about how work gets done. You’ll obtain much more accurate data by allowing the team— the people responsible for accomplishing the tasks—to estimate the effort required.

There are a couple of exceptions to this rule. The first is when an item is very specialized—that is, only one person on the team will be doing it. We can rely on the subject-matter expert to estimate the effort required without taking it to the larger team. The second is when there’s a potential discrepancy in effort depending on who’s doing the work. For me to design and create a landing page from scratch would entail effort akin to running a marathon, but for my husband, who’s an expert in development and user experience, to do the same would be a simple stroll around the block. Getting a variety of perspectives on estimation can help normalize these differences, but at times you may need to know who’s responsible for doing the work before you can accurately determine how much effort will be involved.

Shared Practices: Rimarketing Meetings

Once the team has accepted and estimated work, it’s time for them to focus on getting it done. Whether you have perfectly T-shaped people who could work on anything at any time or a team of highly specialized unicorns, you need meetings to keep things moving along. Because of its emphasis on enhancing focus and limiting work in progress, Rimarketing strives to eliminate as many meetings as possible. The ones that remain have clear objectives, and in fact they take the place of many traditional professional get-togethers. A few types of meeting happen only during the iteration phase of work, but several are common to both phases. We’ll cover those four here.

Meeting 1: Daily Standup

Daily standup meetings are common across most (if not all) Agile frameworks, because they’re one of the most powerful tools for removing impediments, increasing collaboration, and speeding up any sort of process. The problem is they’re also easy to get wrong.

Traditional daily standup meetings happen, as you might imagine, every day. They last up to fifteen minutes, and every attendee should be standing to encourage brevity. Many Agile teams focus their standup conversations around three questions:

1. What did I do yesterday?

2. What do I plan to do today?

3. What impediments are in my way?

There’s nothing wrong with this format per se, but if you follow it over and over again it can get a little stale. That’s especially true for specialized marketing teams, where my work as a copywriter may or may not overlap with my teammate’s work as a martech specialist. In those cases listening to my seemingly endless update about word count and edits and revisions may cause my martech colleague to check out. That means she doesn’t hear me when I ask for help, or when I say something that could trigger an opportunity for us to work more closely together.

One of the things that causes these questions to break down over time is when a team comes to rely on them as a crutch. The daily standup meeting isn’t about those three questions. It’s about bringing a team together so that members can support one another as they complete great work in a short amount of time. It provides near-realtime visibility into progress and roadblocks so that both can be addressed rapidly and meaningfully. It reveals previously unknown ways for team members to work together.

If the three questions are serving your team and getting the results that standup meetings were made to deliver, then by all means use them as long as they’re effective. But if standup has become a fifteen-minute daily death march, then it may be time to switch things up.

One option is to focus on the visualized workflow or kanban board rather than on individual updates from team members. A facilitator can use the board to discuss items that have changed status since yesterday (what got finished, what new work was started, what got blocked or unblocked). Individual team members chime in with questions, comments, and context as needed, but they refrain from detailing the minutiae of their day. The danger here is that detail gets omitted and opportunities for collaboration lost, but in specialized groups this may be the antidote to boring standups where nobody pays attention to anyone else’s updates.

It’s also vital to keep people on track during the standup. No meandering stories about pets allowed. Designate someone to run the meetings (it might be the team lead or rotating members), and keep participants focused on the conversation at hand. One team chose a code word to indicate that someone was getting off track, and anyone on the team was free to shout it whenever a team member lost focus during standup. Cries of “Squirrel!” often rang out from their area of the workspace each morning. That may be all you need to keep people on task.

Whatever strategy you devise, don’t let standup deteriorate. Done well, standup can be the engine that drives continuous improvement across the team and its work. Neglected, it can be the first crack in a long descent into irrelevance for the Agile system the team has worked so hard to build.

Meetings across Multiple Teams: Scaled Daily Standup

In larger Rimarketing organizations, daily standup often needs to scale beyond a single team. If two or more execution teams are coordinating their efforts, if handoffs occur among teams, or if subject-matter experts need to be dynamically reallocated, then a scaled daily standup can be enormously helpful. Regardless of the driving factors, the meeting proceeds much the same way.

Ideally, the scaled daily standup happens right after the individual teams’ standups, so any issues that were raised can be addressed as quickly as possible. If teams hold standup at 8:30 a.m., the scaled daily standup could start at 8:45 a.m. When there’s a high degree of volatility or high demand for speedy completion in a group’s workflow, the scaled meeting should happen every day. Some groups where things don’t get done quite so quickly may be able to hold the scaled daily standup two or three times per week.

Once a time frame is settled on, team leads from each connected team get together and discuss the following:

• ■ what their teams have accomplished since the last meeting

• ■ plans for what will be done before the next meeting

• ■ any problems that negatively affect their team’s productivity

• ■ possible impacts of their team’s upcoming work on other teams

• ■ feedback on how other teams’ work might affect them

As with regular daily standup meetings, face-to-face meetings for the scaled daily standup are strongly preferred. Failing that, video can come in second, with phone a far distant third. Also like daily standups, a well-run scaled daily standup can unblock the flow of work and create previously unknown opportunities for collaboration across teams. You might be amazed to discover how much help becomes available when you allow for recurring moments of face-to-face interaction.

Meeting 2: Queue Refinement in Two Flavors

No matter its structure, the kind of work it does, its size, or its industry, every Rimarketing team shares the same engine: a queue. Analogous to the backlog you may have encountered in other Agile frameworks, the queue shows the team what tasks are most important for them to work on at any given time.

However, although the queue drives the team’s work, maintaining the queue is not its job.

Part of the reason we distinguish between the What and How Cycles in Rimarketing is to free individual contributors from the mental load of both getting work done and determining whether the work they’re doing aligns with larger priorities. If team members can focus exclusively on creating work of the highest possible quality, they’re more likely to deliver outstanding results.

As discussed before, the team lead owns this part of the Rimarketing system: ensuring that the team can clearly identify and execute the highest-value work at all times. They can do this in a couple of ways: through continuous refinement or recurring meetings.

Option 1: Continuous Refinement

If your team lead can manage this approach, it’s typically the most beneficial. As the name implies, the team lead constantly takes in new requests and prioritizes them against the work that’s already in the queue. Some new items will make it right to the top of the list, while others will fall lower. Some will be rejected outright if they don’t align with the execution team’s focus or core KPIs.

As the team completes tasks, new items make their way to the top, and the team lead ensures that high-priority work is ready for the team to tackle. The team lead conducts fact-finding meetings, gathers requirements, liaises with stakeholders, and otherwise maintains the queue.

Team members aren’t pulled into excessive numbers of meetings, nor do they spend hours each week navigating the political landscape and negotiating which tasks will be completed first. The idea here is not that the team is incapable of making such decisions, but rather that their time is more valuable when it’s devoted to getting things done.

On the flip side, although we want to free the team from queue management whenever possible, that doesn’t mean the team lead never consults team members. If the team lead doesn’t fully understand a work item, can’t decide how much effort a task might take, or is otherwise unsure how to proceed, they can always tap into the subject-matter expertise of individual team members. The important thing is to avoid overburdening the team.

In the continuous refinement mode, all of this happens in real time, meaning the queue is in a constant state of flux. Such an approach typically lends itself to the flow state, but it may be used during iteration as well.

Option 2: Regular Refinement Meetings

An alternative to ongoing refinement is to schedule recurring meetings to review, analyze, and reprioritize the queue. During iteration it’s easy to set these up to coincide with the beginning of an iteration; during flow the team lead can create whatever cycle makes sense for the team’s needs. Ultimately the schedule will depend on the team lead’s efficiency (and how long it takes them to hunt people down), as well as the level of volatility in the work the team needs to complete. If stakeholders are habitually absent, or if priorities change often, queue refinement will probably need to happen every week or every other week to keep it current. If, on the other hand, gathering requirements goes smoothly and the team can predict what it’s likely to be doing in three or four weeks, a monthly queue refinement session may be sufficient.

As with all aspects of Rimarketing, we strive for continuous improvement. Don’t expect to nail the schedule the first time; be prepared to adjust it as you learn more about where the refinement bottlenecks are.

Queue Pro Tip: Balancing Urgency and Value

The most important factor in prioritizing the queue, regardless of how often that happens, is determining what work will deliver the most value for the customer (however you define “customer”). Work items with clearly defined and documented value should be completed first. Those with less certain outcomes fall down the list.

The exception to this guideline, of course, is when work comes with an immovable deadline. Sometimes deadlines are self-imposed, such as when you sponsor a conference. Booth components have a delivery deadline. Logos must be submitted on time. If you fail to book rooms on time, attendees won’t have anywhere to stay. The list of tasks to accomplish is long, and none of its components are flexible. At other times, the deadlines aren’t of your making, such as when sales suddenly books a demo with a massive potential client and you need to support them with custom collateral. In either case, urgency trumps value.

This is a reality of marketing work, and it should be reflected in the state of the queue. The team lead needs to be an expert in managing this balance, ensuring that work happens in the responsible window rather than the urgent window. In the responsible window the team remains in control of its workstream. They have deadlines, but they’re able to incorporate them into high-value activities. In the urgent window they have to drop everything to tackle a task that’s on fire. No matter how valuable another piece of work might be, it will be neglected while the deadline takes precedence.

Some Agile marketing teams have internalized a common rumor that Agile systems shouldn’t take deadlines into account, but Rimarketing recognizes that this black-and-white mentality is simply unrealistic. The queue is designed to create visibility around both value and urgency, allowing the team lead to make intelligent tradeoffs that keep the team flowing smoothly while delivering on time.

Meeting 3: Stakeholder Interactions

Marketing is never an autonomous department. We’re connected to nearly every other function inside an organization, which means we have to manage a lot of different stakeholder interactions. These touch points might be as simple as a salesperson requesting an updated one-sheet, or as complex as timing marketing campaigns with a major product launch. In both cases (and all the others in between), Rimarketing teams need to connect with other groups. This remains true whether the team is in iteration or flow.

A delicate balance must be struck here: we don’t want to sidetrack the team with excessive meetings, but nor do we want problems to go unnoticed because we’ve lacked enough face time with partners. As if that balance alone weren’t hard enough to manage, it’s also likely that different stakeholders need different levels of interaction. And those levels may fluctuate from team to team.

Due to these complex factors, rather than create a prescriptive set of requirements for who a Rimarketing team should meet with and how often, in Figure 28 I provide a tool that each team can use to create its own preferred cadences.

The team labels the outer circle of the canvas with the least frequent interaction schedule they want to follow. In this example, it’s labeled for quarterly interaction; for other teams it might be once a month. The label should equal the longest amount of time a team is comfortable going without talking to a stakeholder group.

The center circle contains the most frequent interaction schedule they’d like to have with a group. Usually that’s daily (often at the daily standup meeting), but some teams may decide that’s too often. Each circle in between gets labeled with a time period between the shortest and longest increments.

FIGURE 28
Stakeholder Interaction Canvas

Rimarketing Framework^® AgileSherpas.

Next, it’s time to decide which groups go where on the concentric circles. Each group has its own symbol for easy visibility; you could also use different colored sticky notes. In the completed version above, the team has chosen to connect with sales only once per quarter, but they’d like to touch base with someone from product management, the business units, and their agencies everyday.

For teams with relatively low levels of external interaction requirements, the canvas can act simply as a reminder of how often they need to be talking with different groups. However, for teams who spend a large amount of time managing stakeholder relationships, the canvas may serve as a visualization tool to reveal these high coordination costs. When a leader from another team swoops in and asks for a recurring weekly meeting to “check in with the team,” the canvas quickly displays the impact such a cadence would have, and how many other meetings the team is already committed to.

In such cases, a team might create two versions of the stakeholder interaction canvas, one that represents the current state and one that shows the future state they want to move toward. The team lead can then work to change the frequencies to align with the team’s preferences. Sometimes that means reducing the cadence (no need for daily chats with the business units after all), and at other times it means increasing it (if we could talk with legal more than once a month, we’d get more done).

Regardless of how you use the canvas, I recommend documenting each individual team’s interactions on it. Per the Rimarketing principle of transparency, it helps to surface potential issues while also keeping the teams accountable to the groups they need to interface with.

Meeting 4: Retrospectives for Continuous Improvement

The core Agile meeting known as retrospective, or retro, allows the Rimarketing team to deliberately pause to reflect on their process. Too often we fly from project to project without taking time for inspection and adaptation; the retro is designed to counteract that tendency.

Retros are for the Rimarketing team only; no leadership or stakeholders should join. We restrict attendance to create an open environment for the team to have frank discussions about their current ways of working. There’s nothing like having upper management in the room to shut down honest conversation.

If the queue is the engine of a great Rimarketing team, retros are the tune-ups that keep the system running smoothly. In the early days of a team’s creation, it should meet every two weeks to talk about improvements in process. More mature teams may be able to hold retros slightly less frequently—say, three weeks apart. Going any longer risks degrading people’s memories of what really happened at a process level. Details can fade, making the retros less effective if too much time passes between them.

Don’t cut corners on retro meetings by allocating too little time for them. Plan for the team to spend at least a full hour in a room together. You may be tempted to “free up some time” by cutting retros short, but you need to create plenty of space for conversation to ramp up and keep flowing. The end of the day is a great time for a retro, especially if you bring snacks and turn it into a bit of a party.

However the discussion proceeds during the meeting itself, make sure your retros produce concrete action steps that the team will take to address the problems and opportunities that come up. There’s nothing more disheartening than rehashing the same topics week after week after week because change hasn’t occurred. If needed, create new items to include in the team’s queue so the team lead can prioritize the team’s chosen improvements alongside its other work. Select a scribe for each retro who’ll capture the most salient discussion points, action items, and owners of those items to ensure that the meetings lead to action.

Finally, team leads should be prepared to guide the retro, especially when the team isn’t yet familiar with the meeting or its purpose. Some common formats for kicking off a retro are to ask the team to think of events from the past two weeks and place them into predetermined categories. Sample categories include Stop/Start/ Continue (what should the team stop doing, start doing, continue doing), Liked/Lacked/Learned/Longed For, and Mad/Sad/Glad. Allow individuals to brainstorm quietly for several minutes before opening the floor to discussion. (Introverted team members will be deeply thankful for this time.) Each team member creates a sticky note for each event or idea and places it in the appropriate category. Then the team lead can walk through the items, guiding the team through group discussion.

If a team lead isn’t experienced in running this kind of meeting, I strongly recommend the book Agile Retrospectives, by Esther Derby and Diana Larsen, for a nearly endless source of ways to keep it fresh.

The Execution Team in Flow

Now that we’ve established a few best practices, we’re ready to dive deeper into the Rimarketing execution team’s default way of working: continuous flow. The easiest way to understand a team in flow is to follow one through its typical activities, so that’s how this section is structured.

We’ll begin at the start of a new quarter, when the execution team has just returned from its big-room planning session. Following that meeting they should have a prioritized project-level queue, but it doesn’t yet incorporate their business-as-usual work. Remember that items in the BRP-generated queue can be completed by a couple of people in a couple of weeks. The team will need to break them down into smaller parts and add their BAU items. Execution teams can determine how often they want to do this activity when in flow, and their decision will likely depend on the volatility of their environment and the speed with which they accomplish their work.

Some advanced teams can do just-in-time (JIT) planning. That is, whenever the team gets ready to start a new, large project, they hold a quick meeting to divvy up the tasks. Less mature teams, or those that lack experience with the work they’ll be doing, will want to hold regular planning meetings in which they task out items in the queue that they plan to start over the next few days. They might even break things out for weeks in advance, though this is the exception rather than the rule. Each execution team employs slightly different timing for queue refinement and planning while in flow, so be prepared to experiment. Start with planning every week and see how that feels, then discuss it during a retro and adjust as needed.

Now is also the time when each member of the team incorporates into the queue any BAU work they’re responsible for, and the team lead helps to ensure that it’s appropriately prioritized against project work. To be frank, this aspect of planning can be time consuming and a bit tedious at first, but it’s an important part of the Rimarketing principle of radical transparency. Taking the time to get everyone’s work out in the open can reveal previously unseen time-sucking black holes, which the team lead can help to mitigate or remove.

As a bonus, once all the work is visible, it becomes far easier to show stakeholders and marketing leadership how busy people really are. As requests come in, you can ask that they be prioritized against the full scope of a person or team’s commitments rather than just the project work.

A Typical Day in Flow

Once the team has a quarterly queue that’s been broken into manageable pieces, each person will take a look at it. They’ll select the highest-priority item they’re able to work on, attach their name to it, and get started. Early in the day—let’s say at 9:00 a.m.—the team will have its daily standup meeting.

Since the team has just started a new round of work, members won’t have anything to report about the prior day’s activities, but they will share their plans for the upcoming twenty-four hours. Any predicted dependencies or handoffs among team members may also be discussed, for example, “I’m doing the copy for this landing page today, and I’ll have something to work with design on tomorrow.” This micro-cycle continues each day while the team is in flow. Team members pull work when they have capacity, work on it independently or with other team members until it’s done, and then move to the next item in the queue.

If you have a team of specialists, tasks may be completed mostly independently, with occasional moments of collaboration. On a more cross-functional team, the balance will tip the other way, with very little solo work and more shared effort. Either way, daily standup meetings keep everyone in sync, ensure timely collaboration, and help people address impediments that come up. Assignments may get blocked, which should be noted in a visible way, but even when that happens plenty of activities should still be available for all team members. WIP limits should ensure a steady flow of work through the team from day to day.

In a larger Rimarketing system—that is, one with three or more execution teams—the team leads will also meet daily with the strategy group. This meeting happens after the scaled daily standup (introduced earlier in the chapter, and which takes place following each execution team’s standup). The team leads convey to the strategy group pertinent information from their teams’ standups, escalate any major hurdles the team is encountering, and coordinate efforts with other team leads.

Note that team members are pulling work when they’re available, rather than being assigned work by the team lead. Additionally, if items in the queue need to be broken into smaller chunks and owned by different team members, it’s up to the team to take care of that. They may need a weekly planning meeting to do so, which is typically a good Monday morning activity. It should be a relatively quick meeting (an hour should cover a week’s worth of work) that allows everyone on the team to pull items from the queue without wasting time investigating what their part of a larger project needs to be.

Incorporating Subject-Matter Experts and Reviews

Wrinkles are likely to crop up that will need to be addressed within this cycle of continuous flow. One such wrinkle is the incorporation of subject-matter experts (SMEs). Most marketing departments aren’t perfectly resource balanced, meaning they have a handful of people that many teams need access to but whom nobody needs all the time. These individuals’ roles vary widely from one organization to another, but common SMEs include search-engine optimization (SEO) specialists, content strategists, and editorial reviewers. Regardless of who your SMEs are, they need to be incorporated into the Rimarketing flow.

The weekly planning session described above is crucial to ensuring that SMEs are available when the team requires them. Likewise, if they’re in high demand across multiple execution teams, the scaled daily standup is there to allow team leads to negotiate SME time while minimizing waste and waiting and avoiding overburdening the SMEs.

As work proceeds within flow, the execution team will want to periodically obtain input and feedback from the strategy group through review meetings. Depending on the project, some execution teams will require such meetings more frequently than others. For example, an execution team exploring an emerging channel, targeting a new persona, or otherwise working on something new may want to check in with their strategy group every week. An execution team that is supporting events may have their process dialed in and need far less input. They may request a strategy group meeting every three weeks. Each execution team will establish their own meeting cadence, and the strategy group should honor the request unless they have a good reason to question it. In that case, their concern can be aired at a retrospective meeting or communicated to the team lead, who can discuss it with the execution team. Ultimately, aim to establish sufficient oversight around strategic alignment, brand compliance, and other long-term interests without babysitting the execution team or slowing down their ability to get work done.

Improving Flow by Eliminating Meetings

Strategy group reviews, in conjunction with daily standups and the visualization of work via a kanban board, should replace all status meetings. No execution team member should be pulled out of their daily work to provide an update on how that work is proceeding. If the board fails to communicate status with enough specificity, a request for further detail should go through the team lead. Having just attended a standup meeting, the lead should be able to provide the necessary insight. Excessive meetings are some of the biggest wasters of time in modern knowledge work, and Rimarketing strives to eliminate them whenever possible. All meetings have a clearly defined purpose and happen as infrequently as is feasible.

Sometime in the last decade or so we began to equate our level of importance with the number of meeting invitations on our calendars. Many teams I coach tell me they have literally an hour per day to actually work; they spend the rest of their time in meetings. This isn’t acceptable, productive, or pleasant, and Rimarketing is designed to clear calendars so that real work can happen.

If you’re currently operating in a culture that equates busyness with importance, you may have some work ahead of you to disentangle activity from value creation. Accomplishing tasks that serve our customers and audiences (and supporting our teammates in doing the same) makes us productive team members. Sitting in hour after hour of meetings does not.

One meeting that does still need to happen is queue refinement. As the team proceeds, their queue needs to stay updated so that they (1) are working on the highest-priority items at all times, and (2) have all the information they need to execute those tasks. The team lead is responsible for ensuring that the execution team’s queue is current. Some team leads know enough about the organization and the execution team to refine the queue independently. They’ll do it on their own time. Other team leads lack specialized knowledge about everything an execution team works on, which is very common in teams that tackle a wide variety of assignments. In this case, the team lead needs help from the team to keep the queue current.

When the team lead needs input from the team to refine the queue, they have a couple of options:

1. Weekly refinement: Set aside a particular window of time each week to refine the queue, usually two to four hours, depending on the volume and complexity of work in play. During that period, execution team members know to make themselves available to the team lead to answer questions. The team lead may need to call on individuals either for a quick consultation or for longer. Either way, members of the execution team are not required to sit in an hours-long meeting when their input may be required for only ten minutes.

2. Just-in-time refinement: Refine the queue in a JIT fashion, conferring with execution team members as needed. In this scenario, the team lead is refining the backlog almost constantly. Whenever a new request comes in, they compare it to the existing contents of the queue and place it where it belongs. As work moves closer to the top, the team lead sets up meetings and gathers requirements. To do all of this in an organic, real-time way, the team lead will likely need to tap into the expertise of various team members. The daily standup should offer an ideal time to let team members know when they’ll be called on to contribute so they can adjust their plans accordingly. As with weekly refinement, some people will need to spend an hour or more helping the team lead, while others may need to answer only a few quick questions.

TABLE 4
Rimarketing Activities Handled in Flow

Whatever system a team lead uses, the important thing is for individual contributors to provide their unique insight when it’s required without being overburdened with unnecessary meetings.

Table 4 summarizes the Rimarketing activities typical of the flow state.

Specialists versus Cross-Functional People

As you can imagine, flow can be easily interrupted when the execution team is made up of specialists. When only one person can perform a particular function, the process gets disrupted when that person is out of the office, too busy to help, or otherwise unavailable. Things proceed more smoothly with cross-functional team members (the T-shaped people we met in Part Two).

Many marketers were hired for their specializations, and they may resist the push to generalize their skill set, but a team can go faster if it consists of individuals who possess abilities the team needs. Remember that not everyone needs to be an expert in everything; basic knowledge that allows someone to lend a hand is often enough to keep tasks moving forward.

The Execution Team in Iteration

From time to time, an execution team may choose to pause its flow and move into a more iterative style of working.¹ While in the flow state, team members choose high-priority items from the queue, complete them, and move on to the next ones. Their queue is regularly refined and replenished by the team lead, and they conduct retrospectives to inspect and adapt their process. As the term implies, a team in flow delivers work in a continuous, uninterrupted flow. They are prepared to take in work at any time, reprioritize often, and generally go with the flow of their professional obligations. Situations may arise, however, when the team no longer wants to accept this constant change, when flexibility needs to give way to focus. At that point the team moves into a phase of iteration.

Iteration is a distinct way of executing work that begins with a planning meeting, during which the team determines:

1. the length of their upcoming iterations

2. what work needs to be accomplished before the iterative stage can be considered complete

3. how many iterations are required to complete the work (an estimate that the team is free to adjust as they go)

The iteration phase consists of a series of consecutive iterations, during which the team focuses on a small amount of work. This is a different method of limiting work in progress, one that forces the team to narrow its scope for a brief time. The iteration plan outlines what the team needs to accomplish, and they do their best to stick to it until the iteration concludes.

Iterations work best when they’re short (between one and three weeks), because even when the execution team locks down to focus on set tasks, they don’t want to prevent themselves from being able to respond to changes for too long. A six-week iteration means that all external requests and reprioritizations will be put on hold for that time, which can feel like an eternity if you’re a sales team that needs marketing’s help for a project.

If you’re unsure what the length of your iteration should be, start with two weeks. You’ll get a feel for whether you should adjust up, down, or not at all for future iteration phases. But whatever length you choose, it should stay consistent throughout the iteration phase. Keeping the length the same allows the team to accurately estimate how much they’ll be able to accomplish from iteration to iteration; if the length changes, the team won’t be comparing apples to apples.

As mentioned, the iteration phase begins with the first planning session. The team gathers to decide what they’ll commit to completing during their first iteration. They examine their queue, paying particular attention to whatever project, campaign, hurdle, or other obligation sparked their entrance into iteration, and decide how much they can and must accomplish in the next couple of weeks.

Whatever you do, don’t skimp on planning time! The team needs to commit with accuracy and confidence to their plan, which means they need ample time to hash out details and dependencies before jumping into the work. A good rule of thumb is to allow one hour for every week of the iteration; thus, a two-week iteration will take about two hours to plan.

By the end of the planning session, the execution team will have built an iteration queue, which will serve as their guide for what needs to get done during the iteration. Their larger team queue still exists, and it can continue to accept work and be rearranged during the iteration. The iteration queue, however, is static once the execution team commits to it. The purpose of entering iteration is to create the conditions for effective, focused delivery, which means the iteration queue should be locked down. The team lead can accept new requests in the main queue, but only unavoidable emergencies should disturb the execution team in iteration.

Table 5 summarizes how a team’s activities are handled during iteration. Take a moment to compare it with Table 4, “Rimarketing Activities Handled in Flow.”

If the execution team will be moving through two or more consecutive iterations, it can be helpful to pause between them for a retrospective meeting. Like the retros that take place during flow, this session lets them discuss the outcomes from earlier iterations, making adjustments as needed to improve their performance going forward.

TABLE 5
Rimarketing Activities Handled in Iteration

The stakeholder reviews discussed earlier should almost always pause during an iteration. Setting this limit allows for greater focus within the iteration by eliminating a meeting. To continue aligning with larger strategic goals and obtain timely feedback, the execution team conducts a more formal review session after each iteration. They also conduct an overall review when all their iterations (and therefore the project they needed to focus on) conclude.

Analogous to a software demo, the iteration review provides an opportunity for the execution team to reveal the output of their focused work. There’s no need to spend hours creating beautiful slides for this meeting; its contents should consist of whatever the execution team produced during the iteration. Stakeholders, internal partners, executives, and anyone who may need to use the execution team’s output should attend. The review is the time to learn everything about what the execution team committed itself to executing, making it a very important meeting.

Differences between Flow and Iteration

As you can imagine, many differences exist between an execution team in flow and one in iteration. Rimarketing envisions flow as the primary state, so it’s where you’d expect to find the execution team most of the time. While in this state the team flexes and adapts on a daily basis. Their queue is refined often as new requests come in and are prioritized. Team members grab high-priority items, work on them to completion, and then proceed to new tasks. Low WIP limits keep work flowing smoothly. Stakeholders and marketing leaders both have regular touchpoints with the team.

In iteration, the vibe of the execution team changes. Something has come up to demand their focus, and in some respects they close ranks, restricting the access of outsiders. They commit their time and energy to a small subset of the tasks in their queue, and they work diligently together to get them done. Other items take a backseat. They continue holding their regular retrospectives and daily standups, but they may suspend sessions with the strategy group and external stakeholders.

The iteration phase, because it’s infrequent and occurs only in times of serious focused effort, should be respected by those outside the execution team. In its usual state the execution team takes incoming requests freely, incorporating them into its queue and flowing rapidly through assignments. Iteration happens rarely, and outsiders need to allow the team to move into it and remain there when the team believes it will be the best way to complete important work.

The events that trigger a move from flow to iteration are many and varied. In essence, the execution team needs to enter iteration when they encounter work in their queue that is:

• ■ Unusually large: Running a user conference, supporting a product launch, or drafting a new content strategy would all qualify as substantially larger than the work marketing teams typically do. Each of them might warrant a series of iterations to create the right conditions for focused execution. The caveat here is that even when iterating on large work items, the team needs to break the work down into smaller, manageable pieces that can be completed rapidly. Otherwise the team risks slipping into old waterfall styles of project management that won’t support the rapid delivery that modern marketing demands.

• ■ Complex: Almost every execution team has items in its queue that are more complicated than others. These complex tasks may require a lot of agency support, involve multiple channels, or demand coordination with other execution teams. Whatever their exact makeup, complex assignments can be easier to deal with in iteration than in flow.

• ■ Unknown: When I help marketing teams learn about iterative work, I use a simulation that involves folding origami fish. There’s almost never anyone in class who’s an expert in origami; iterations are therefore the best way to handle this unfamiliar task. You probably won’t do origami as part of your marketing efforts, but if you encounter an unknown it may be time to circle the wagons and iterate until your execution team figures it out.

• ■ Urgent: This one is the most obvious. You may only need iteration to handle an urgent work item if it also meets one of the other criteria on this list. A task that’s merely urgent could quite possibly be tackled by an execution team in flow. The team lead moves it to the top of the queue, where someone grabs it quickly and works on it to completion. A team might even break its usual WIP limits to address the urgent item right away rather than waiting for capacity to open up in the system. Whatever the tactics used, many execution teams can handle work that’s urgent without breaking into iteration. If the assignment is both urgent and complex, unknown, or large, then iteration is the way to go.

You’ll notice that the first three criteria have something in common: if handled within flow, work that meets these conditions has the potential to take a long time. In traditional project management, new, complex, large projects are notorious for dragging on. They miss deadlines, go over budget, and otherwise fail. A good execution team should deliver early and often in flow, but work that falls into the above categories calls for deliberate focus to save it from the typical fate.

Measuring Rimarketing in Flow and Iteration

Regardless of what state an execution team is in, it needs to be aware of how it’s performing. That means tracking effectiveness at two different levels: process and marketing. Process-level metrics tell us if Rimarketing is doing its job—in other words, if the team is getting more done in less time. Marketing-level metrics measure the same things we’ve always measured (or at least should have always measured). They indicate whether the execution team’s activities provide the expected outcomes.

Measuring Process

There are two primary methods of measuring process: cycle time and throughput. An execution team can get away with tracking only one, but keeping an eye on both improves predictability for upcoming work.

Cycle time is simply how long it takes a work item (something from the queue) to make it through the execution team’s entire workflow. Said another way, how much time passes between when the team starts on a task and when they finish it? Most digital tools, both the Agile and the traditional project management variety, should have this capability built in.

If an execution team is using good old-fashioned sticky notes, they jot down the date when they started an assignment and then the date they finished it. Their cycle time is the difference between the dates. So if a team started a task on Tuesday and finished it on Friday of the following week, they had a cycle time of nine days (we don’t count weekends, because after all we’re supposed to be working at a sustainable pace). See Table 6 for other examples.

TABLE 6
Cycle Time Measurement

I like measuring cycle time because it smooths out some of the variability that comes with marketing work. Certain small items, like writing a weekly blog post, never take long. Others, like drafting a new content strategy, take far longer. Cycle time lets us embrace these different scales without getting caught up in making every item in the queue the exact same size. After tracking cycle time for several weeks, we can reach a meaningful average that allows us to predict delivery time before we start tasks.

Measuring cycle time helps control for the variations in work, but you can also track the cycle times of different types of work if that data point is useful for your execution teams or strategy group. You might track content-creation tasks in one table and strategic-planning work in another. Then you can compare different types of assignments with more specificity. You could measure an infinite number of things; instead, decide which ones will deliver the insight you need and track only those. If knowing the different cycle times for different kinds of work might be useful, then by all means measure each one. If you can’t imagine what you’d do with that data, or if the team doesn’t work on a wide variety of tasks, focus on overall cycle time.

The second process-level metric is throughput, or the number of items an execution team completes in a set period of time (usually a week). Like cycle time, throughput is agnostic about the type of work. It doesn’t care if the team finished five blog posts and two emails, or three social media campaigns, three landing pages, and one ebook. In both cases the throughput is seven.

This data point is particularly powerful when predicting future delivery for tasks that are positioned lower in the execution team’s queue. If a team finishes about eight work items per week, and a stakeholder asks the team lead about an item that’s twenty-fourth in the queue, the team lead can predict that the execution team is likely to complete that item within three weeks (assuming, of course, that nothing happens to disrupt the order of the queue).

To track throughput, every Friday afternoon the team lead tallies up all the items the execution team completed that week. If the team uses a physical board, doing this simply involves counting what’s in the “Done” column. A digital tool will quickly sort all the items marked as complete in the past week.

Cycle time and throughput work in both the flow and iteration phases, so you don’t have to change the way you’re tracking the execution team if they move into an iteration.

A third—and optional—process-level metric is rounds of revision. It’s most useful for execution teams that depend on external reviews with creative directors, legal, or other groups that are likely to request multiple rounds of changes to the team’s work. This back-and-forth may eat up days, or even weeks, so reducing the number of handoffs can be valuable. If an execution team has gotten stuck in endless rounds of review, you may want to keep track of how often tasks usually get revised. Fewer revisions indicate a more collaborative process, and they certainly indicate gains in process efficiency.

Measuring Marketing Outcomes

As you gain a better understanding of how Rimarketing helps an execution team accomplish more in less time, keep an eye on whether they’re doing the right work at the right time. I can’t give you a blue-print for this part, because every marketing department evaluates success in a different way. But whether your primary success metric is a gain in marketing qualified leads (MQLs), email subscribers, or paid conversions, you want to know if you’re achieving more of it following a Rimarketing rollout.

As mentioned earlier, marketing-level metrics may vary. Even so, you should have in place a few overarching metrics that all execution teams can roll up to. A software-as-a-service (SaaS) company, for instance, might have a yearly goal to reduce churn in its subscriber base. Each execution team might work on smaller metrics, but they should also be able to show how their overall efforts contribute to the larger marketing objective of reducing churn.

As you can imagine, all these metrics bear the biggest impact when viewed from a before-and-after perspective. Ideally, an execution team will take a look at its past performance before undertaking Rimarketing, and then compare it to outcomes following the transformation. If new execution teams were created as part of the Rimarketing rollout, obtain a departmental average for both process- and marketing-level data points. This is the best way to determine the impact of your Rimarketing efforts.

If, for instance, you know that most marketing projects currently take three months to deliver, and by following a Rimarketing pilot a new execution team delivers a similar assignment in just two weeks, you can point to a 6x improvement in delivery time (a common level of improvement for Agile teams). During their pilot efforts, the Agile marketers at CA Technologies reduced their delivery time from two months to two weeks. If a project-based team of eight people typically completes three items per week (I know I’m being generous), but a Rimarketing execution team cranks out twenty-four tasks each week, they’ve achieved a 700 percent improvement in output.

Even if we don’t have the capability to take a before-and-after snapshot of marketing outcomes, we can extrapolate the impact of the easily measured process metrics. If campaigns usually deliver a hundred MQLs, and now we can deliver twenty-six campaigns per year (one every two weeks) rather than four per year (one every three months), we’ve increased from four hundred MQLs per year to twenty-six hundred. If a typical content item provides ten new email subscribers per week, and we can now complete six per week when we were doing three, we’ve doubled our rate of subscriber generation.

Of course, the rapid feedback loops of Rimarketing ensure that even marketing outcomes improve. We have far more opportunities to iterate on our efforts when the execution teams, strategy groups, and leadership team regularly connect. Campaigns and projects come up for iteration more frequently, and each adjustment increases the potential to improve marketing’s impact. Consider the usual marketing cadence. We race around to finish a campaign, hustle it out the door right at the deadline, and immediately turn our attention to the next thing looming on the horizon. We’re too busy rushing forward to review our past work. In the process we miss crucial opportunities for learning and improvement.

But in a Rimarketing environment, pauses are mandatory. We have regularly scheduled check-ins with our strategy group, who should provide their expertise on campaign metrics and suggest ideas for improvement. Packs connect individual teams every few weeks, so the lessons from one team’s successful (or unsuccessful) campaign can be applied to future efforts.

For instance, the CA team from earlier tripled their win rate for marketing-sourced opportunities and saw a 20 percent increase in their leads pipeline without increasing their budget.

This is where the Agile magic really starts to show itself. More work, less time, bigger impact. That’s the power of agility in action.

Where Do Subject-Matter Experts Fit In?

Before we close the section on practices, we need to talk in more detail about subject-matter experts. These folks are often the thorn in the side of marketing organizations looking to reorganize in a more cross-functional, customer-centric way. The problem comes down to this: if we need to build four execution teams based on stages of the customer journey but we have only one SEO expert, where does that person sit?

Usually there’s more than one SME, and the tendency is to put each of them on all the teams so they can provide insight to everyone. But the moment this happens we’ve put our rapid feedback loops and the focus of individual contributors in jeopardy, because we’ve quadrupled (at least) the inputs for all the SMEs. If the SEO expert is on four teams, she’s got four daily standups to attend. Four boards to monitor. Four queues to prioritize against one another. In other words, she’s in for a huge amount of context-switching and decision-making overhead. She’ll spend far too much time navigating the process and not nearly enough adding value with her expertise.

This inequitable resourcing can be handled in two ways. The first is more common in small to mid-sized marketing organizations with just a few SMEs to manage. In this case the SMEs don’t belong to any single execution team. They’re part of the strategy group only, and the members of the strategy group determine which team the SMEs assist and when. As you recall, the strategy group has a scaled daily standup with representatives of the execution teams that it serves. This is when the strategy group hears the needs of the execution teams and dynamically allocates the SMEs where they can deliver the most value.

It may become clear during quarterly big-room planning that a particular execution team will need to borrow an SME for an extended period of time. In that case, one outcome of BRP might be to send an SME to that team for the quarter, or however long it takes to complete the project they’re advising on.

The second option for handling SMEs works best when you have enough of them (at least four) to form an execution team. In this case they make up their own distinct team, complete with a team lead, who accepts requests into a queue and prioritizes them for execution by team members. When necessary, members of the SME team may join meetings with other execution teams, but often they focus on a flow-centric process that allows them to complete requests from other teams in a rapid, just-in-time fashion.

What Happens when Your Partners Aren’t Agile (Yet)?

One of the questions I hear all the time from new execution teams is how they can commit to improving their own practices when their partners aren’t ready to change. Sometimes that means internal groups (legal, human resources, maybe even product development); at other times it means external partners, usually agencies.

Here’s the thing: Agile development teams have been the lone pockets of agility in many, many organizations for about two decades. They realized that if they were going to have any chance at breaking free of the horrible cycle they were in, they had to make radical changes, and they couldn’t wait for everyone else to get on board.

Marketers, we’re in the same boat now. You can bemoan the sluggishness of business units, stakeholders, and vendors and use their pace as an excuse to avoid change. Or you can commit to doing everything within your power to optimize the things you can control.

Marketing is powerful. Our profession touches customers throughout their engagement with a brand, and we have a unique opportunity to influence the adoption of agility across the organization. Not everyone we encounter will move with our nimble grace. They won’t be as responsive to customer needs. But that’s no excuse for us to turn away from the potential offered by marketing agility.

Take the steps outlined in these pages, and document whatever drag non-Agile partners have on your effectiveness. Once you’ve exhausted avenues for improvement inside your own system (which is likely to take quite a while), you can turn your attention to the external pieces and begin to work through the bottlenecks. Don’t worry— you’ll have plenty to do in the meantime.

1. Scrum practitioners will notice similarities to the Scrum framework in this description. Although based on Scrum, these iterations are designed to be a subset of the team’s activities, rather than continuously recurring, back-to-back sprints. I believe this distinction separates the concept from traditional Scrum, making the usual Scrum naming conventions confusing rather than helpful for our purposes. I also want to help marketing teams think about their agility as a personalized, customized approach and avoid getting caught up in existing terminologies or best practices.