Agile Marketing takes its inspiration from Agile Development. But why would a set of values, principles and processes developed by software developers for faster, more predictable delivery of computer code help marketers? Aren’t developers and marketers as different as oil and water? Don’t they approach problems with a different mentality, respond to different incentives and perform very different jobs?
While it’s true that developers and marketers are different (although not as different as stereotypes might suggest), Agile Processes can apply to both Marketing and Development because they optimize how people interact and how they accomplish tasks. Let’s take a look at a few common (not necessarily Agile) laws of human interaction and see how Agile addresses them:
Pareto’s Principle, also called the 80/20 rule, says “80% of the effects come from 20% of the causes.” It can be restated in various ways: 80% of the cost comes from 20% of the work, 80% of the value comes from 20% of the effort, and so on.
One result of working in short iterations is that we force stakeholders to make hard choices up front about what work goes into an iteration and what work is cut or deferred. Since stakeholders see the results of the work every two to four weeks, they can stop the team when it has achieved 80% of the value. With waterfall methods, the team works to a plan and continues until the plan is done, even if the marginal cost of the work exceeds the marginal benefit.
Parkinson’s Law states “Work expands so as to fill the time available for its completion.” On a Waterfall-type schedule, this leads to inevitable delays – when the plan calls for spending a week on a work item, the team will spend a week on that item and not finish early. When an item takes longer than planned (and inevitably one will), then the project will be late.
Agile provides several tools to mitigate Parkinson’s Law. First of all, time estimates (whether in story points or hours), are not dictated by the boss and generally not by any single person, but rather by the team. The team exercise, usually taking the form of planning poker, leads to better estimates of task completion, meaning there will be less “extra” time for each item.
Second, during stand ups, teammates commit to completing concrete pieces of work before the next stand up. I have found personally that this commitment, along with the accountability to teammates that comes with it, helps to focus people on what is essential to completing a task.
Third, every team (engineering or marketing) has amorphous, hard to define work. In Agile processes, we use the notion of a “timebox” or “spike” to deal with this sort of work. While not necessarily unique to Agile, research done during spikes is integral to the flow of an Agile team and provide a way of focusing efforts to learn as much as possible and do all necessary vetting of high risk, experimental tasks with large unknowns.
Conway’s Law tells us “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” In engineering, the “system” is the computer system in question, whereas in marketing, it helps to think of the system as the marketing plan. When thought of that way, this is a well-known phenomena in Marketing – companies will have an Email Marketing team, a Paid Search team, a Post-Click team, and so on, and so will have marketing plans that are ultimately disjointed.
Again, Agile has several tools to help attack this problem. First among them is mentality. In the Agile Manifesto, the first line is that we value “Individuals and Interactions” over “Processes and Tools.” Agile puts the emphasis on building teams of people who interact in ways that make sense for a given project. Since having healthy interactions is important, Agile teams discard process that don’t produce results for stakeholders.
Agile also helps teams avoid the tyranny of Conway’s Law by encouraging cross-functional teams. Since the design (either of the system or the marketing plan) needs to be focused around the customer, Agile says that the best way to organize the design of the system (or marketing plan) is to create low-cost communication structures between people of the needed skill sets to prepare and implement the design.
There are other laws of human interaction that I could have addressed, and of the ones I did address, I could have gone into greater detail about the implications of each law for Agile methods. My hope is that Agile Marketing Advocates can see how the organizational behaviors sometimes create natural pain, and Agile processes are a solution to avoiding this naturally occurring pain.
I’d love to know: do your experiences with the above human interaction patterns match the descriptions above? Do they cause your company pain? Have you tried using Agile methods for relieving or avoiding the pain?