Scrum Master Certified

This Monday and Tuesday I attended the Scrum Master Certification tutorial at QCon held right here in San Francisco, California. It was great to have this tutorial right in my own back yard. I wish I could have attended the rest of the convention this week with speakers like Martin Fowler from the Agile community, but alas I was paying for the $1,700 course myself and shelling out extra bucks on top of that didn't seem like a good plan.

The course was two days as I mentioned, and held no surprises for the seasoned Agile/Scrum participant. We went over the product backlog, the sprint backlog, product planning, sprint planning, Scrum artifacts with a lot of emphasis on burn down and burn up charts, and we did some simulations, which is what I want to talk about.

In our simulations we had WAY too much to do in the time box we were given. So for instance, when we were told to prioritize the stories, we didn't really have time to fight over was story A really more important than story B in relation to stories A through ZZZZ (so there were lots of stories). But, we didn't have time to fight. Initially I felt cheated, like the simulation didn't resemble "the real world", but then I got to thinking that it could resemble the real world, if I made it that way. Think about it, why give your Product Owner and the stake holders days to decide what they can decide in hours, or even minutes. The end result will probably be the same that the critical items get in the product before the release, and the rest will possibly go in the next release.

I also got confirmation that technical items, those that don't directly add value to the customer, but help the devs produce better code faster, should also be on the product backlog, which implies that a tech person should be a stake holder. That person could be an architect, a team leader, or maybe even just a team member (and rotate the member). Same thing for maintenance (aka super high priority bugs, that management can't downgrade because they can't set expectations well enough with customers) - put a person on them all the time, but rotate who that person is so he doesn't burn out.

So now I'm a Scrum Master, and I feel confident I could do what a Scrum Master should do, given my new found training and my previous experience with Passageways and my counter-Scrum experience at Jobvite. If you're looking to hire someone with unlimited courage and a good sense of people, feel free to drop me a line.