Like most practical organizations, our approach was to incrementally adopt the new process. This would allow our team to learn, adapt, and prepare for more widespread adoption. Our pilot "project" was marketing. Marketing is a particularly diverse business function including public relations, advertising, branding, collateral design, event management, and much more. Furthermore, it is multi-disciplinary, interrupt driven, and extremely collaborative. Why start with such a complex discipline? We simply borrowed from a common best practice of "addressing high risk areas first."

We attribute much of our success to our process and correlating culture. Most Scrum practitioners would recognize many of the practices that we adopted. We have daily stand up meetings. We use planning poker for estimations. We have a marketing taskboard. We report using burn down charts. We even know our team velocity. What is not as apparent are the lessons learned that may actually be beneficial to all groups, including software development teams.

Lesson 1: Individuals and Interactions over Process and Tools
The first value mentioned in the Agile Manifesto (www.agilemanifesto.org) is "individuals and interactions over process and tools." Our team quickly discovered the significance of this very important value. For the first several months, our company committed a Certified Scrum Master (CSM) to guide our marketing team and product owner through the process. Overall, this provided an immense value. However, it also presented an early challenge.

As we started to explore the new process, our CSM continuously reminded us of the process, how things should be done, and those things we were doing incorrectly. His intentions were certainly admirable, but the pressure that resulted in moving too quickly from a comfortable business process to Scrum decreased our productivity and created observable team frustration. In fact, a team member openly commented that our Scrum master was "process dogmatic and didn't even adhere to the first value of the Agile Manifesto." In the first few retrospectives when deltas were identified, our CSM would openly challenge our action plans to address them. Much later we actually came to the same conclusions as our Scrum master, but at the time we were not ready to either believe or accept his recommendations.

This experience truly reinforced the individuals and interactions value. Most teams, even those that are eagerly embracing change, require significant time to adjust to new processes. A Scrum master in both business and technical environments should recognize this dynamic and learn to guide teams in a manner that encourages self-discovery. The individuals and teams will have much more ownership if they are allowed to experience the journey themselves.

Lesson 2: Too many meetings - the yellow card
We have all experienced working environments that seem to support too many meetings. In fact, some companies have actually developed "meeting cultures." Marketing is highly interactive and requires coordination with almost every aspect of a business. As a result, there may be a tendency to fall into this trap.

In our early sprints we regularly planned more than we could reasonably complete in two weeks (our standard sprint duration).  Our intentions were always good, but we continued to fall short of our own expectations. During our retrospectives we would revisit our estimations but they always appeared to be fairly accurate. We eventually identified the sources of our "lost time" - one, we were spending too much time in meetings.

A team member suggested that we apply the concept of kanban (en.wikipedia.org/wiki/Kanban) to our meetings, essentially, limiting the number of meetings we could conduct in a single sprint. The group accepted the idea and implemented it with "Yellow Cards" - an appropriate soccer analogy which implies a warning but not a significant foul. A yellow card could represent an internal or external group meeting. Furthermore, each card represented a meeting for 1 team member (with other organizations) for an hour or 2 team members for ½ an hour. Meetings of 15 minutes or less were not significant enough to track. Finally, during each planning session the team would limit the number of acceptable meeting cards that made it to our corkboard - usually 7. When the yellow cards ran out, NO MORE MEETINGS.

The results were better than expected. First, only meaningful meetings occurred.  If there was not a good reason to have a meeting it simply did not happen.  People were reluctant to waste a scarce resource (meeting). Second, because time was limited, meetings became more efficient and people came more prepared. Finally, many (if not most) meetings were replaced with desk-side discussions of 15 minutes or less. We continued to encourage regular communication, but wanted it to be concise, directed, and meaningful. It is important to note, that particularly significant or longer meetings are planned separately as tasks - e.g. website design meetings, sales campaign kickoff, etc.

Lesson 3: Interruptions - the nature of the business
As previously mentioned, our team regularly over committed in early sprints. Besides meetings, we discovered that interruptions (new requirements) were regularly occurring during ALL of our marketing sprints. E.g. a link in our website would suddenly get a 404 error or a newspaper needed an interview on the following day.  These were important tasks that needed to be addressed immediately. Instead of canceling more sprints (which was not very popular with our product owner), we created a mechanism that allowed us to accurately plan for and efficiently handle new requirements in the middle of a sprint.

A common suggestion that we received was to move lower priority items out of the sprint as new more important requirements surfaced. We tried this approach but it became too burdensome to shuffle tasks and reprioritize almost daily.  Furthermore, the interruptions were almost predictable in number, but not in form. Essentially we could plan for them, even though we did not know when or where they would appear.

As a result, we introduced the concept of the Purple Bullet. The name was simply derived from the fact that we had an ample supply of purple index cards. Purple bullets were also designed to be a scarce resource - the team was empowered to accept a certain number (kanban applied) without having to involve the product owner for reprioritization or to regroup for additional planning. The only requirement was that each high priority interruption was documented on the purple card so we could review them during the retrospective.

This particular practice has become one of the most pervasive lessons throughout our business Scrums. Unlike many software projects, the business has to handle important interrupts on a daily basis versus a weekly basis. The purple card has enabled us to handle new, frequent, and changing requirements in an efficient and effective manner. With only few modifications, this practice could be wonderfully adapted to a production environment where enhancements must be combined with support tickets.

Lesson 4: "Trusting" our velocity
As most practitioners of Scrum can testify, a burn down chart is a simple but highly effective tool that provides meaningful visibility to a team, its product owner, and other stakeholders. While its most common use is to measure actual progress versus a target, a burn down should not be over simplified. Information about each sprint should be careful noted; over a period of time the collection of sprints can be understood. I was surprised to discover that most teams do not take time to analyze a project across multiple sprints. The information can be extremely useful and can be used for countless benefits - including establishing trust between the team and its product owner.

Because marketing covers such a broad array of important business functions, several simultaneous "projects" are usually progressing during a single sprint. Our typical sprint backlog might include posting a press release to the company website, developing a new brochure, maintaining a blog, managing a sales campaign, etc. Once we got past the meetings and interruptions, we started to see other trends by evaluating our burn downs. We certainly have a velocity that has become reliable for planning purposes (more on this later), but we observed that it actually changes in a repeatable fashion throughout a majority of our sprints. We start out slow and finish fast (see diagram). This is logically apparent given the nature of many marketing tasks. They are started early in the sprint, but there is usually some factor that delays completion until late in the iteration. E.g. writing a customer news article for the website cannot be posted until a client approves it. The article is written early, then posted midway to late in the sprint. In the beginning, the slow start to a sprint created a sense of de-motivation within the team; furthermore, it created concern for the product owner who was usually very anxious about progress. Over time, however, we recognized the typical pattern and began expect it with no concern unless the velocity did not pick up midway through our sprint. Truly understanding our velocity helped to establish trust throughout our organization.

Lesson 5: In Retrospective - it's a valuable tool
Perhaps the most valuable part of each sprint is the retrospective.  Every couple of weeks our team takes the time to reflect and understand the work we performed, our team dynamics, and our overall effectiveness. While our current retrospectives last for merely an hour, they bring a constant and formal attention to improving ourselves, our company, and our team. In a standard business environment, such frequent and formal reflection is rare. It is truly amazing how productive a team can become by improving in a small aspect every couple of weeks. Compared to previous marketing teams at previous companies, we estimate that our current team is twice as productive. Although, we have no definitive baseline to reference, the raw results outlined in the introduction provide more than ample evidence to support our findings that we at conducted more events, hosted more user group meetings, produced more collateral and added more meaningful contacts to our database than teams in the past.

The success of our marketing Scrum has now caused us to launch additional agile efforts within our company.  We are now practicing Scrum in our sales, operations, and training organizations. Although drastically different than the "flavor" we adopted for marketing, the results have been equally impressive - business development pipeline doubling in 8 weeks, zero revenue delays due to incorrect invoicing, etc. We have become firm proponents of Scrum and agile and anticipate continuing to adopt in throughout our business.

Curtis: As CEO of Improving Enterprises, Mr. Hite is responsible for the strategic direction of the company and is the Chairman of the Board of Directors.

Trackback(0)

TrackBack URI for this entry

Comments (4)

...
written by Andrea Lane, April 27, 2011

Great article. I truly hope to see many elements of Scrum extended throughout functional business areas. Especially to so many companies crippled by the "meeting culture."

• 
• +0
• 
• 

...
written by Russell Pannone, March 13, 2009

Fantastic article! Thank you so much for sharing your experiences and insights.

• 
• +0
• 
• 

...
written by Peter Brunone, March 12, 2009

This is great. Way to think outside the box; it's surprising how effective Agile can be when correctly translated to other environments.

• 
• +0
• 
• 

...
written by Interesting Article -- Want more, March 12, 2009

I started to skim this article then found myself reading the whole thing. Very interesting, however, I would also like to see additional information about how it was applied directly to marketing or in other areas of their business. For example, how was scrum used for demand generation, or to increase sales, etc.

• 
• +1
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview