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

4668RE: [scrumdevelopment] Re: SCRUM performance measurements

Expand Messages
  • Mike Cohn
    Sep 30, 2004
      Those two will be less productive because they are going to fight it all the
      way. I have absolutely told people "here is how we are doing things and it's
      my way or the highway." There is *nothing* in agile that says you have to
      put up with belligerent people whom you can tell are never going to get with
      the program. I wrote a paper for Cutter a few months ago on how some teams
      need a "Telling" leadership style and some a "Selling" leadership style.
      Your team needs "Telling" right now. They can't be truly agile in that mode
      but you can lead them through that.

      The article is on my site at
      http://www.mountaingoatsoftware.com/articles.php and is called "Situational
      Leadership for Agile Software Development."

      --Mike Cohn
      Author of User Stories Applied for Agile Software Development
      www.mountaingoatsoftware.com
      www.userstories.com

      -----Original Message-----
      From: John Gilman [mailto:jpgilman@...]
      Sent: Wednesday, September 29, 2004 6:44 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: SCRUM performance measurements

      Dear Mike (Ann Landers), your story raises an interesting question
      for me. I have begun working with a new team and am experiencing a
      new problem. The problem is with two of the developers (out of a
      total of 3). They are really resistant to adopting the spirit of
      what we are trying to do. They don't believe in it. They certainly
      do not want to give up their offices and work in a common room with
      the other team members from QA and PM, viewing it as some kind of
      demotion and they are convinced that they will be less productive.

      I fear that what one of them really wants is for me to hand him a
      functional requirements document, he'll retire into his office and
      come back at some point with workproduct. We aren't co-located yet
      and he sleeps through meetings or checks his email on his laptop.
      I'm a huge believer in building consensus and want conceptual buy-
      in, but with this team have failed to date. The last team I worked
      with got it from day one and we had zero issues of this type.

      So here is my question. Did you have any issues like this with the
      team that you took from waterfall to agile? Have you ever told
      anyone "here is how we are doing things and it's my way or the
      highway"?

      John

      --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
      wrote:
      > Hi Patrick--
      > Sorry for taking a few days to reply but I was working on exactly
      this
      > question for a team this week and wanted to have solid answers.
      >
      > This team used a waterfall process from 2001-2003. I switched them
      to Scrum
      > at the start of this year. They write in Java. Here are some
      measurements:
      >
      > 2001-03 2004
      > Lines of code per programmer-month 389 1206
      > Defects per thousand lines 10 2.9
      >
      > Some code metrics as measured in Feb 2004 (2 months after
      Scrumming started)
      > and today. These show improvements in the code being written:
      >
      > 2/04 9/04
      > # of packages 43 118
      > # of classes 718 1,128
      > # of methods 10,451 14,424
      > lines of code 119,950 145,897
      > lines per class 159 121
      > Methods per class 14.6 12.8
      > Lines per class 10 8.4
      > Cyclomatic complexity 2.3 2.1
      >
      > Keep in mind that things like "methods per class" going down so
      much means
      > the new code written using Scrum went down even further because
      the overall
      > average is shown above, not just totals for the new code in the
      right
      > column.
      >
      > Note that throughout, lines of code is "non-comment source
      statements". A
      > caveat: I didn't count the JSP lines in the 2001-2003 version (not
      many of
      > them as much had been migrated back into servlets) or the velocity
      templates
      > in the 2004 system. If those were measured, things would look even
      better
      > for the latter metrics.
      >
      > I think these show a very compelling advantage to Scrum. This team
      became
      > more than 300% as productive (as measured my lines, which is
      somewhat
      > questionable as a measure) and has 80% fewer defects. More
      importantly, the
      > CEO is ecstatic about what the team has achieved. They're 3x
      faster in lines
      > but are probably 10x in delivering business value. For example,
      the team's
      > best programmer spent all of 2003 on a feature that has still not
      been used
      > ONCE. That doesn't happen with Scrum.
      >
      > Let me know if you have any questions,
      >
      > --Mike Cohn
      > Author of User Stories Applied for Agile Software Development
      > www.mountaingoatsoftware.com
      > www.userstories.com
      >
      > -----Original Message-----
      > From: Patrick Steyaert [mailto:steyaert.patrick@p...]
      > Sent: Sunday, September 26, 2004 12:25 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: [scrumdevelopment] SCRUM performance measurements
      >
      >
      > *.*;
      >
      > While introducing SCRUM to software organisations, the question
      pops up of
      > what *bottom-line* improvements can be expected - decreasing
      number of bugs,
      > lower cost of quality, faster time to deliver, ...
      > My question is whether there are people out there, that have
      actually
      > measured such improvements, and whether such measurements have been
      > collected ? Are there experiences in using such measurements to
      actually
      > track progress of introducing SCRUM into an organisation ?
      > All input welcome.
      >
      > Patrick.
      >
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@e...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@e...
      > Yahoo! Groups Links




      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
      Yahoo! Groups Links
    • Show all 19 messages in this topic