Tag Archives: agile

Partnering With Agile Marketing Teams

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.

flyDevelopers 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.

Agile Marketing

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.

In short, the agile concept makes eminently good sense for marketing, and it turns out that “Agile Marketing” is indeed a thing. In fact, it’s a big thing.

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).

fly4Like 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.”

fly5Notice 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.
  • fly6Sprint 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:

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.

Leave a comment

Filed under content marketing, digital marketing

Convergence: One Year’s Meme

Peter Dorfman Creative Solutions celebrated its first birthday on December 1. It’s a good time to stop and reflect on what I’ve learned from a year as a freelance content creator.

I leverage not only my original training as a journalist but three decades of experience in marketing, implementing and writing about technology. So it’s hardly surprising that most of my content marketing initiatives have been technology-related. It is intriguing, however, to see the way disparate projects with disconnected clients tie back to a common idea, as though companies operating in distinct market segments all are inspired by the same dominant meme.

conferenceIf that’s the case, this year’s meme has been the erosion of the wall between the world of corporate Chief Information Officers and the businesses they serve. The distinction between the rationale for the business and the IT assets that enable the company to execute that strategy is disappearing, as markets, marketing channels and the products sold through those channels all become increasingly digitalized.

“It’s impossible to live in this society and not be inundated with technology,” Barry Libenson, CIO of the West Coast grocery retail chain Safeway, told me in an interview. “That’s the reality, even for a large brick-and-mortar operation like ours.”

A Seat at the Table

I spoke to Libenson in connection with an article for the magazine SupportWorld, published by the customer support professional organization HDI (“Come Together: Business and IT Executives See Their Roads Converging,”November/December 2014). He was describing the preoccupation with the digitalization of virtually every important business process. People of a certain age remember when enterprises could be run by executives who never touched computer keyboards and had admins filter and print out their emails. Such a thing is inconceivable now. For a CIO like Libenson, the result has been that he now has a seat at the table where business strategy is developed, and technology is no longer just an enabling tool but is a core part of that strategy.

My background in IT Service Management (ITIL) and my nodding acquaintance with the software development discipline have led to a series of content projects related to this convergence recently: White papers and two eBooks focused on Agile or Lean development strategies intended speed up the process by which pragmatic business challenges are translated to enterprise software.

Developers have argued for decades that the traditional process by which software is designed, built, tested and deployed is too slow and too disconnected from the needs of the business to be practical. Now, agile development methods by which software is rolled out in small, rapidly developed increments are ubiquitous. It would be unthinkable to develop new mobile apps by anything other than agile methodologies with constant feedback from the business. This is not a fad; it’s simply that these software tools are essential competitive weapons, and that change in competitive markets is so rapid today that there is no way conventional development methods could keep up.

More to the point, however, it is no longer feasible for the business to call a meeting with IT, draw up a set of requirements, and tell the developers to come back in six months with a finished application, expecting it to reflect an understanding of the original business problem. The new reality is that Marketing, Finance, Operations and other business functions must adopt technology developers as trusted partners, invest in bringing the techies up to speed on what the business actually does for a living, and allocate business people’s time to development projects as fully involved product “owners.”

Esoteric But Practical Concerns

Business people also must develop an appreciation for some seemingly esoteric factors that can impact the timing – indeed, the feasibility – of critical development projects. A series of writing projects for Nlyte Software provided an object lesson with respect to the data centers that serve the infrastructure needs of enterprises.

The data center is a huge black box to most line of business executives. They think of it as a remote installation stuffed with expensive hardware that houses their applications. Beyond that, the executives rarely give the data center a thought until some capacity issue becomes a reason why they can’t have some IT enhancement, or can’t get it in the current fiscal quarter. Nlyte markets software that provides advance warning when data center resource issues have the potential to become bottlenecks for business system enhancements.

While IT people are the immediate consumers of the data Nlyte’s tools produce, business people need to develop an appreciation for processes like Configuration Management and Change Management, so that they at least know enough to anticipate that issues like data center capacity could get in the way of a critical business initiative.

The convergence of the business and technology currents in enterprises is a halting, imperfect process. But it is irreversible and it is not just driven by millennials – it is captivating executives at the peak of their experience and their command of enterprise strategy. It seems likely to be an important continuing theme in 2015 content projects.

Is mission convergence a theme behind the products or services you sell into enterprises? Contact Peter Dorfman for help articulating that point to technical and business audiences.

Leave a comment

Filed under content marketing, IT Service Management