I am a sports nut. So the Olympics come on and now that seems to be all that I watch for the entire month of February. In some spare cycles, I begin to think about athletes, and how they prepare and train for events like the Olympics, and how there are some interesting parallels to software development.
Athletes are pretty normal people, but those at the highest level have one distinct difference from everyday people like you and I. They love to compete and are fueled by a desire to not only compete, but to win. All of the best athletes from any number of different sports all share these traits. They are competitive, committed, and hate to lose. They WANT to be MEASURED against their competitors, and they MONITOR THOSE MEASUREMENTS. Sprinters and racers strive for better split times, and better finishing times. Team sports athletes strive for better numbers in the measures of their sport (like goals, RBIs, touchdowns, interceptions, home runs, etc.). That is why many athletes have a tough time retiring. The competition, the single minded purpose, is all gone in retirement, and they cannot replace it with other things in their lives. This desire to be measured against the best in the world, with the confidence that you can do better, is what makes a world-class athlete special.
Software teams should try to be like these team athletes. Many software teams seem to fear being measured, and to me this is a sign of weakness. It shows a lack of confidence, and a lack of accountability. The key lies in WHAT you measure, and how you use this information. When an athlete finds a weakness in their performance, they view this not as a personal weakness, but as an opportunity to further improve their performance. Coaches looking at poor scores/metrics don’t typically call their athletes worthless, or get rid of them. They see a weakness in some measurement as an opportunity to coach, improve, and grow.
Software development management needs to adopt the same mentality that team sport coaches have. Use the measures at your disposal to help you fine tune the areas that you need to improve upon, and to tailor your organization to take full advantage of the strengths of your team. Great coaches adapt their style to the specific personalities and talents of the members of their team. Each team has players that perform different roles, and a good coach/manager should be doing the following:
- Encouraging their players to improve in the areas where they are weak
- Putting each team member in situations where they can excel
- Allowing team members opportunities to grow, and encouraging that growth
- Show their players the ways that they are being measured, and allow them to monitor their own progress and performance
- Treat players as individuals
Doing these things allows team members to prove their worth, every day. When people know how they are being measured, and when they are responsible not to some faceless concept (the “Company”), but to a group of teammates who have a shared purpose and mission, their performance improves. Read some of the material out there on high performing teams. Is any of this original thought? A lot of this looks like it dovetails with the Principles of the Agile Manifesto.
So since this is a Jazz based blog, how does all of this relate to Jazz? Go out and look at how we use the Jazz technology to develop the products that utilize that framework, on jazz.net. You can see a large number of dashboards and iteration plans that detail what our teams are doing, as well as how well they are doing it. This information is available to the teams, the management team, and our customers. EVERYONE on the Jazz team is accountable, and it’s visible. We can either get better, or get embarrassed. The Jazz concept of a common repository, with easily accessed data that can be displayed in a number of different ways, works best with a high degree of information sharing. It helps fuel the collaborative aspect of the tools that utilize Jazz, and this visibility enforces accountability. I believe that this has a positive effect on the quality of our tools, and on the overall quality and capability of our software development teams. I have seen this improve our responsiveness to our customers (check my earlier blog on Supporting Jazz).
So enjoy the Olympics, and watch the stories behind the athletes. Many of them have been measured for years, and have used what could have been perceived as negative measurements as motivation for improving. We should all strive to foster that view of measurements and metrics in our software development organizations, and quit being afraid of being measured.