» Scrum Methodology
Several years ago I had the opportunity to support a growing consulting firm to move from waterfall development to the Scrum Framework. It's been exciting to watch Highland Solutions learn, adapt, and grow as a team in their ability to organize and deliver great client solutions. The attached Case Study on Transition to Scrum describes the approach that Highland used to move from Waterfall to Scrum, and some of the things that they learned along the way.
Inevitably, when working with organizations and helping them move from Waterfall to the Scrum Framework, there is a lot of confusion about the Scrum Master role. One of the most common questions I get is, What does a Scrum Master do? People often ask the follow-up question, Can we make our Project Managers the Scrum Masters? (Yes you can but no you should absolutely not.) And third, Do we need a full-time Scrum Master?
The new Scrum Guide, the definitive reference for the Scrum Framework, is out. As of November 7, Scrum co-creators Jeff Sutherland and Ken Schwaber have published an updated version of the Scrum Guide. The last three revisions were in 2011, 2013 and 2016 so this is a relatively fast update since July 2016.
I always thought that crew looked like a cool sport and I've admired crew teams. In crew, team members in lightweight boats race to go as fast as possible. It is hard work! I think the crew team is a useful metaphor for Scrum teams.
Crew teams strive for speed so they keep everything as light as possible by eliminating anything heavy or unnecessary. The more strong people that are rowing, relative to the weight of the boat and everything on it, the faster the boat will go.
This is part two in my series of posts about improving your retrospectives. As I mentioned in my previous post, the retrospective is a key part of the Scrum Framework - I think it is the most important Scrum event. It is designed to help the team make their processes and practices more effective and enjoyable. This post focuses on the first part of the retrospective where we set the stage for the rest of the retrospective meeting.
In my last post I talked about the Scrum Retrospective meeting and how the speed of the retrospective event was not the most important thing. The retrospective is critical element of the Scrum Framework. It is a continuous improvement process to help the Scrum Team become more effective and enjoyable. In this post, we are going to explore how the retrospective helps the team improve, and introduce a structure for planning retrospectives.
Most people are aware of the retrospective meeting that is part of the Scrum Framework. It is a key improvement activity used by Agile and Scrum teams at the end of each sprint or iteration. This past week I was coaching a Scrum team and I witnessed one of the fastest retrospectives ever. The entire meeting lasted 13 minutes and there were 9 participants. Fast? Hell yes! Efficient? Perhaps. Effective? Not even close!
Earlier this week I was facilitating a discussion on agile estimating at a Meetup. A question came up about whether or not the Product Owner of a team using the Scrum Framework should participate in team estimation via planning poker. The majority of the people felt that the PO should not be included. A minority of the people felt that it was OK to include them, and I agreed. What do you think? Do you include or exclude the Product Owner when estimating?