I first got know Chris when we collaborated to start the very first Seattle Scrum Users Group in 2007 and I’ve been following him ever since. You should check out his blog at http://www.gettingagile.com/.
Have you ever heard or said any of these phrases?
- We are going to implement the Scrum methodology.
- We’re doing a modified Scrum.
- Our developers are using a Scrum process.
These may seem like innocuous statements but they are indicators of potential misinterpretation of how Scrum is best utilized. Scrum is not a full development process (although almost anything that has steps could be considered a ‘process’) and it is not a methodology. It does not tell you how to implement the software. It is a simple-looking framework that will help a group developing products figure out what is not working well so they can fix it. Here is the Scrum framework diagram:
At first, people and teams implementing Scrum focus on the process without understanding why and how to do each piece effectively. We believe that we will be “doing Scrum”, and will gain all of its benefits, by just:
- Keeping a list of work (the Product Backlog)
- Assigning it to the team during a Sprint Planning meeting
- Doing that work over the course of the Sprint
This focus on going through the steps can be dangerous and frustrating for individuals, teams, and managers. Scrum is NOT A SILVER BULLET! No process, practices, or techniques are. Instead of focusing on the process, practices, and techniques of Scrum, I suggest individuals, teams, and management focus on the learning that can be produced by a team doing Scrum and act on that learning.
Scrum is an Empirical Process Control. The idea is that you plan and then do something, inspect what you did, and then adapt your behavior to improve on what you did. It is a learning framework for product development teams. This learning cycle is referred to as “inspect and adapt”. All 3 Scrum roles are involved in the learning: the Product Owner, ScrumMaster, and Developers (when I say developers I mean anybody needed to build the product, not just coders). In Scrum, there are 3 specific “inspect and adapt” cycles:
- The Daily Scrum meeting allows the team to focus on their commitment for the current Sprint and whether they are still on track to deliver on that commitment. If they are not able to meet the commitment then they are asked to adjust the Sprint, thereby adapting to the situation.
- The Sprint Review meeting allows customers to view a potentially shippable product increment created by the Team and provide feedback that adjusts the Product Backlog contents and priorities. We are inspecting the product and adapting to a new understanding of the product.
- The Sprint Retrospective enables the Team to improve the process they use to delivery software each Sprint. The Team is expected to inspect their process honestly and thoroughly to figure out how they can adjust for improved delivery capability in the following Sprint.
If you read my blog often, you might recognize this from a previous post called “Kaizen Mindset” that has good information on how to use learnings and manage the impediments around those learnings.
Scrum is more of a tool than a methodology. It will make visible what is not going as well as it could be. It is then up to people in the team and organization to make changes to improve it. With each incremental improvement the product development team will move that much more effectively on its work. Rather than focusing on getting perfect at the steps in the Scrum framework, find out what can be improved in your delivery process and adapt it accordingly. If a part of the Scrum framework is difficult to do or seems like a waste then instead of eliminating that part, find out why it is difficult or wasteful in its adoption. There is usually a hidden impediment behind these difficulties and perceptions that if eliminated will allow the product development team to be more effective.
Scrum is not a destination. It is rather a tool that a product development team uses to continually inspect and adapt their way to more effective delivery. The destination should be your business and development team effectiveness goals. How can we deliver more product? How can we reduce time from inception of project to release? How can we release more often at a lower cost for release stabilization of the product? How can we reduce the risk in our project delivery and portfolio? The destination should be substantial and worthwhile. Scrum is just the vehicle to help get you there.