Marketing planning has changed little in the past century. It's essentially a linear process built on the development of rigid 12-month plans built around brand and channel metrics. This approach is coming increasingly under strain as the combined effects of the growth of digital marketing platforms and a volatile economy demand marketing plans that deliver clear business outcomes and can adapt and improve to meet evolving market dynamics.
Over the past 12-18 months, we have come across several marketing organizations that have decided to do something about this situation and look for new ways to improve their approach to marketing planning by adopting some principles borrowed from a relatively new methodology originally conceived for software development efforts: agile development.
From the interviews that we did with marketers that are experimenting with this new approach, several of the key principles of "agile" development looked particularly relevant to innovating their approach to marketing planning:
A clear definition of business outcomes and associated business metrics
How many times have you heard the following phrases?
“This software bites.”
“Why is software development always delayed?”
Both sentiments describe the need to design and build software that provides a great user experience (UX) and that is delivered in a timely manner. Luckily, there are two communities focused on both of these goals:
The user experience gang focuses on designing software the users find useful, usable, and desirable.
The Agile camp focuses on delivering working software to expose functionality that users can test.
Complexity is the nemesis of application developers everywhere. While software products' complexity may be, to a great extent, unavoidable, we don't have to complicate software development to match it.
That's the conclusion driving many of the new approaches that app dev teams are embracing. For example, Agile breaks down humongous, complex projects into incremental deliverables that are far easier to scope, build, test, and deliver. Lean practices simplify processes, making it easier for teams to achieve a state of flow. DevOps advocates are trying to eliminate the needless complexities that result from throwing software over the wall from one team to the next.
But there's more to Agile, Lean, and DevOps than just a common enemy. It's no accident that practitioners often speak of this trio in practically the same breath. The Kanban board is the symbol of this convergence of practices. Here's an increasingly common use case: an Agile teams uses a Kanban board to manage work with other groups, including the DevOps team.
The evidence for this convergence is more than just anecdotal. When we survey app dev professionals, they report that they're mixing methodologies all the time, including Agile and Waterfall. For a variety of reasons, Agile teams have made the adjustments necessary to accommodate Waterfall. Not every planning activity at the beginning of a project can be handled in a strictly Agile fashion, and not everyone involved at the end of the project (release management, operations, and business users) is necessarily sold on the idea of rapid, continuous delivery. If you work in a regulated environment, you're required to take extra steps at the beginning and end of a project.
There is growing urgency among eBusiness leaders to consider the impact of agile commerce on customer service. In the weeks since my colleague Brian Walker’s “Welcome To The Era Of Agile Commerce” was published, I have had many conversations with eBusiness executives and leading customer service vendors to discuss on agile commerce’s implications to customer service. The result of these conversations is my recently published document called “The Metamorphosis To Agile Customer Service."
Technology has had a dramatic impact on when, where, and how consumers want customer service:
The number of connected devices is increasing. Today 59% of US online adults have more than one device that is connected to the Internet. One in five US online adults — or 37 million people — own five or more devices that are connected to the Internet. (For more insight into this, see our January 25, 2011m "Welcome To The Multichannel Multi-Connection World" report.)
Consumers are connected everywhere. Mobile phones are nearly ubiquitous: According to Forrester's US Mobile Technographics®, 88% of US adults own mobile phones, and 21% of US adults are Superconnecteds who use their phones for information, research, and commerce.
Fiction writers I've met have said that the hardest section of a novel to write is not the beginning or ending but everything that happens in between. The middle chapters trace the course of the protagonist's struggle in way that must be both engaging and credible. The story of how people adopt Agile successfully also has a beginning, middle, and end. The middle part here, too, poses some of the most difficult challenges. The first chapter is a grabber, with teams energetically and fervently doing daily stand-ups, blazing through sprints, christening a product owner, prioritizing their backlogs, and living through all the other exciting events that happen at the very beginning.
And then the plot takes a different turn. Success at the small team level is fantastic, but how do you fit into a development organization? What if you need to work with an offshore team? How do you maintain velocity when builds take several hours or maybe even a full day? Is it possible to deal with compliance requirements without a significant amount of automation? How do you work better with the ops team so that the speed of deployment matches the speed of development?
Since Agile went mainstream, the number of teams reaching the difficult middle chapters of Agile adoption has increased markedly. Both I and my colleague Dave West answer questions about the middle phases every day. Many of these questions also arise during the yearly conference that the Agile Alliance holds in the US. (This year, it's in Salt Lake City to mark the tenth anniversary of the signing of the Agile Manifesto in nearby Snowbird.)
Leaving Scrum, Sarbanes-Oxley, and related concerns aside for the moment, a hot topic these days in app dev circles is product-oriented development. While teams in IT departments might have different motives than ISVs, systems engineers, or people in other situations, they're all interested in roughly the same thing. What it takes to qualify as a product may not be altogether clear, and there may be no definitive way of measuring whether your team's thinking and behaviors have shifted from project-centric to product-centric. As rough-hewn as the concept of product-oriented development might be, it's still an attractive destination for people coming at it from multiple directions. (Not coincidentally, this is the topic of a soon-to-be-published doc.)
In an unexpected way, many of the app dev teams that have been most successful at dealing with compliance are, as it turns out, acolytes of the product-oriented approach. They may not realize it, as their work output may not be any more productized than it was before. Instead, compliance is what turns into a product.