RE: [scrumdevelopment] Digest Number 258
Good idea, this makes me think in SIP (software in progress) measure that Kent Beck is developing; SIP try to measure the goodness of a project applying XP.
From: db [mailto:kid_danomite@...]
Sent: Sunday, March 02, 2003 1:39 PM
Subject: Re: [scrumdevelopment] Digest Number 258
I think you would have to certify teams or organizations, as opposed to simply the scrum master. There are two ares that drive my thoughts:
1. Individuals are the most important part - not just one person, but the team, and the management too. If the team is weak, even a strong scrum master can't save the day. It would still be one person telling everyone else what to do & not self organization.
2. In the end, its the results that matter. Thus, teams may self-organize for a process that works for them (for example, I work with a global team where we have only 2 weekly meetings because it means someone is losing sleep to participate). So as long as you can track the effectivness of your results, you should be able to self-adjust.
Based on the above, I suggest that we certify teams / organizations based on ROI of their software development. I feel strongly that once one has worked in an efficient environment, one never wants to go back.
It isn't that I'm blind to the problems you mention. I've seen it in my company as we have new groups starting up scrum. I simply stress two points to aid them. First, I re-use your maxim, when you start, use all the parts of scrum because the process is like a watch - it may still look like a watch if you take out the springs or the gears, but it won't work very well. Second, I make sure the teams inject a feedback cycle at the end of each sprint to correct whatever isn't working for them. This is usually enough to get teams going.
Date: Sat, 01 Mar 2003 21:31:18 -0000
From: "Ken Schwaber "
Subject: Certified ScrumMaster
Over the last year, I've seen more and more bad Scrum implementations
(do we really need daily Scrums? why can't I tell the people what to
do during the Sprint?). I've also seen and heard about even worse
implementations (or claimed use of) XP. Although we've made every
attempt to help people understand Scrum and XP with our books,
websites, talks, and articles, we're still coming up short.
I talked with Mark Paulk, one of the authors of CMM. He is pleased
with his efforts, but discouraged at what CMM has turned into. His
estimate is that over 2/3 of all CMM implementations are "trash."
These are implementations that focused on getting certified, not
improving the software process. Cnsultants did it to make money even
though they really didn't know what they were doing.
Scrum isn't something that is intellectually apprehended. As Mike and
I wrote in our book, it has to be experienced, with management
becoming facilitators, telling the teams what to do. And the teams
owning the entire development iteration, the how to do it. Yet this
has tremendous trouble getting across. And it's getting worse, both
as we move from early adopters to the mainstream, and as more people
start to scale Scrum and XP. I think people mistake iterative
development for agile development and let it go at that.
I had a long conversation with Martin Fowler about this and he
suggested that we launch the idea of the "Certified ScrumMaster."
This is someone who really knows Scrum, getting it both emotionally
and intellectually, through reading, thinking and - most important -
experience. When we hear of a bad implementation, we can ask, "did
they use a Certified ScrumMaster?" Or, when someone wants to get
going, we can recommend a Certified ScrumMaster to them.
I'm considering implementing such a program to do what I can about
ensuring the consistency and quality of Scrum. I'm early in thinking
about this and want to solicit your comments and conversation
regarding whether to do this (I'm pretty set on it at this point, but
could be swayed) and how to do it (suggestions are welcome).
Thanks for the help!
KenTo Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.