In the first 22 chapters of this book, I laid out the Scrum framework and explained what I believe to be essential Scrum. You should now understand the mechanics of using Scrum to deliver innovative solutions. You should also have a good sense of why Scrum prescribes particular roles, practices, artifacts, and rules. Now you are ready to define your path forward. This chapter discusses the idea that there is no universal, final target for your Scrum implementation; instead, you need to define your own unique route towards agility. I end by describing the role of best practices and how to use Scrum, with its iterative and incremental approach, as the basis for discovering your own path forward.
There Is No End State
Being highly proficient with Scrum, and thus being more agile, is not your end goal. It is, rather, a means of more effectively and economically achieving your business goals. So how do you know when you're done learning Scrum?
There is no definition of done for a Scrum adoption or transition to agile. There is no agile maturity model “Level 5.” To say, “I have finally achieved agility!” is a meaningless comment. Instead, becoming proficient with Scrum is a process of continuous, never-ending improvement aimed at growing your bottom line.
Discover Your Own Path
Just as no one can tell you where your Scrum implementation should end, no one can lead you down a predefined path that will guarantee success. Instead, you must use the feedback loops inherent in Scrum to learn, inspect, and adapt your way forward based on your organization's own unique goals and culture and the ever-changing complex environment in which you must operate.
Sharing Best Practices
If there is no “one right path” to follow, how do best practices fit in? First, let's agree to call these “best approaches.” Practices are how I describe the core aspects of Scrum. I think of an approach, on the other hand, as a particular implementation of a Scrum practice. While two teams might have different approaches, they should both adhere to the same core set of Scrum practices.
Many organizations try to describe what a succesful Scrum team is doing, capture it, and then institutionalize it as a best approach. Doing so can be harmful, because individual team approaches are highly contextual, and might not work for other teams. Teams should share approaches that have worked for them, but those approaches should only be adopted by another team when it makes sense for that team's unique culture, environment, and situation.
Using Scrum to Discover the Path Forward
No matter where you are in your Scrum implementation, you can use the principles of Scrum to guide you on your path forward. Keep a backlog of improvement ideas, or on a larger scale, change initiatives. Work in sprints to iteratively and incrementally implement the improvements and changes you'd like to see. Inspect: See how the implementation is going. Then adapt your path forward accordingly.
It always amazes me that the same people who concede it isn't possible to get the requirements for a product correct up front, and therefore want to use Scrum development, will in the same breath tell me that they aren't quite ready to use Scrum because they haven't worked out all the details yet. Don't worry about getting things perfect up front. You can't! Try Scrum for a few sprints and see what happens. Try to improve a little each sprint.
You should expect to run into problems and impediments along the way. Experiencing difficulty doesn't mean Scrum isn't working: It likely means you're starting to expose some of the dysfunctions that have been there all along.
And you should expect to encounter some resistance. Change is never easy. Help make it easier by educating others about the principles that underlie Scrum and the goals you are trying to achieve. Work with the naysayers, not against them, to chip away at the obstacles that prevent your team, your product development effort, and your organization from realizing the full benefits of your Scrum implementation.
I wish you all the best of success!