About 12 months ago, our company started an initiative to adopt agile practices across our entire organization—not only our software development organization, but our business organization. For years we had experienced outstanding results by utilizing Scrum for our clients' application development projects. Team productivity improved, executive visibility strengthened, and overall quality increased. Our goal was to capture similar results for our business.
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."
With a limited schedule (10 months), moderate budget (lt;$90,000), and small team (3 permanent members), the return on our investment has exceeded expectations. Over this time period, we conducted 10 regional events, organized a significant technology conference, hosted 35 user group meetings, completed a major website enhancement, created a complete set of corporate collateral, and developed measurable brand recognition with thousands in the Dallas market (just to name a few).
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 theprocess, 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