As I explained to them, I first was introduced to the agile web development method at Intuit, when I partnered with an engineer who was leading the development of Intuit’s Live Community and when I managed Seth Webster, who led the Support Website team. In observing how they facilitated their teams, I was able to pick and choose some key aspects of the Agile methodology and adopt them accordingly to our marketing team.
Some key mechanics of Agile:
- Daily check-ins
- Six week sprints (projects)
- Embrace mid-course correction
- Develop requirements based on user stories
- Cross-functional teams at the table
- Build projects are ‘what people are passionate about’
- Step back and often discuss what the team can do better
- Be metrics driven, but also listen to what customers/users are saying
- Uncover efficiencies over time by learning real time
Some key points about Agile:
- A Second Track: In addition to six week sprints, I believe the web requires teams to react and change course even faster, so I built a second track which was less than a week. If our metrics indicated something wasn’t working after a few days, for example, we altered our course (Obviously, you need enough traffic and engagement to ensure that your metrics are statistically significant). My motto for the second track is “Real Time Learning and Just-In-Time Correction!” (TM)
- Every day check-ins: Even before I was introduced to the Agile methodology, I have believed that it is important to have short 15-20 minute meetings every day. Not only does this ensure that everyone is on the same page, it accelerates the process of building a high performing team
- Everyone has a voice at the table: The leader is really just the facilitator and is someone who can make the final decision if consensus can’t be reached. It is important, however, that as many teams as possible are represented at the table and that everyone has a voice and has the right to speak up.
- All data is available: Even though the team might be measured on 10 or so KPIs and key metrics, the team should have access to all available data. I have worked with many companies where individuals try and control all the data, as if they were concerned someone might find out something they don’t know. And the team should be focused on the top ten items, but if someone wants to go off the reservation and take a deeper dive into some of the data, then all the power to them
- Builds Good DNA to handle Crisis’: If your team is meeting every day and is used to consistently responding to user behavior, they will be trained to be more nimble, which will be important if a crisis occurs. It’s difficult to herd the cats into last minute meeting (Agile has set daily meetings) and get people to think about working closely together to formulate a quick response.
- Don’t launch with the Stealth Bomber: Start simple with a few features and build over time as you learn. Yes, the old ‘launch and learn’ approach. Remember that only 20% of what you develop will be used by 80% of your users, so why not engage with them upfront.
We used this approach when we launched the Intuit Online Community and since then I have facilitated this process for several marketing groups. They have hired me as their Marketing Coach, and even though one of my responsibilities is to help them with Strategy, a big part of what I do is work with them to build a nimble cross-functional ‘social business’ process.
Ask your questions and I will tell you more