Metrics to Build Great Agile Teams: Measure Influence, Not Control

by Avienaash Shiralige

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)!”

measure quality

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.

Metrics for Agile Teams

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.

About Avienaash Shiralige


Avienaash Shiralige is an Agile Coach, Trainer, Business Optimisation and Agile Transformation Consultant @ AgileBuddha. He has been on senior leadership positions in various companies and comes with very rich 17+ years of experience in product and service companies. He has consulted companies in India, US, Europe and Australia on Agile/Scrum/Lean/Kanban and successfully set-up various distributed agile teams across timezones. He can be reached at avienaash@gmail.com.

{ 14 comments… read them below or add one }

Nancy Sharma May 2, 2013 at 3:37 pm

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!

Reply

Avienaash Shiralige May 2, 2013 at 4:14 pm

Thanks Nancy. That’s great to hear that you are talking at SG. Good luck.

Reply

Rupinder May 2, 2013 at 5:30 pm

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.

Reply

ShriKant Vashishtha May 3, 2013 at 7:01 am

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.
ShriKant Vashishtha recently posted..Metrics to Build Great Agile Teams: Measure Influence, Not Control

Reply

Avienaash Shiralige May 3, 2013 at 9:36 am

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.

Reply

Jacqueline Brown May 3, 2013 at 9:22 am

Very well put, and excellent points of contention.

Reply

Ravi Jangra May 4, 2013 at 2:59 pm

Very well put. Liked the idea of rewarding the team on a bug free release rather no of bugs found.

Reply

Satya May 11, 2013 at 6:58 am

Very good article. This culture persist in so may organisation

Reply

Joe Rounceville May 18, 2013 at 11:42 pm

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.

Reply

Alex Pikulev May 23, 2013 at 1:32 am

Good idea. I thought a lot about it. Seems to me it is very useful.

Reply

Edwin Dando May 24, 2013 at 3:26 am

Really nice article Avienaash. I like your approach. There are many valuable insights in this for all types of teams and businesses. Thank you :-)

Reply

Saranya May 30, 2013 at 4:53 pm

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.
:-(

Reply

Maheshkumar June 7, 2013 at 11:18 am

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.

Reply

Jamal Sheikh September 9, 2013 at 11:29 am

Nice one Avienaash !

Reply

Leave a Comment

{ 1 trackback }

Previous post:

Next post: