The developers who gathered in Snowbird, Utah in 2001 to write the original Agile Manifesto represented many different approaches to improving programming productivity: Scrum, Extreme Programming, Dynamic Systems Development Methodology (DSDM), Adaptive Software Development, Pragmatic Programming, etc. Other than rejecting the traditional waterfall methodology, they had little in common. It’s amazing, really, that they were able to agree on anything in 3 days, much less something as crisp and influential as the Agile Manifesto.
Since 2001, Scrum has emerged as the most commonly used Agile methodology, and many of us have applied Scrum to marketing. However, I’ve been asking myself if some of the alternative Agile methodologies can also be applied to marketing. The answer, I think, is yes. Over the next couple of weeks, I’d like to look at several of these alternatives, beginning with Pair Programming.
Pairs programming requires that two programmers sit in front of one computer – one drives, or enters code, the other observes, looking at the big picture, looking for mistakes or for unwarranted assumptions, commenting as the first programmer types. Every so often, they switch roles. The emphasis is on communication and quality.
There is some evidence that although pairs programming may take somewhat longer initially, it reduces the number of defects, and leads to long term productivity. Pairs programming has other benefits as well:
- It improves communication among the team
- It spreads knowledge. If one developer leaves, his partner has knowledge of the code
- It can be used to mentor less experienced programmers
How might this apply to marketing? Can we adopt something I’ll call Pairs Agile Marketing? Imagine a marketing team, divided up into pairs. Rather than having lots of group meetings (something us marketers seem to do a lot of), brainstorming particular marketing programs or deliverables, pairs of marketers divide up, one outlining or even creating marketing programs or materials, while the other looks over his or her shoulder, suggesting improvements, correcting mistakes and generally contributing to the finished product. After 30-60 minutes, they switch off.
The emphasis is on deliverables, not meetings. Quality control is built in. The pairs take a list of stories from the Sprint backlog, and complete them in a timely fashion. They could also use more of a Kanban style methodology to pull the next work item into their pair. Let’s call this Pairs Agile Marketing.
Can this work? I honestly don’t know. We’re going to try it at my office, and we’ll let you know. Has anyone else tried this? Is anyone else willing to try it and report the results?