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
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 LawParkinson’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 LawConway’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.
Conclusion
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?
“… 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…” -spot on. Teams, in it to win it. No one wants to be the one who let his/her mates down. Of course, there are the inevitable and sometimes unknown “tar pits” – true colleagues help the stuck one out and all move on to complete the Sprint.
Good stuff.
Glad to hear you liked the post!
I agree – the teams where people jump in to help each other out are rewarding to work on. It’s something lots of teams talk about, but it’s hard to achieve. The commitment at the beginning of the sprint and the hard end to the Sprint seem to really make a difference in achieving the mentality shift.
Jamie, more than what the literature says is the key role of the friend/colleague in team leadership. They’ve got your back on what you don’t known, are additional eyes and ears and help everyone get on board. Teams are important but special relationships may also play critical roles. What do you think?
Yes, I agree on many levels.
On the teams that I’ve lead, I’ve always tried to be the chief among peers. In other words, the team lead’s job is to produce a vision and inspire others to achieve that vision, and having strong relationships with the individuals that make up the team is important in trying to lead a team that way. I also find that it makes work more fulfilling to know something about the people I work with.
I think the point about people having your back on what you don’t know is important – I found it important in software engineering, but it is even more important now that I’m on a marketing team. Within our larger department consisting of about 10 people, different people specialize in software engineering, relational databases, applied mathematics, statistics, the mechanics of AdWords, evaluating new advertising channels, our internal processes, and keyword research and ad copy writing. Agile Marketing encourages cross functional teams like that, because nobody has the time to be good at all of those things! Teams with diverse skill sets are very productive, and all the relationships between different team members are important in getting such a diverse set of people pulling in the same direction.