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

4675RE: [scrumdevelopment] Re: SCRUM performance measurements

Expand Messages
  • mike.dwyer1@comcast.net
    Sep 30, 2004
    • 0 Attachment
      Right on Mike!
      Some times the biggest impediment to productivity is the prima dona.
      By giving them the choice between what your doing and the highway, these folks get a chance to either take off their toe shoes or see how far they can tip toe down the road
      --
      Mike Dwyer

      "I Keep six faithful serving-men
      Who serve me well and true:
      Their names are What and Where and When
      And How and Why and Who." - Kipling
       
      -------------- Original message --------------

      > 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"
      > 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
      >
      >
      >
      >
      >
      >
      >
      > ------------------------ Yahoo! Groups Sponsor --------------------~-->
      > $9.95 domain names from Yahoo!. Register anything.
      > http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/9EfwlB/TM
      > --------------------------------------------------------------------~->
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      > <*> To visit your group on the web, go to:
      > http://groups.yahoo.com/group/scrumdevelopment/
      >
      > <*> To unsubscribe from this group, send an email to:
      > scrumdevelopment-unsubscribe@yahoogroups.com
      >
      > <*> Your use of Yahoo! Groups is subject to:
      > http://docs.yahoo.com/info/terms/
      >
      >
    • Show all 19 messages in this topic