» Scrum Framework
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.
In my previous article, I argued that using a distributed team with the Scrum Framework was a bad idea and advised against it. There is sufficient information to show that distributed Scrum teams perform poorly compared to those that are co-located. However, everyone does it anyway! As Jeff Patton once said, “if you want to run a marathon with ankle weights, don't complain to me about your time!”
Recent studies show that 3 out of 4 Scrum Software Development Teams are distributed, meaning that at least some of the team members are not in the same location. Co-location is one of 12 factors that can contribute to or detract from high-performing teams. This article explores the 12 factors that contribute to high performance when using the Scrum Framework, and then explores how having a distributed team affects.
Last month I wrote about bad Scrum and other abuse of the Scrum Framework. One of the common abuses that I see in organizations using Scrum is that they don't properly use the 3 Scrum roles. To be effective, these three Scrum roles need to be implemented properly and protected. Like bowlers in a bowling alley, we need each of the roles to stay in their lane.
We’ve all seen it - Scrum Gone Bad
I think we have all seen Bad Scrum and misuse of the Scrum Framework. Sometimes Scrum started out good with a solid understanding of Scrum, good leadership, an effective Scrum Master, an engaged and empowered Product Owner and a hopeful and open-minded Dev Team. But then somewhere along the way it went bad. Maybe the leadership changed or changed their mind. Perhaps the skillful Scrum Master left and was replaced by one who was ineffective. The team may have soured or felt like Scrum was used against them.
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 have a client that has been using Agile and the Scrum Framework for the last 3 years. Let me restate that, this client has been using A.I.N.O. (Agile in name only) for the last 3 years. I am working with him to implement Scrum and eventually embrace a full Agile Transformation. With him and his team I have to refer to this as implementing a "more disciplined Scrum" because unfortunately, everyone believes they are already using Scrum.
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.