Earlier this week, I drove down to Phoenix to attend a ScrumMaster training workshop presented by Certified Scrum Trainer (CST) Mike Vizdos. Mike is the guy behind those Scrum “chicken and pig” cartoons; check out his Implementing Scrum website. The Agile Alliance has a pretty open-ended approach to training, and each CST pretty much does it in his own way. I looked at several workshops coming to the southwest and California over the next couple of months, and chose Mike’s. Good choice.
There were 22 of us in the class, with eight folks from one company, and smaller groups from a couple of others. Mike had Phoenix local Alan Dayley on hand as co-presenter. The morning of day one was the intro – Agile principles, the basics of Scrum, and an explanation of backlogs and burndown charts. As the day progressed we got into Scrum roles – Product Owner, ScrumMaster, and Team Member. A simulation involving Martian tourism got us engaged, but also demonstrated the criticality of the Product Owner to the team’s ability to make progress. We discussed Bruce Tuckman’s “stages of group development” model, and talked about the ramifications of disruptions to the process of becoming high-performing teams. We also briefly addressed retrospectives. At day’s end, Mike made a point of warning us not to try to implement Scrum all at once, at the risk of massive rejection. “Don’t spook the herd,” I murmured.
The next day, we got into Scrum values (as opposed to the values expressed as preferences in the Agile Manifesto). Mike uses the acronym FORCE, for focus, openness, respect, commitment, and extreme courage. We also talked extensively about user stories, including an interesting simulation. We explored various estimation techniques, including planning poker, and defining “done.” Along the way, we ran through more simulations, to let us practice the concepts. The notion of velocity, expressing the ability of the team to process items from the backlog in the most recent sprint, was the subject of one simulation. It helped me understand why the Scrum approach requires a planning session for every Sprint, and why we don’t just carry over backlog items not completed.
The longest simulation of the workshop had us run through a sprint planning meeting and three seven-minute iterations, without benefit of a ScrumMaster or retrospectives, and with various disruptions by the CEO and a compliance consultant. Some CST’s construct exercises that let the teams succeed; Mike ensures they fail, under the theory that you’ll learn more from failure. The teams were continuously reset into forming and storming, and progress essentially stopped every few minutes while we re-grouped. The post-mortem on the simulation certainly had a lot of findings, so I’d say the approach works.
As a project manager, my interest was in determining how to best integrate a development effort using Scrum methods into a larger project using traditional critical path methods. My principle insight during the course was that the Product Owner was the scope driver, and therefore best positioned to work closely with a project manager external to the team. Indeed, the role of ScrumMaster is focused on managing team dynamics, preventing external influences from creating disruptions, and ensuring adherence to the Scrum methods, rather than optimizing for delivery according to an externally developed plan. This explained a lot of the comments and blog posts I’ve been reading lately, expressing antipathy toward project managers. It’s not that Scrum teams don’t create schedules; they simply reserve the right to continuously adapt the schedule to the release backlog, and vice-versa. Fair enough, but I’ve gotten weary of horror stories about pointy-haired project managers.
Highly recommended. To enroll in one of Mike’s workshops, check out his website. For more insight into the Product Owner role, check out Peter Saddington’s recent post on ten essential Product Owner characteristics.