The challenge was to introduce agility (Scrum) across the AOL Publishing organization. If we subtract the editorial staff, the agile transformation affected roughly 3,000 employees one way or the other. The agile consultant and coach tried to tackle several issues under one “reward and recognition program” umbrella. For example, “How do we know that the 50-70 project teams, who were working in parallel at any given moment, were really doing agile?”
Experiences from an internal reward and recognition program introduced by Jochen Krebs to AOL.
Early 2008, I became responsible of one of the largest agile transformations in the industry. The challenge was to introduce agility (Scrum) across the AOL Publishing organization. If we subtract the editorial staff, the agile transformation affected roughly 3,000 employees one way or the other. Many of the employee’s jobs turned upside-down as contributing team member. Other, more peripheral stakeholders such as advertising, legal and executives, the agile transformation had less impact on their daily life but was still noteworthy. Needless to say, everyone needed to pull into the same direction to make agile stick across the board. The transformation was rapid with full executive support, but the speedy commitment and high expectations introduced new problems for a transformation of such a magnitude.
I was facing several issues which I tried to tackle under one “reward and recognition program” umbrella. For example, “How do we know that the 50-70 project teams, who were working in parallel at any given moment, were really doing agile?” In my role, I needed to know if we increase productivity with Scrum and if so by how much? In other words, “Was it really (with evidence) a good idea to depart from waterfall?” It was however extremely important that we did not want to get insights through additional bureaucracy. We did not want to establish a command and control process police nor did we want to introduce additional reports and status meetings. The goal was to use what was automatically produced by the Scrum framework. I also wanted to proactively tackle the issue of sprint fatigue when teams burn out over time and agile practices become neglected due to routine and mechanical execution (e.g. retrospectives). Last but not least, we wanted to use the award to help creating a team boundary as well organizational boundary in a company operating across the globe.
The first step was Scrum training for every project team. We did then establish a mix of internal and external team coaching which guided every team through the key elements of iterations, especially iteration planning and review. That lasted for at least two iterations for every team. Many of these 2-day Scrum courses I delivered myself world-wide. The mix of internal and external coaching was crucial for success during the initial iterations. External coaching delivered freshness, experience and purity in agile practices. Internal coaches were especially important, because AOL would need to find a way to keep the agile process alive for the months and years to come. In addition, nobody knew the political and cultural playing field better than the employees themselves.
While the team-based roll-out was underway I was looking for a way to keep the energy-level and morale elevated while we wanted to review the effectiveness of the agile process. In fall 2008, I introduced the “A-team” reward and recognition program for all agile teams. We used A-team as wordplay between “agile” and “AOL” but it also connected the award with the media industry we are operating in. It also made it clear that we were looking for hero teams, not individual hero team members. Either the entire team would become A-team or nobody on the team.
We wanted to make this program catchy, easy to verify, achievable and most important without introducing any new bureaucracy. That meant no paperwork, forms or templates to be filled out and no committee which would decide as a judge. We agreed to one basic requirement which turned “a” team into an “A”-team. That is:
“Demonstrate three months of successful sprinting”
We outlined the success criteria for every agile team as follows:
- Capture velocity metrics
- Demonstrate increments with working software
- Deliver dynamic requirements
- Duplicate knowledge
The first three of the four criteria were directly linked to the Scrum process framework and reinforced the knowledge transfer from the courses and coaching. It is very important, that we did not state the criteria for example similar to “increase velocity by 10% each iteration”. As a matter of fact we did not use the velocity number in any communication other than with the project team itself. A team comparison or performance analysis was never intended would have been wrong anyway. We wanted make sure the team would know their velocity and use it as an instrument.We trusted that each team would track their velocity. That re-iterated the importance of metrics in planning and estimating and gave teams the tool to become more predictable. A higher degree of predictability was actually a goal of executive management when they introduced Scrum. Before agility, dates slipped or requirements were under delivered.
Demonstrating working software had a direct impact on the deliverables (definition of done). Demonstrating product features at the end of every iteration would also symbolize a real departure from mini-waterfalls (feature completion vs. phase completion).
The third criteria took care of changing requirements and that we expected teams to be flexible with their requirements management. We purposely did not ask the teams to deliver what they planned, but to deliver what was needed even if the requirements changed. It was important that the A-team reward success criteria couldn’t conflict with goals of the product strategy.
The fourth was the only criteria which was not “built-in” into the Scrum process but important from an organizational maturity perspective. We wanted to encourage every team to share successes and challenges with other teams. We did not state how and when, but we wanted to increase inter-project communication. For example, one team might decide to write an experience report on our internal agile blog, while another team offers a quick lunch amp; learn. All it mattered was that the teams were communicating and exchanging experiences among each other. The exchange could have been formal or informal.
After three months of successful sprinting, the team would receive the A-team award. Although we asked the teams to provide the dates and iteration info, the A-team certificate was issued when the teams signaled readiness. The information was only collected for the certificate and to support the award ceremony. We had public ceremonies for winning teams and funky certificates signed by executives. The A-team award was not limited to one award and every team could earn multiple awards over time. Therefore every team could ideally collect four awards a year. We also did not define the price for each award. That allowed us to be very basic during economic challenging times, but gave us room to grow in the future.
We created awareness of the program through internal campaigns and the word “A-team” became quickly part of everyday vocabulary.
Although we took a very AOL centric approach with the A-team program, I hope this article generates thoughts and ideas for recognizing maturity of agile practices in other organizations. Remember, this program helped with the roll-out of Scrum and was very broad. More experienced agile organizations might need to adjust the success criteria to make it more meaningful.
We know from requirements management that feedback is very important. Think about giving feedback to your teams not only about the product, but also how they are doing as a team. The A-team valued Scrum and the team, not the software they were producing. Your reward program success criteria might value different goals. Our A-team’s had fun and they went the extra-mile. Today, when you walk through the offices, you see A-team certificates hanging at desks and I would not be surprised if you soon find the term in resumes of employees.
Keep the program simple, transparent, fair, filled with trust just like the agile process itself. Instead of checklists, define success criteria and state them as expectations not as results. Have fun with it and kick-off 2010 with some fresh new ideas.
Last but not least I wanted to thank Tamara Sulaiman for her valuable feedback when the broad and initial ideas about this program began to take shape.
About the Author
Jochen (Joe) Krebs (www.jochenkrebs.com) is an independent agile coach, instructor and consultant. As Incrementor (www.incrementor.com), he increases measurable business value through agile consulting and training programs for teams and entire organizations. Joe is the author of the book “Agile Portfolio Management”, founder of the APLN chapter in New York City and speaks at conferences and user groups when time and schedule permits.
