One of the well-known virtues of Agile development is the focus on frequently delivering valuable, working software to our customers. In practice, this results in the establishment of a variety of well-defined goals at all layers of the planning flame. We have roadmaps that identify goals beyond the current release, release themes that align and motivate the team within a release, and, ideally, iteration goals (or themes) that help everyone maintain a crisp focus on the current iteration, and daily goals (cross off ANOTHER item in your task list).
Establishment goals is a critical foundation of high-performance teams. Suitably challenging goals can inspire a team to realize greater performance, provided the challenge is perceived as attainable (impossible goals are demotivating!). The decompsition of larger goals into sub-goals enables the team to feel good about their progress, even when they take on a bit too much work in a given iteration and fail to realize all that they had planned.
Goals serve to enable a team to resolve conflicts. By focusing on the goal that is to be achieved, teams can spend time debating how to realize the goal—a big improvement over teams who waste precious energy arguing over what they should be doing in the first place.
Assuming that goals are set, it is quite natural to drift towards the topic of reward and compensation systems around the achievement of goals. This is an extremely complex topic, and one that deserves more attention in the Agile community. In the remainder of this post I’ll try to shed some light on this topic and offer some approaches that you may be able to leverage in your team. I’m hopeful that other members of the community will join our discussion, including HR and other professionals outside of our community.
I’ll start by tacking informal reward systems that are created by the team without the need for explicit corporate endorsement to celebrate their accomplishments as a team. These range from Agile teams that share pizza and beer whenever their product manager accepts all of their stories at the end of the iteration to the team that donates $1 from every team member to a local charity for every delivered point. Parties at the end of the release, taking the team out to a movie, giving developers a few days off, and publicly recognizing the team and congratulating them in front of the rest of the company are all common informal reward systems. Product Managers should do everything they can to foster these reward systems. If needed, chip in and buy some pizza. T-Shirts are nice, and you can always find a way to get the marketing team to cough up some schwag for a team that delivers software frequently enough that new and improved really are, well, new and improved.
Unfortunately, the enterprise adoption of Agile can be at odds with existing reward systems that emphasize individual over collective performance. Our clients often ask us for advice on how to structure more formal compensation / reward systems along with their adoption of Agile. Each situation is unique, but I’ve found thinking about compensation in the following structure helps establish suitable reward systems. It is a tough challenge, but one that is worth tackling.
My ideal structure consists of three components: a base salary, an individual performance bonus, and a team performance bonus. The base salary would be appropriate for the skills, ability, experience, and job of the developer. We’ll always pay more for smart, capable, experienced, senior product managers developers and pay less for less knowledgable, inexperienced, and frankly, less effective junior developers. Eventually, the least capable members of the team need to be replaced for the health of the team and the health of the organization. This may take longer in an Agile team, where individual performance variations may be harder to identify, but the rigorous application of Agile practices will make individual and team performance visible.
The individual performance bonus would be appropriate for individuals who truly perform above and beyond the call of duty. In general, this bonus should not be under the explicit control of the developer, but it should be clear what behaviors are likely to obtain it. I’m thinking about the developer who works extra hours to help a colleague who was unexepectedly sick so that the overall release was not affected, or the developer who pioneers and eventually institutionalizes a significant change to development practices even though the rest of the team didn’t initially agree with their recommendations. (Hey, not everyone thinks automated testing is a good idea the first time they hear about it). Note that these behaviors tend to align with the full expression of corporate culture, not the number of lines of code written or removed or resolving a complex bug.
The team performance bonus should reward the attainment of stated goals and should again explicitly reinforce organizational culture. This is arguably the most challenging element of the reward structure, as it could motivate the team to operate in ways that might be incongruent with the Agile Manifesto or larger culture. For example, a team working towards a specific release date could stop doing retrospectives to “save time” to hit the release date. A poor manager could force the team to work at an unsustainable pace to protect their bonus. Another team might engage in gold-plating the release, forever refactoring their software in pursuite of technical elegance beyond what is needed for success in the market. For this reason, establishing a team bonus must be undertaken very, very carefully, and usually with the guidance of HR professionals.
Chances are good that you will be highly constrained by larger organizational forces as it relates to the nature and structure of the bonus. And, if you’re working in a Silicon Valley style startup, the concept of a “bonus” is completely immaterial. You’re working for your stock, and your bonus is getting to work long hours at something you love doing.
Trust is also a factor in designing and executing reward systems. The likelihood a developer will perceive a bonus as “fair” will be based primarily on the degree of trust between them, their teammates, their manager, and their employer. More specifically, I am happy with a $500 bonus if I trust that my manager treats me fairly and unhappy with a $1500 bonus if I believe otherwise.
As you start or continue down your path towards greater enterprise agility, be prepared to examine and possibly change existing compensation and reward systems. These systems are harder to create and align that simple goals. Done well, they can be unusually powerful. Done poorly, and you’ll end up less Agile than you were before.
To help you get started, consider the following questions.
* What individual and collective activities contribute to the attainment of rewards?
* Are these activities consistent with the culture of the team? the larger company?
* Are these activities consistent with the Agile Manifesto?
* Explore different time horizons as you answer these questions. Are your reward systems promoting sustainable growth?
The results are not always clear, and reward systems that on the surface contribute to stated goals may actually promote the opposite behavior.
– Luke Hohmann, www.enthiosys.com
Popularity: 42% [?]
Leave a Reply