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 “A 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.
Chris,
Great post, Scrum has done a great job of getting agile into the conversation. It has help to bridge the gap between the XP approach and business, and the visibility of the burndown when it’s working well is just fantastic.
I don’t think Scrum as it exists today is really where we will be in the future but it has helped to move us a long way forward.
Andrew
I work in a small team as part of a larger department at the University of the West of England. We develop solutions for SharePoint as well as managing the SharePoint infrastructure. We had a VERY large influx of requests for work and we realised the only way to manage the development cycle without implementing a overly formal methodology was to implement something like scrum. We did this and as you say, we probably learned a hell of a lot about the way we work, and the assumptions about how we thought we worked. The performance benefits? Yes. Sustained over time? Well, there has still been a higher throughput and better communication between the team members. Was it worth it? Absolutely yes. But it is an ongoing thing as you say, not an end in itself, and we are evolving the process to fit in with some of our demands.
“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.”
How about focusing on the principles and have mgmt help infuse that culture?
I don’t doubt that could work. What I have found is that it is difficult for management to infuse that culture if they don’t know what that culture should look like. We use Scrum as a vehicle to help infuse the cultural shifts and shed light on the issues that need resolving.
The learning cycle built into Scrum is what helps cultural change take shape, in my opinion.