4671Re: SCRUM performance measurements
- Sep 30, 2004Thanks Mike and what a great article! I highly recommend to others
dealing with similar issues.
--- In firstname.lastname@example.org, "Mike Cohn" <mike@m...>
> Those two will be less productive because they are going to fightit all the
> way. I have absolutely told people "here is how we are doingthings and it's
> my way or the highway." There is *nothing* in agile that says youhave to
> put up with belligerent people whom you can tell are never goingto get with
> the program. I wrote a paper for Cutter a few months ago on howsome teams
> need a "Telling" leadership style and some a "Selling" leadershipstyle.
> Your team needs "Telling" right now. They can't be truly agile inthat mode
> but you can lead them through that.called "Situational
> The article is on my site at
> http://www.mountaingoatsoftware.com/articles.php and is
> Leadership for Agile Software Development."a
> --Mike Cohn
> Author of User Stories Applied for Agile Software Development
> -----Original Message-----
> From: John Gilman [mailto:jpgilman@m...]
> Sent: Wednesday, September 29, 2004 6:44 PM
> To: email@example.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
> new problem. The problem is with two of the developers (out of acertainly
> 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
> do not want to give up their offices and work in a common roomwith
> the other team members from QA and PM, viewing it as some kind ofproductive.
> demotion and they are convinced that they will be less
> 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
> and he sleeps through meetings or checks his email on his laptop.worked
> 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
> with got it from day one and we had zero issues of this type.the
> So here is my question. Did you have any issues like this with
> team that you took from waterfall to agile? Have you ever toldexactly
> anyone "here is how we are doing things and it's my way or the
> --- In firstname.lastname@example.org, "Mike Cohn" <mike@m...>
> > Hi Patrick--
> > Sorry for taking a few days to reply but I was working on
> > question for a team this week and wanted to have solid answers.
> > This team used a waterfall process from 2001-2003. I switched
> to Scrum(not
> > 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
> many ofvelocity
> > them as much had been migrated back into servlets) or the
> > in the 2004 system. If those were measured, things would look
> > for the latter metrics.
> > I think these show a very compelling advantage to Scrum. This
> > 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
> been usedbeen
> > 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: email@example.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
> > 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
> To Post a message, send it to: scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> Yahoo! Groups Links
- << Previous post in topic Next post in topic >>