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

4671Re: SCRUM performance measurements

Expand Messages
  • John Gilman
    Sep 30, 2004
    • 0 Attachment
      Thanks Mike and what a great article! I highly recommend to others
      dealing with similar issues.

      John

      --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
      wrote:
      > 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@m...]
      > 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@e...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@e...
      > Yahoo! Groups Links
    • Show all 19 messages in this topic