Featured Whitepapers
- Apples, Oranges, and Acorns - All Agile Development Tools Are Not the Same
- One's Enough for Agile Application Development Management
- Requirements Management 101 – 4 Basics Everyone Should Know
- Tips on Requirements Traceability – Learn How to Control Change and Improve Quality
- Scaling Continuous Integration to Large and Distributed Teams
|
Happy New Year. It is the time for resolutions and high personal and professional goals again. If one of your aspirations includes improving or sustaining team morale or increasing agile maturity through an enterprise-wide reward and recognition program, this article might give you some fresh new ideas for 2010. 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:
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 & 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
Set as favorite
Bookmark
Email this
Hits: 2027 Trackback(0)Comments (0)
|
Experiences from an internal reward and recognition program introduced by Jochen Krebs to AOL. 
TrackBack URI for this entry
Show/hide comment form
Agile Marketplace - Announcements and Special Offers
The Business Case for ALM Transformation
Are legacy systems holding your company back? Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper