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

4658Re: SCRUM performance measurements

Expand Messages
  • John Gilman
    Sep 29, 2004
    • 0 Attachment
      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


      --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
      > Hi Patrick--
      > Sorry for taking a few days to reply but I was working on exactly
      > 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
      > 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
      > 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
      > in the 2004 system. If those were measured, things would look even
      > for the latter metrics.
      > I think these show a very compelling advantage to Scrum. This team
      > more than 300% as productive (as measured my lines, which is
      > 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
      > measured such improvements, and whether such measurements have been
      > collected ? Are there experiences in using such measurements to
      > 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
    • Show all 19 messages in this topic