Years ago I approached a senior developer at work and asked him what he thought of Agile development methodologies. With a slight smile (Or was it a smirk? We were a Waterfall shop.), he responded that Agile was only useful for Agile consultants and authors. At the time, Agile was still relatively new when compared to waterfall based methods but the number of books, groups and consultants starting to materialize signaled its rapid growth. While the pros and cons of Agile methods may still be debatable today, Agile’s popularity over the past 15 years point to its efficacy for software development.
Without going into too much detail, Agile methodologies (as laid out in the Agile Manifesto) espouse four core values and twelve principles for better developing software. The Manifesto (shorter than implied by its title) is definitely worth a read – even for non-developers – as the values and principles provide sound advice applicable to other business areas.
Recently, marketing and project management teams have adopted certain Agile processes for their use. A burgeoning Agile Marketing LinkedIn Group exists and another group recently published the “Agile Marketing Manifesto”, a take off of the original Agile Manifesto.
Personally, I’ve used Agile Scrum in both development/product management environments and in customer service/operations teams. I haven’t explicitly used Agile with marketing campaigns (yet), but some of the best practices I’ve utilized (like test, launch, measure, review, revise) overlap with Agile values and principles.
As director of operations for a digital signage network operator, I latched onto one of the Agile Scrum processes – the daily scrum meeting (aka stand-ups) – as a great tool to make sure our customer service team stayed focused on improving our KPIs. We met each morning at the same time and quickly answered our own variation on Agile Daily Scrum’s three easy questions:
- What did I do yesterday to contribute toward our goal?
- What am I doing today to contribute towards our goal?
- And what do I need help with/what obstacles do I foresee?
While the daily scrums typically focus on supporting a development sprint, non-development teams still garner benefits from the daily scrum format.
Setting aside time each day for a scrum allows team members to stay focused during the rest of day on individual tasks and provides a disciplined approach to sharing information. Interrupting a colleague during the day to ask a quick question often seems innocuous. But consider recent research findings that it takes the average adult 25 minutes to return to the original task after interruption and you see how dangerous interruptions really are to business success (see Brain, Interrupted, New York Times, 2013).
If you follow the rules of the daily scrum, you start at the same time everyday – no matter if a team member is absent. Many scrums are held standing up, to prevent folks from getting too comfortable and digressing into a meeting. You quickly go around the room and each team member answers the three scrum questions (or some variation of, as mentioned above). If a team member hears something pertinent to their sphere of influence or a team member has a problem you can help them with, you might quickly mention it but generally save it for discussion after the scrum. Again, you don’t want the scrum to turn into a full fledged meeting.
Daily scrums also build trust amongst team members and managers by providing transparency into team member’s work progress. Since team members come each day reporting what they accomplished the day before and what they’re going to work on that day, shirkers can’t hide. You do what you say and say what you do, essentially, so clock watchers and lazy team members aren’t tolerated.
The flip side of the daily scrum is that a daily meeting – even a quick one – can sometimes be too frequent for some projects. I’ve read comments on some developer blogs that point out the daily scrum takes too much time away from busy developers. But I’ve also been part of development scrums with as many as twenty people that took no more than four or five minutes to complete. For operational teams tasked with delivering the same service each day, daily scrums may also be inconvenient for an entire team to attend. In these cases, I suggest trying every other day or at an interval that provides enough transparency without burdening the team.