I recently attended Certified ScrumMaster training, held by Ken Schwaber. I thought it was a very well run course, and I definitely got to understand how to make Scrum work for a variety of team dynamics.
I'm curious for those who are using Scrum in their projects -- is your ScrumMaster certified? (note: certified, not certifiable) The main reason I ask, is after reading this other Scrum topic its pretty obvious that those over-bearing and micro-managing Scrum Masters are not certified and will surely cause Scrum to fail in their organization.
Has anyone else gone to the ScrumMaster training? what did you think of it?
Would you try to implement Scrum after the training you've had? Or would you prefer to bring in an experienced coach to get going? I suppose the answer depends entirely on you and your team and won't necessarily apply well to me and mine, but I'm curious about how good you felt after 2 or 3 days of immersion. Thanks!
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
After taking Ken's class, reading his book (Agile Project Managment with Scrum), and getting your team up to speed and on board -- yes I would feel comfortable with implementing Scrum.
The course was very engaging -- lots of discussion -- lots of teaching my example -- and lots of shared experiences from the group. There was a pretty good mix of people: a bunch who had not yet implemented scrum, a bunch who had just started, and a bunch who had been doing it for awhile.
Joined: Jan 29, 2003
Thanks! I just sent a paper about Scrum success from the ControlChaos site to my managers. I'd love to prod our team to advance a bit in the art, but feel like a lone voice in the wilderness a lot of days.
I think this is one case where the training would be very valuable. Although a lot of it is simply team lead best practice stuff. I led my first project in 1988 when I knew absolutely nothing about leading a team. I had 4 years experience as a C hacker and had kept my eyes and ears open and learned stuff.
The project succeeded beyond my best hopes, in large part because of my predecessor. He had experience and good ideas but didn't have the technical skill under Unix to make the tools work. The first thing I did was fix the tools and learn from them. I also spent a week with him at his office. That helped a lot. Before that I'd spent hours in bars after work with an older colleague who had run construction projects before moving into IT. I used the Golden Rule and tried never to do anything to someone which I wouldn't like done to myself. If something I tried pissed off one of my people I'd change and try something else the next time. That's about it.
And I took a walk around the floor every morning. Once I had my setup going I'd get in at 9 and have a look at the results of the overnight regression tests to see the state of the built system. Did I mention the overnight builds and test runs? Then I'd get a cup of coffee and walk around and ask how things were going. Any hangups? Ok, I'll get back to you. I had to finish my walk after all. Sometimes it turned out the problem impacted several people. If there was a problem with the build or one or more regression tests failed I'd report that fact in a low-key way to the developer who broke it and tell him the req was re-opened. That was it. I was prepared to come down like a load if it became a habit but it never did. It happened twice with only one guy and that was a strange situation. I was prepared to help out if I could. Actually everyone was on that team. Does this sound a little familiar?
In the space of 6 months we went from taking a month to make a new build to being able to build, test, and redeploy in 2 hours. No big deal today in a world with JUnit, Cruise Control, and Maven. But I'd never seen it done before. We cut the list of outstanding bugs by 90%, improved performance by a large factor and doubled the number of concurrent users we could support at one time on the same hardware. Someone had gotten a bit enthusiastic with malloc(). By allocating initial memory more judiciously we were able to cut the memory profile of a user session by about 40%.
This was all team stuff. I didn't touch a line of C code in 6 months time. I didn't have the time to. Too busy clearing obstacles from my people's paths, negociating bugs, writing tests, packaging work into decent packages complete with a handy-dandy regression test the programmer could run to see the problem(s) and test whether his work fixed the problem. I also expected them to run the short suite of regression tests before dropping the code. Basically everything but the soak tests, which took hours and which I mostly ran over the weekend.
What struck me about SCRUM was the morning SCRUM session. Short and sweet. It was immediately obvious that it would work a charm if used correctly.
The reason I think the SCRUM courses are important is that SCRUM is a tool which can help you a lot or can hurt you disasterously if misused. To make SCRUM work everyone has to drop their defenses and trust. If that trust is violated even by mistake SCRUM can turn into a clusterf... (er, disaster).. I can usually work around a poor team lead but not if I have to drop trou in a SCRUM inquisition every morning. :roll:
Well that was overstated. A single mistake won't kill you, particularly if it is honestly recognized and corrected. It's when it turns into the morning session of the Spanish Inquisition that the wheels fall off.
So if there is a chance you might screw it up spend the sawbuck and talk to an expert. Even if you're not screwing up but others on your team are spend the sawbuck. It costs far less than recruiting a new team does!
Originally posted by Stan James: Thanks! I just sent a paper about Scrum success from the ControlChaos site to my managers. I'd love to prod our team to advance a bit in the art, but feel like a lone voice in the wilderness a lot of days.
Get yourself a copy of "Fearless Change"!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jan 29, 2003
Looks interesting, I might try the library. Right after Maximum City.
My partner in crime architect and I don't usually get conventional coding assignments. But this off the wall requirement came up and mgt decided he was a good fit so they gave him a pile of stories. We've decided since nobody else will do BVCs we will all on our own. We stood a whiteboard on end in the aisle today and started. Got a lot of attention. From "Joel on Software" it just has these columns:
Story | Original Estimate | Effort So Far | Effort Remaining