Couple of weeks back, I noticed an incident that triggered this post. Senior Management in a company applauded people for showing individual heroics on the project.
Some of them were:
- Staying late in office to address a client request?
- Responding to project emails at late night..
- Rewarding testers on number of bugs found and more.
And then, managers shared this privately with rest of the organisation too. Treating this as accepted, rewarding behaviour invited more such incidents and frustrated many of those who don’t do this. Below comic strip summarises it well.
“You Will Get What You Measure(or Reward)!”
I recently heard an another incident of how testing team kept an very important bug under the carpet before bringing it up just a week before release, and then getting rewards for the same. Such behaviours more likely are the candidates for root cause analysis than rewards.
Definitely, we all have numerous such incidents to share. How can we design a reward system to get team level behaviour more and less of individual heroics?
There is no greater de-motivator than a reward system which is perceived to be unfair. It doesn’t matter if the system is fair or not, if there is a perception of unfairness, then those who think that they have been treated unfairly will rapidly lose motivation.
Great products are developed through collaborative efforts of many people. So in a development environment, individual rewards will inevitably leave overlooked people feeling that they have been treated unfairly. Moreover, individual rewards fosters competition in an environment where co-operation is essential for success.
Conventional wisdom says that people should be rewarded based on the results that are under their control. However, information sharing and co-operation are essential, rewards must be based on span of influence rather than his or her span of control.
For example instead of rewarding testers on number of defects found, but rather developers and testers should be measured on team’s ability to create defect-free code. Instead of rewarding developers with technical success of their efforts; whole team should be rewarded based on business success of it efforts.
Team behaviours over individual heroics
Building defect-free code over finding bugs
Accepted stories over delivering stories
Business success over technical success
Building collaborative team is the corner stone of hyper-productive agile teams. Hence middle and senior management has to be extra cautious in their Agile Transformation approach. Implementing scrum with conventional wisdom metrics will not get what we want – A Hyper-Productive Agile Team.
A very well articulated article. I personally like the idea of building teams than individuals.
I also got some pointers for my session on Behavioral Traits of Agile Teams, SG Paris.
Thank You!
Thanks Nancy. That’s great to hear that you are talking at SG. Good luck.
Thanks for such a nice article. I could very well relate to it and think thats the biggest mistake to reward an individual than whole team.
Cool stuff. That’s a big grey area and I think it’s a good beginning. People from waterfall background ask this very questions. Where are the metrics in Agile? Other question which nobody tries to answer is – how to motivate team and not just individuals.
True. People coming from traditional background have affinity towards metrics. They are used to watching metrics and not people/team. Hence it’s time we have to drive more team behaviour.
Very well put, and excellent points of contention.
Very well put. Liked the idea of rewarding the team on a bug free release rather no of bugs found.
Very good article. This culture persist in so may organisation
Generally speaking, setting external targets for teams can be a bit dicey in-and-of-itself (much less setting individual targets as this article illustrates well). Certainly, when an agile team is new, some level of external influence is needed to structure activities and behaviors. However, at some point a team needs to own agile itself. Meaning, they need to own their own growth and improvement, and they need to be able to count on managers and leaders to help them clear obstacles to their own growth. Management shifts to a facilitator focused discipline — helping teams adopt effective continuous improvement programs, and sharing practices between teams. Many managers cannot bring themselves to see this as leadership, but it’s absolutely leadership, heavily bent toward thought leadership and influence, and bent AWAY from the traditional transactional behaviors of traditional top-down management.
Good idea. I thought a lot about it. Seems to me it is very useful.
Really nice article Avienaash. I like your approach. There are many valuable insights in this for all types of teams and businesses. Thank you 🙂
Good one…
Saying “Scrum Prctitioner” really means not only following the prctices of Scrum(Like Daily standup’s ,Updating Scrum board etc..),but one should feel the essence of doing it.
Practising Scrum partially will really end up in mess.
But, to be frank most of us are still working in an environment where people belive spending more time in office and reporting more bugs will determine the efficiency of an individual.
🙁
True eye-opener!
More the team culture we build it will help to build great products and I believe this artical pin-points common issue we see around us.
Nice one Avienaash !
I don’t really care for your metrics as I think they will encourage the wrong behaviors.
I recommend you look at the metrics in the EBM guide from Scrum.org.
(Btw, the EBM metrics can be used for both Agile and Waterfall projects)
See here:
http://www.ScrumCrazy.com/ebm