If you’ve ever wondered why Scrum is called Scrum, a quick Google search yields:
When Jeff Sutherland created the Scrum process in 1993, he borrowed the term “scrum” from an analogy put forth in a 1986 study by Takeuchi and Nonaka. In that study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the scrum formation used by rugby teams.
A scrum (short for scrummage) is a method of restarting play in rugby that involves players packing closely together with their heads down and attempting to gain possession of the ball.
Most of us know this history already; this isn’t anything new. I think it’s more common today to hear discussions centered on “doing” versus “being” Agile or “getting” Scrum. I’ve heard that, as with the board game Othello, it’s “A minute to learn, a lifetime to master.” You can dive into Scrum values of courage, commitment, respect, focus, and openness. Also you can contrast old-school command-and-control style to self-organizing teams (the post Scrum and Self-Organizing Teams does a great job on this). Not all command-and-control is bad. It is possible to value people and their perspectives while incorporating a servant-leader style and still get things done. This speaks more to management style than to methodology, however.
I recently finished reading Learning Agile: Understanding Scrum, XP, Lean, and Kanban by Andrew Stellman and Jennifer Greene. It’s a great read, particularly if you like a narrative style. I think the book gets to the heart of being versus doing Agile. You’re like a fly on the wall observing a team as they adopt and struggle with the Scrum method. If I had to pick two words to describe a big takeaway from the book, they would be: collaboration and ownership. Since I’ve grew up loving baseball and never played or even watched rugby, I think baseball might be a better analogy for some. Let me explain.
Whatever the level, the most successful baseball teams have a few things in common. The players are skilled at what they do, and they are committed to winning. This is obvious. What is not so obvious to most is what happens as the game unfolds. Not everyone is a home-run hitter, nor is it desirable for everyone to be. When a team is at bat, the players in the dugout must pay attention to the situation on the field. Hitting is more than just taking some swings. It’s about knowing the situation and adjusting to it. It’s late in the game, and we’re a few runs down. Should I bunt the runner over? Should I hit behind the runner so that they can advance to third base or maybe even score? What are my strengths in this situation? On the field, when a fly ball is hit between center and right field, you’ll see one player back up the other player as they catch the ball. The same thing happens when a ground ball is hit between shortstop and third base. Even the pitcher covers first base when a ground ball is fielded by the first baseman.
So at the end of the above blog post on self-organizing teams, they ask, “So how would you build courage on a team? How would you get a team to believe in themselves, and believe that Scrum will not only help them build more valuable software but that the company will see the value in their new methodology?”
I’ll put my answer in the vernacular of baseball: Put your team in the best possible position to win (i.e., deliver valuable software). This starts at training camp, where skills are assessed, improved, and honed and practices are perfected. It’s also a place where bonding occurs. Really look at your team. What do they need? (Remember, the manager doesn’t win games, the team does.)
- Does someone lack confidence?
- Is there an adequate cross-pollination of skills to help minimize work bottlenecks so that more than one person can cover a task?
- Is the team made up of people who are open to helping others?
- Does the team really understand how what they do supports the vision and strategy of the product or organization? Do they feel like a partner in this effort or just the tail end being wagged to and fro?
- Has anyone ever said “Thank you” to them?
Better baseball teams, like software teams, will do the “little things,” being observant and understanding of the situation. Not everyone is a home-run hitter, but everyone should be able to help manufacture runs. That is, win by delivering valuable software, covering for each other, and knowing their strengths and weaknesses. This is what I think is meant by collective commitment and gets you and your team closer to being Agile.