Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] the team that turned down KPIs and bonuses

Expand Messages
  • Abhilash c
    Thanks MJ this is a great story :) Regards Abhilash
    Message 1 of 11 , Feb 16, 2012
    • 0 Attachment
      Thanks MJ
       
      this is a great story :)
      Regards
      Abhilash


      On 16 February 2012 22:19, Michael James <mj4scrum@...> wrote:
       

      This encouraging story was sent to me (below). Thought it was worth posting here.
      --mj

      > Hello Michael,
      >
      > Thanks very much for your message.
      > I did not blog about this, because my blog is still under construction.
      > We are a software company employing about 50 people.
      > A few years ago, our CEO introduced a company wide bonus system, based on 5 KPI's. The KPI's were different for every department, to be determined by the manager of the departments, like Direct Sales, Helpdesk, Development.
      > I told the CEO that, as a Scrum Master (and manager of the Development department), I could not decide on these KPI's myself (nor did I want to), so I "took it to the team", to coin a popular (and rightly so!) Agile phrase.
      > We discussed it in multiple sessions (I did not "lead" these sessions, nor did I put my view across, I just asked questions), but the team kept coming to the same conclusion: Any KPI we could come up with, either infringed on the Scrum principles, or deferred the team from the continuous improvement principle.
      > And believe me, we brainstormed about a lot of possibilities: Number of story points gotten credit for per sprint, number of iterations per story or task, newly reported bugs per sprint, even lines (and characters) of code.
      > Our bottom line was, that it just doesn't sound right, quantifying performance on any other criteria than working software. And, adult and intelligent as we obviously are (I mean, we're Development, right?), there will still always be this "hidden agenda" in the back of one's mind, that makes one, for example, report two defects in one bug, or write a routine differently, to make it larger, in order to positively influence the KPI's. It's all unwanted distractions, in the end.
      > So ultimately, we unanimously decided to kindly refuse the offer. Much to the surprise of the rest of the company, including management. Priceless to see the look on their faces. Funnily enough, no-one asked us to explain why. I reported it to the CEO, and he understood. He's into Agile. Thank God.
      > Up to this day, we still don't participate in the bonus system.
      >
      > I've used this example on a few occasions myself, because it's very illustrative.
      > You're absolutely welcome to share it with other people, if it contributes to spreading the word.
      >
      > Kind regards


    • jean@azuregate.net
      Thanks for sharing this, Michael. We need more such case studies around the topics of performance reviews and compensation. -- Jean Sent from my Verizon
      Message 2 of 11 , Feb 16, 2012
      • 0 Attachment
        Thanks for sharing this, Michael. We need more such case studies around the topics of performance reviews and compensation. -- Jean
        Sent from my Verizon Wireless BlackBerry

        From: Michael James <mj4scrum@...>
        Sender: scrumdevelopment@yahoogroups.com
        Date: Thu, 16 Feb 2012 08:49:18 -0800
        To: <scrumdevelopment@yahoogroups.com>
        ReplyTo: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] the team that turned down KPIs and bonuses

         

        This encouraging story was sent to me (below). Thought it was worth posting here.
        --mj

        > Hello Michael,
        >
        > Thanks very much for your message.
        > I did not blog about this, because my blog is still under construction.
        > We are a software company employing about 50 people.
        > A few years ago, our CEO introduced a company wide bonus system, based on 5 KPI's. The KPI's were different for every department, to be determined by the manager of the departments, like Direct Sales, Helpdesk, Development.
        > I told the CEO that, as a Scrum Master (and manager of the Development department), I could not decide on these KPI's myself (nor did I want to), so I "took it to the team", to coin a popular (and rightly so!) Agile phrase.
        > We discussed it in multiple sessions (I did not "lead" these sessions, nor did I put my view across, I just asked questions), but the team kept coming to the same conclusion: Any KPI we could come up with, either infringed on the Scrum principles, or deferred the team from the continuous improvement principle.
        > And believe me, we brainstormed about a lot of possibilities: Number of story points gotten credit for per sprint, number of iterations per story or task, newly reported bugs per sprint, even lines (and characters) of code.
        > Our bottom line was, that it just doesn't sound right, quantifying performance on any other criteria than working software. And, adult and intelligent as we obviously are (I mean, we're Development, right?), there will still always be this "hidden agenda" in the back of one's mind, that makes one, for example, report two defects in one bug, or write a routine differently, to make it larger, in order to positively influence the KPI's. It's all unwanted distractions, in the end.
        > So ultimately, we unanimously decided to kindly refuse the offer. Much to the surprise of the rest of the company, including management. Priceless to see the look on their faces. Funnily enough, no-one asked us to explain why. I reported it to the CEO, and he understood. He's into Agile. Thank God.
        > Up to this day, we still don't participate in the bonus system.
        >
        > I've used this example on a few occasions myself, because it's very illustrative.
        > You're absolutely welcome to share it with other people, if it contributes to spreading the word.
        >
        > Kind regards

      • alex.armstrong
        Michael, Great read, thanks for sharing. Do you have any idea if a modest profit sharing arrangement was considered? That seems to have been the typical way to
        Message 3 of 11 , Feb 17, 2012
        • 0 Attachment
          Michael,

          Great read, thanks for sharing. Do you have any idea if a modest profit sharing arrangement was considered? That seems to have been the typical way to align teams with the goals of the product/company over the past few years. If the team in the story did consider it, I would be curious what the potential sub-optimization was that they expected.

          Alex

          --- In scrumdevelopment@yahoogroups.com, jean@... wrote:
          >
          > Thanks for sharing this, Michael. We need more such case studies around the topics of performance reviews and compensation. -- Jean
          >
          > Sent from my Verizon Wireless BlackBerry
          >
          > -----Original Message-----
          > From: Michael James <mj4scrum@...>
          > Sender: scrumdevelopment@yahoogroups.com
          > Date: Thu, 16 Feb 2012 08:49:18
          > To: <scrumdevelopment@yahoogroups.com>
          > Reply-To: scrumdevelopment@yahoogroups.com
          > Subject: [scrumdevelopment] the team that turned down KPIs and bonuses
          >
          > This encouraging story was sent to me (below). Thought it was worth posting here.
          > --mj
          >
          > > Hello Michael,
          > >
          > > Thanks very much for your message.
          > > I did not blog about this, because my blog is still under construction.
          > > We are a software company employing about 50 people.
          > > A few years ago, our CEO introduced a company wide bonus system, based on 5 KPI's. The KPI's were different for every department, to be determined by the manager of the departments, like Direct Sales, Helpdesk, Development.
          > > I told the CEO that, as a Scrum Master (and manager of the Development department), I could not decide on these KPI's myself (nor did I want to), so I "took it to the team", to coin a popular (and rightly so!) Agile phrase.
          > > We discussed it in multiple sessions (I did not "lead" these sessions, nor did I put my view across, I just asked questions), but the team kept coming to the same conclusion: Any KPI we could come up with, either infringed on the Scrum principles, or deferred the team from the continuous improvement principle.
          > > And believe me, we brainstormed about a lot of possibilities: Number of story points gotten credit for per sprint, number of iterations per story or task, newly reported bugs per sprint, even lines (and characters) of code.
          > > Our bottom line was, that it just doesn't sound right, quantifying performance on any other criteria than working software. And, adult and intelligent as we obviously are (I mean, we're Development, right?), there will still always be this "hidden agenda" in the back of one's mind, that makes one, for example, report two defects in one bug, or write a routine differently, to make it larger, in order to positively influence the KPI's. It's all unwanted distractions, in the end.
          > > So ultimately, we unanimously decided to kindly refuse the offer. Much to the surprise of the rest of the company, including management. Priceless to see the look on their faces. Funnily enough, no-one asked us to explain why. I reported it to the CEO, and he understood. He's into Agile. Thank God.
          > > Up to this day, we still don't participate in the bonus system.
          > >
          > > I've used this example on a few occasions myself, because it's very illustrative.
          > > You're absolutely welcome to share it with other people, if it contributes to spreading the word.
          > >
          > > Kind regards
          >
        • Michael James
          I don t know anything about that company s situation, but I read something in the Pfeffer/Sutton book about evidence-based management that challenged my own
          Message 4 of 11 , Feb 17, 2012
          • 0 Attachment
            I don't know anything about that company's situation, but I read something in the Pfeffer/Sutton book about evidence-based management that challenged my own assumptions:

            There is, in fact, little evidence that equity incentives of any kind, including stock options, enhance organizational performance.  One review of more than 220 studies concluded that equity ownership had no consistent effects on financial performance.14  Another massive study and review of research on executive compensation published by the National Bureau of Economic Research reported that most schemes designed to align managerial and shareholder interests failed to do so; instead, executive compensation practices just operated as devices to enrich senior managers, who usually received most of the stock options.15 
            ...

            Stock options are more crucial to success, and perhaps less likely to produce false hype, in small, privately held start-up companies.  The entrepreneurship fueled by options helps new companies get off the ground.  Cash is at a premium in most start-ups, and the chance to strike it rich attracts talent that otherwise would remain out of reach.  Yet, despite such virtues, unwavering belief in stock options that is so pervasive among the leaders of high-technology companies is not based on sound evidence or logic.

            FWIW, I've experienced the latter situation (ownership interest in a privately held start-up) first hand, and believe it did help align my actions with organizational goals.  I was surprised to read the lack of evidence this scales though.


            --mj

            On Feb 17, 2012, at 7:58 AM, alex.armstrong wrote:

             

            Michael,

            Great read, thanks for sharing. Do you have any idea if a modest profit sharing arrangement was considered? That seems to have been the typical way to align teams with the goals of the product/company over the past few years. If the team in the story did consider it, I would be curious what the potential sub-optimization was that they expected.

            Alex

            --- In scrumdevelopment@yahoogroups.com, jean@... wrote:
            >
            > Thanks for sharing this, Michael. We need more such case studies around the topics of performance reviews and compensation. -- Jean
            >
            > Sent from my Verizon Wireless BlackBerry
            >
            > -----Original Message-----
            > From: Michael James <mj4scrum@...>
            > Sender: scrumdevelopment@yahoogroups.com
            > Date: Thu, 16 Feb 2012 08:49:18
            > To: <scrumdevelopment@yahoogroups.com>
            > Reply-To: scrumdevelopment@yahoogroups.com
            > Subject: [scrumdevelopment] the team that turned down KPIs and bonuses
            >
            > This encouraging story was sent to me (below). Thought it was worth posting here.
            > --mj
            >
            > > Hello Michael,
            > >
            > > Thanks very much for your message.
            > > I did not blog about this, because my blog is still under construction.
            > > We are a software company employing about 50 people.
            > > A few years ago, our CEO introduced a company wide bonus system, based on 5 KPI's. The KPI's were different for every department, to be determined by the manager of the departments, like Direct Sales, Helpdesk, Development.
            > > I told the CEO that, as a Scrum Master (and manager of the Development department), I could not decide on these KPI's myself (nor did I want to), so I "took it to the team", to coin a popular (and rightly so!) Agile phrase.
            > > We discussed it in multiple sessions (I did not "lead" these sessions, nor did I put my view across, I just asked questions), but the team kept coming to the same conclusion: Any KPI we could come up with, either infringed on the Scrum principles, or deferred the team from the continuous improvement principle.
            > > And believe me, we brainstormed about a lot of possibilities: Number of story points gotten credit for per sprint, number of iterations per story or task, newly reported bugs per sprint, even lines (and characters) of code.
            > > Our bottom line was, that it just doesn't sound right, quantifying performance on any other criteria than working software. And, adult and intelligent as we obviously are (I mean, we're Development, right?), there will still always be this "hidden agenda" in the back of one's mind, that makes one, for example, report two defects in one bug, or write a routine differently, to make it larger, in order to positively influence the KPI's. It's all unwanted distractions, in the end.
            > > So ultimately, we unanimously decided to kindly refuse the offer. Much to the surprise of the rest of the company, including management. Priceless to see the look on their faces. Funnily enough, no-one asked us to explain why. I reported it to the CEO, and he understood. He's into Agile. Thank God.
            > > Up to this day, we still don't participate in the bonus system.
            > >
            > > I've used this example on a few occasions myself, because it's very illustrative.
            > > You're absolutely welcome to share it with other people, if it contributes to spreading the word.
            > >
            > > Kind regards
            >


          • Adam Sroka
            ... Things that work at a small scale generally don t work at a larger scale. This is a truism as far as I can tell, at least for complex systems. There are
            Message 5 of 11 , Feb 17, 2012
            • 0 Attachment
              On Fri, Feb 17, 2012 at 10:56 AM, Michael James <mj4scrum@...> wrote:
              >
              >
              >
              > I don't know anything about that company's situation, but I read something in the Pfeffer/Sutton book about evidence-based management that challenged my own assumptions:
              >
              > http://www.amazon.com/Facts-Dangerous-Half-Truths-Total-Nonsense/dp/1591398622
              >
              > There is, in fact, little evidence that equity incentives of any kind, including stock options, enhance organizational performance.  One review of more than 220 studies concluded that equity ownership had no consistent effects on financial performance.14  Another massive study and review of research on executive compensation published by the National Bureau of Economic Research reported that most schemes designed to align managerial and shareholder interests failed to do so; instead, executive compensation practices just operated as devices to enrich senior managers, who usually received most of the stock options.15
              > ...
              >
              > Stock options are more crucial to success, and perhaps less likely to produce false hype, in small, privately held start-up companies.  The entrepreneurship fueled by options helps new companies get off the ground.  Cash is at a premium in most start-ups, and the chance to strike it rich attracts talent that otherwise would remain out of reach.  Yet, despite such virtues, unwavering belief in stock options that is so pervasive among the leaders of high-technology companies is not based on sound evidence or logic.
              >
              >
              > FWIW, I've experienced the latter situation (ownership interest in a privately held start-up) first hand, and believe it did help align my actions with organizational goals.  I was surprised to read the lack of evidence this scales though.
              >

              Things that work at a small scale generally don't work at a larger
              scale. This is a truism as far as I can tell, at least for complex
              systems. There are innumerable examples of this in business,
              government, engineering, biology, etc. IMNSHO, we ought to always,
              automatically assume that scaling is the wrong solution and apply
              Systems Thinking. This goes for "Scaling Scrum" or "Scaling Agility"
              as well.
            • DH.
              ... Not automatically, no, but still there is Semco SA and they are a good example of how far you can push democracy and social acceptance in a large company
              Message 6 of 11 , Feb 17, 2012
              • 0 Attachment
                >
                > Things that work at a small scale generally don't work at a larger
                > scale. This is a truism as far as I can tell, at least for complex
                > systems. There are innumerable examples of this in business,
                > government, engineering, biology, etc. IMNSHO, we ought to always,
                > automatically assume that scaling is the wrong solution and apply
                > Systems Thinking. This goes for "Scaling Scrum" or "Scaling Agility"
                > as well.


                Not automatically, no, but still there is Semco SA and they are a good example of how far you can push democracy and social acceptance in a large company when you are willing to.

                -d
              • Adam Sroka
                ... The principles might be the same at scale, but a complex system, by definition, has so many moving parts and so many interdependencies that there are
                Message 7 of 11 , Feb 17, 2012
                • 0 Attachment
                  On Fri, Feb 17, 2012 at 11:13 AM, DH. <dmalloc@...> wrote:
                  >
                  >
                  >
                  > >
                  > > Things that work at a small scale generally don't work at a larger
                  > > scale. This is a truism as far as I can tell, at least for complex
                  > > systems. There are innumerable examples of this in business,
                  > > government, engineering, biology, etc. IMNSHO, we ought to always,
                  > > automatically assume that scaling is the wrong solution and apply
                  > > Systems Thinking. This goes for "Scaling Scrum" or "Scaling Agility"
                  > > as well.
                  >
                  > Not automatically, no, but still there is Semco SA and they are a good example of how far you can push democracy and social acceptance in a large company when you are willing to.
                  >

                  The principles might be the same at scale, but a complex system, by
                  definition, has so many moving parts and so many interdependencies
                  that there are always, as a rule, unintended consequences. Unless you
                  measure and attempt to understand those unintended consequences you
                  are just locally optimizing. And the effect local optimization has on
                  a complex system can be unpredictable (and unforgiving.) It often
                  surprises me how poorly this is understood, and how rarely it is
                  considered in practice.
                • Michael James
                  ... Regarding Semco, all I really know about it is Semler s own account of it in his _Maverick_ book and an interview I saw. I *want* to believe it s as he
                  Message 8 of 11 , Feb 17, 2012
                  • 0 Attachment
                    On Feb 17, 2012, at 9:13 AM, DH. wrote:

                    Not automatically, no, but still there is Semco SA and they are a good example of how far you can push democracy and social acceptance in a large company when you are willing to.

                    Regarding Semco, all I really know about it is Semler's own account of it in his _Maverick_ book and an interview I saw.  I *want* to believe it's as he described.  Since the Semco story is so extraordinary I'm wishing we had more sources to corroborate it.

                    --mj
                  • Michael James
                    ... Yes, sometimes even deadly. Mike Mayo gives numerous examples of bank execs taking reckless actions not in the banks long term interests to create the
                    Message 9 of 11 , Feb 17, 2012
                    • 0 Attachment
                      On Feb 17, 2012, at 9:23 AM, Adam Sroka wrote:

                      And the effect local optimization has on a complex system can be unpredictable (and unforgiving.)

                      Yes, sometimes even deadly.

                      Mike Mayo gives numerous examples of bank execs taking reckless actions not in the banks' long term interests to create the illusion of rapid growth on quarterly statements:


                      Steven Denning has some related criticism, suggesting businesses should optimize for their customers *first*, and shareholder value will take care of itself in the long run:


                      --mj

                    • JackM
                      i still think there are metrics that you could track that would encourage the team agility but i don t believe you can do it with one kpi My opinion is that
                      Message 10 of 11 , Mar 1, 2012
                      • 0 Attachment
                        i still think there are metrics that you could track that would encourage the team agility

                        but i don't believe you can do it with one kpi

                        My opinion is that you want to encourage teams to deliver completed features early with high quality

                        What we do is we have checkpoints in our release cycle. At each checkpoint we expect teams to deliver to 80% of their feature commitment and of course no known bugs other than fact of life bugs.

                        You need both because they provide the check and balance for the other.

                        While I think it's admirable that they turned down the bonus, i think it's unfair that they can't participate in it - frankly they deserve it most.

                        My 2 cents
                        Jack
                        www.agilebuddy.com
                        --- In scrumdevelopment@yahoogroups.com, Abhilash c <c.abhilash@...> wrote:
                        >
                        > Thanks MJ
                        >
                        > this is a great story :)
                        > Regards
                        > Abhilash
                        >
                        >
                        > On 16 February 2012 22:19, Michael James <mj4scrum@...> wrote:
                        >
                        > > **
                        > >
                        > >
                        > > This encouraging story was sent to me (below). Thought it was worth
                        > > posting here.
                        > > --mj
                        > >
                        > > > Hello Michael,
                        > > >
                        > > > Thanks very much for your message.
                        > > > I did not blog about this, because my blog is still under construction.
                        > > > We are a software company employing about 50 people.
                        > > > A few years ago, our CEO introduced a company wide bonus system, based
                        > > on 5 KPI's. The KPI's were different for every department, to be determined
                        > > by the manager of the departments, like Direct Sales, Helpdesk,
                        > > Development.
                        > > > I told the CEO that, as a Scrum Master (and manager of the Development
                        > > department), I could not decide on these KPI's myself (nor did I want to),
                        > > so I "took it to the team", to coin a popular (and rightly so!) Agile
                        > > phrase.
                        > > > We discussed it in multiple sessions (I did not "lead" these sessions,
                        > > nor did I put my view across, I just asked questions), but the team kept
                        > > coming to the same conclusion: Any KPI we could come up with, either
                        > > infringed on the Scrum principles, or deferred the team from the continuous
                        > > improvement principle.
                        > > > And believe me, we brainstormed about a lot of possibilities: Number of
                        > > story points gotten credit for per sprint, number of iterations per story
                        > > or task, newly reported bugs per sprint, even lines (and characters) of
                        > > code.
                        > > > Our bottom line was, that it just doesn't sound right, quantifying
                        > > performance on any other criteria than working software. And, adult and
                        > > intelligent as we obviously are (I mean, we're Development, right?), there
                        > > will still always be this "hidden agenda" in the back of one's mind, that
                        > > makes one, for example, report two defects in one bug, or write a routine
                        > > differently, to make it larger, in order to positively influence the KPI's.
                        > > It's all unwanted distractions, in the end.
                        > > > So ultimately, we unanimously decided to kindly refuse the offer. Much
                        > > to the surprise of the rest of the company, including management. Priceless
                        > > to see the look on their faces. Funnily enough, no-one asked us to explain
                        > > why. I reported it to the CEO, and he understood. He's into Agile. Thank
                        > > God.
                        > > > Up to this day, we still don't participate in the bonus system.
                        > > >
                        > > > I've used this example on a few occasions myself, because it's very
                        > > illustrative.
                        > > > You're absolutely welcome to share it with other people, if it
                        > > contributes to spreading the word.
                        > > >
                        > > > Kind regards
                        > >
                        > >
                        >
                      Your message has been successfully submitted and would be delivered to recipients shortly.