My years in technology adoption and implementation have led to lots of opportunities to help tech companies market what they build. But it isn’t always easy to predict what experiences will have the greatest value in a marketing context.
I have been involved at several points in my career in field implementation – most recently as a member of a series of “agile development” teams deploying enterprise software. The term “agile” describes a variety of methodologies implementers use to boost their chances of success in projects that stretch out over months or years, have lots of moving parts, and are subject to unforeseen changes and risk factors.
Developers have found that it is foolhardy to try to engineer a large-scale project from the beginning, anticipating everything that will happen to the tooling, the project team, the budget or even the business unit that commissioned the project. Agile teams embrace big objectives, but achieve them by tackling smaller projects in sequence, each delivering functionality that is a component of the Big Vision.
It occurred to me numerous times during agile development projects that this approach would map nicely to all sorts of business processes where the goals are lofty, the team members are interdependent, and lots of external factors can alter the terrain. Marketing, for instance.
Think about it. You want the dominant share of one or more carefully identified market segments. You want to seize that dominance and hold it indefinitely. That’s a big, complex, extended-term goal. On the way there, competitors, shifting customer preferences and product evolution will all converge to change not only the path to that objective but the objective itself.
At any given time, it makes the most sense not to be executing against last year’s macro strategy, but rather a continuously-refined micro strategy incorporating everything your marketing team has learned from the last several micro strategies.
As a freelancer, I engage with marketing organizations every day, and I look for aspects of agility in client organizations. Agility makes it easier to manage a project that is a component of a larger strategy. It is always encouraging to see signs of it in a new client relationship.
An organization may signal its intention to achieve agility by adopting agile development terminology; it always remains to be seen how well the jargon matches up with the actual methodology, but it’s a “tell.”
Teams attempting to talk the talk often draw their terminology from a specific flavor of Agile called “Scrum.” Scrum buzzwords herein will be presented in boldface (to assure the reader that I am not just making these things up for effect).
Like all agile approaches, Scrum tries to reduce the risks in big, complex undertakings by being very specific and concrete about requirements, and by decomposing big objectives into bite-size chunks – tasks and time intervals in which things are done. This approach gives the team lots of opportunities to stop and reflect on how well it is meeting its objectives, what each bit of work product contributes to the Big Vision, and even whether the Big Vision still makes sense.
A Scrum team maintains a master list of tasks and objectives called the Backlog. In software development, the tasks in the Backlog are directly related to building specific, required functional components of what will be the finished application.
Translated into marketing terms, the tasks will be related to specific lead generation goals, product launches, adoption of a marketing automation system, an event, or the release of marketing collateral or a web site.
A development team works its way through the Backlog; the team has a leader, but an individual from the business side (not a developer) owns the Backlog. That person, called the Product Owner, is responsible for making sure the tasks are accomplished and keeping the team and the Backlog aligned with the Big Vision of the business.
Whatever the marketing team decides to call this role, keeping the tactical marketing folks aligned with the CMO’s strategy is crucial.
It is useless, however, to build a Backlog and assign people tasks unless the tasks are drawn from a clear set of requirements. Product designers usually spawn requirements from User Stories – brief descriptions of desired functionality, envisioned from the point of view of a user. A User Story typically is expressed something like this: “As a Business Analyst, I need to generate Weekly Report X as an Excel CSV file, pulling data from Tables M, N and Q, without closing Microsoft Dynamics, by clicking a single button, and have that report available to all PC or Android users in Engineering.”
Notice that the story includes an Actor (Business Analyst), an end product (Report X), timing, and various constraints and conditions. It is not much of a stretch to imagine marketing programs and deliverables in similar terms. Note also that in Scrum, several related User Stories may comprise a larger story, cleverly called an Epic.
Sprinting to “Done”
Tasks, User Stories and the Backlog all are units of scope. Projects are, of course, constrained by budget. The third essential unit of measure is time. Scrum segments projects into short, fixed-length units called Sprints, in which carefully defined portions of functionality will be built to completion. A Sprint typically is two weeks. The team will determine what product features it can reasonably expect to build in those two weeks, and set that as the scope of the Sprint. Complete means delivered – the scope of a Sprint generally includes new functionality the team can actually put in front of the Product Owner and users, tested and working.
This definition resolves a key issue both for software developers and marketing teams: How do we know when we’re “done” with a task or a project? “Done” is relatively easy to define in software; in marketing, an eBook can be objectively finished, but it may be harder to draw a line under the project of which it is a component. Still, agile methodology has advantages over other project management tools in marketing:
- Participants get to enjoy the satisfaction of finishing something – of “winning small” – every couple of weeks.
- Everything is time-boxed. Tasks are not allowed to sprawl, and once the duration of a Sprint is fixed, it can’t be changed. This goes for successes as well as failures. Small failures don’t balloon into disasters.
A Sprint isn’t just two weeks on a calendar. It is structured around four kinds of events:
- Sprint Planning – Scope definition and assignment of tasks.
- Daily Standup – The team meets daily, usually for 15 minutes in the morning, to address status. Daily standups often prevent the need for other ad hoc meetings. Each team member is asked:
- What they did yesterday to move the Sprint objectives along;
- What they plan to do today; and
- What “blockers” might keep them from meeting the day’s objectives.
- Sprint Review – At the end of each Sprint, the team meets to demo or present (among themselves) anything that it completed during the Sprint, and to go over:
- What items for the Sprint got done, and which ones didn’t.
- What went well, what became a problem, and how they solved those problems.
- What Backlog items remain.
- What is likely to come up in planning for the next Sprint.
- Sprint Retrospective – A meeting to assess the Scrum team and ways it can improve itself.
The term “agile marketing” may be new to a lot of managers. But applying techniques like Scrum to marketing makes sense, and a great deal has been written about it. Here are a few more links:
- What is Agile Marketing? (Jim Ewel)
- How to Make Content Marketing Work With an Agile Team (Andrea Fryrear)
- Applying Agile Methodology To Marketing Can Pay Dividends: Survey (Jennifer Rooney, Forbes)
I look forward to engaging with agile teams, either to create work product for a single Sprint or as a outsource partner with an active (open- or closed-ended) role on an agile marketing team. If agile is your inclination, or even if you’re just curious about it, let’s talk.