Get certified - Transform your world of work today

Close

Practicing Scrum

Building mastery, one day at a time

23 June 2016

Gregory Engel
The Regis Company


Old joke: A young couple visiting New York City for the first time has lost their way. They spot a street musician, just the person to help them get reoriented. "Excuse us, but can you tell us how to get to Carnegie Hall?" The musician stops playing and thinks for a moment before replying, "Practice."

The prevailing wisdom is that it takes 10,000 hours of practice to achieve the level of mastery in any particular field of endeavor. Turns out, this is true for fields with well-defined measures for excellence, such as chess and music. In each of these areas, the rules are relatively simple, but mastering them isn't easy. It's pretty easy to tell when someone is playing an instrument out of tune or off beat. And yet, a pawn shop guitar in the hands of Joe Satriani or Liona Boyd will likely result in that instrument expressing a voice no one knew it had. As for chess masters, they're the ones who win against all challengers regardless of the time or place of the match.

For areas of human endeavor in which the edges are less well defined, such as business or coaching, there may be no marker for how much practice it takes to reach a stable mastery. Having successfully started and built one business does not guarantee that the next venture will be equally successful. A coach with a winning system for one team may end up at the bottom of the ranks when the same system is used with a different team.

As for developing expertise with Scrum, the rules are simple but not easy to master, as is often said. The territory isn't well defined and frequently changes. A new client, a new team, a new project, and the edges for what is possible all change. Misunderstanding this has been the root cause of much frustration that I've observed among people new to Agile. They come from a world with well-defined edges — traditional project management practices filled with Gantt charts, milestones, functional specifications, use cases, deployment requirements, and a plethora of other artifacts that "must" be in place before work can begin. As many unknowns as possible must be made known, risks pounded down to trivial annoyances, and all traces of ambiguity squeezed out of the project plan. Learning how to let go of deeply rooted practices like this is no small feat. We like the comfort of well-defined rules. And when there's work to be done with scarce resources to make it happen, we reach for the rules most familiar to us.

So how can we update the tried-and-true, super-comfy confines of past practices and rule sets?

Practice.

Research on the "10,000 hours of practice" generalization has shown that it isn't just that someone has completed 10,000 hours of practice. The critical factor was how they practiced. Was each hour spent completing the same motions and behaviors from the previous hour, or were they spent building on successive experiences, seeking greater challenges, and developing a deeper understanding of their craft? Following the latter path leads to the incremental improvements required to build mastery. And once obtained, the same attitude toward practice helps sustain a level of mastery. There will always be something more to learn, a fresh perspective to experience, or a more satisfying way to experience success.

There is a great deal of neuroscience at the foundation of practice, and few would dispute the value of learning how to learn. And yet as our experience grows and we master a particular field, it's deceptively easy to fall into complacency, convincing ourselves there isn't anything else to learn. That is until some seismic paradigm shift makes it clear that the rules have changed, and we'd let our mastery go stale. The consequences of this are captured by Greene (2012) in his book Mastery:
 
"We prefer to live with familiar ideas and habits of thinking, but we pay a steep price for this: Our minds go dead from the lack of challenge and novelty; we reach a limit in our field and lose control over our fate because we become replaceable." (p. 176)
If this happens, learning how to learn may not be enough. Learning how to unlearn may be equally valuable for regaining mastery.

In classic hacker culture, you aren't a hacker until other recognized hackers call you a hacker. It's a title to be earned, not claimed. The unfortunate title of "ScrumMaster" aside, it is useful to take this credentialing tradition to heart with Scrum as well. Consider yourself an apprentice Scrum practitioner until other recognized ScrumMasters recognize your mastery. Holding such a frame keeps us humble, curious, and open to constant and never-ending improvement.

I've been practicing, leading, or coaching Scrum in one capacity or another for more than ten years and, based on my billable hours over the past several years, I'm quite confident that I've passed the 10,000-hour mark for practicing Scrum. Even so, I'm not a master ScrumMaster — yet. The reason is simple and is expressed best by the great cellist Pablo Casals' response to filmmaker Robert Snyder's query as to why he continued to practice five hours a day at 80 years of age: "Because I think I am making progress." I keep building upon my practice because each day I discover new ways to enhance team performance and improve my skills. Perhaps more telling, any time that I think I've heard every excuse for not following the Scrum framework, someone on one of my teams surprises me.

If you're interested in staying on the path toward Scrum mastery, you need to get out of the books and into the world. There are a variety of ready opportunities to mark and gauge your progress.
  • Frequently review the framework for Scrum and compare what's there with your current projects. If there are mismatches, find out why. Is there really a good reason for straying from the framework? If so, open a dialogue about these differences during your retrospectives.
  • If possible, ask your fellow Agile practitioners when they are holding their next review, backlog refinement, or sprint planning session and get yourself invited as an observer.
  • There are probably a number of excellent Agile-related meet-ups in your area. Speaking from personal experience, these are incredibly valuable communities of support and new ideas.

Reference
Greene, R. Mastery. New York: Viking Penguin, 2012.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.8 (5 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe