Strict adherence to the rules of Scrum can lead us astray. To master scrum, we must learn to unlearn. Focusing more on the principles than the rules is what makes truly effective scrum teams.
Many software teams practice Agile development. Agile is simply a set of values and principles for software development. Its main aim is to make software teams nimble and responsive. Agile creates teams that are maneuverable, like a speed boat, as opposed to rigid and difficult to turn, like a container ship.
Agile is principles-based. These principles don’t really give us a way of working. They are best viewed as values as opposed to strict rules.
This leaves us with a problem of having nothing concrete to follow. This is especially difficult for teams new to agile working. To address this problem, we have other agile-friendly frameworks such as Scrum.
Scrum is one of the most adopted frameworks for agile teams, but it can be hard to master. This difficulty is addressed in the Scrum Guide. Creators Ken Schwaber and Jeff Sutherland agonized over this document. It was (and is) their baby. It was edited, fine-tuned, and reworked to make it into a succinct masterpiece.
In the document, Schwaber and Sutherland describe scrum as:
- Lightweight
- Simple to understand
- Difficult to master
The last bullet point was not a mistake: difficult to master. It seems almost like a dichotomy when juxtaposed with the other phrases: lightweight and simple to understand. But there is a reason for this last bullet point …
Scrum advocates a series of rules. To understand scrum, we must adopt these rules. Yet over time, the rules can become a hindrance. Strict adoption of these rules can, in fact, lead us astray. Instead, we should focus on the essence and the principles of agile working.
Before we look at how to embody the essence of scrum, we should first recap the rules …
A Scrum Overview
There are a lot of rules to scrum. We’ll touch on some of them, but the best place to review the rules is in the Scrum Guide itself.
Scrum is a team framework. Its intent is to address “complex and adaptive problems.” It’s for this reason that software teams have relied upon it. Building software is by nature a complex and adaptive domain.
The 3 Pillars of Scrum
Scrum bases itself upon three “pillars.” These pillars form the essence of what it means to be a scrum team.
- Inspection – We must review our ways of working and our output to ensure that it is of high quality.
- Adaptation – It’s not enough to only locate issues. We must also fix them and prevent them from happening in the future.
- Transparency – To inspect our work, we must be able to see it. This means making visible what we’re all working on.
The 3 Scrum Roles
The pillars themselves are very high-level and abstract. To put the pillars into practice, scrum teams have roles:
- The Product Owner (the “P.O.”) – The business domain specialist. They know the customer and their needs. The P.O. makes decisions on what the team should work on, as opposed to how they work.
- The Development Team – The people who complete the work. Team members are not given specific roles, as they are expected to pick up a wide range of work. To achieve this, they must be highly skilled.
- The Scrum Master – The servant leader. The scrum master supports team members in adopting scrum practices. They can be considered the opposite of the P.O. as they are more concerned with how the team works than what they work on.
The 5 Scrum Events
Scrum teams also have events:
- The Sprint – Scrum teams work in short bursts, called sprints—periods of uninterrupted work. Sprints result in a complete package of work. Not half-done or 99 percent done. Done-done.
- Sprint Planning – Before a sprint, the team plans their next deliverable. Sprint planning ensures everyone is aware of the details of the work and the goal of the sprint.
- The Retrospective – After every sprint, the team stops completely. The team establishes what went well and what didn’t go so well. Action items emerge, and the team improves with every sprint.
- The Daily Scrum – Every day, the team assembles to discuss progress toward the goal(s) of the sprint. During the daily scrum, the team inspects previous work and decides on their next tasks.
- The Sprint Review – This is an opportunity for the rest of the business to inspect the work delivered in the sprint.
The Scrum Artifacts
Often lesser known and understood are the scrum artifacts:
- The Product Backlog – An ordered list of future changes for the product. It is never complete and is always evolving.
- The Sprint Backlog – The sprint to-do list. It includes all the features and bugs to be completed.
- The Increment – The work completed at the end of the sprint. In software, this is shippable work. It’s been tested and is high-quality.
Rules, rules everywhere!
Phew, that’s a lot of rules! Congratulations on getting this far! But this is where things get interesting.
As a new team, adopting the rules is a great idea. It gives you a feel for how scrum teams work and provides you with a clear model to work from.
In their enthusiasm, new scrum teams often push to make improvements to their ways of working. To do so, they frequently turn back to the scrum guide and back to the rules. Morning stand-ups are cut short. Retrospectives have actions that are followed up.
After a while, teams start to stagnate … This is often where teams end up—following most of the scrum rules but still with a feeling in the pit of the stomach that we could do better. Often these teams return to the rule book, or worse, they can become jaded at the prospect of improvements.
What can programmers do to make their teams more effective when there are so many rules to follow?
The Secret of Scrum: It’s Not About the Rules
After having worked on many different scrum teams, I’ve come to observe a phenomenon …
Strict adoption of the scrum rules doesn’t equate to effective teams.
The rules, as always intended, are guidelines. They’re the training wheels that get you started and build your confidence. But after a while, to go faster, we actually need to remove our training wheels.
I call this issue the “learning scaffolding” problem. Often when we first do something, we have to establish some rules. These rules help us gain our confidence. This is akin to how scaffolding forms the rough outline of a house. Yet when the house is built beyond a certain point, it becomes self-sufficient. It can stand on its own. At this point, we should take down the scaffolding and allow the building to stand free, in all of its glory.
Embodying Agile Principles to Become an Effective Scrum Team
As we take down the scaffolding, we then turn our attention to the principles and values of agile teams. To become effective, instead of tightening the rules, we can tighten the essence. We can start to embody the principles and the values of agile teams.
The following list includes some ways that we can embody these agile principles and values. It is by no means an exhaustive or definitive list. Unfortunately, the steps to becoming a truly effective scrum team cannot be codified.
Some of the following ideas are taken from Peter Senge’s acclaimed book The Fifth Discipline: The Art & Practice of the Learning Organization. In The Fifth Discipline, Senge outlines 7 “Learning Disabilities”. These 7 Learning Disabilities refer to mentality based issues that prevent teams from learning and adapting. While not an agile (or a scrum) book per sé, many of the ideas contained can be used to create effective scrum teams.
1. Shared Vision
Author, marketer, and business owner Seth Godin is renowned for his attack on what he calls “factory” thinking. Godin believes that too often, we take an old-school approach to management. He argues that this approach doesn’t work in today’s creative and complex fields.
During the Industrial Revolution, factory workers were masters of doing the work right, not doing the right work. But most of the modern world has changed. We now need to know how to find the right work. Our organizations need to be up-skilled in decision making centered on effectiveness. This means we can’t treat our employees or our colleagues as we once did in the factory. We can’t relapse into command and control.
What is our alternative? Shared vision, not vision by itself. Scrum teams advocate having what is known as a product vision. This means that all members of a scrum team have a very clear understanding of what they are trying to achieve. The team should then intuitively know which tasks add value and which do not.
It is not good enough for only one individual to understand the vision. All the team members must share the vision. They must feel connected to it on a deep level. Not only is this effective for decision making, but it’s effective for creating purpose. Purpose creates motivated teams. Teams are more effective when they know why they’re doing something. Needing to now why is not a new thing for millennials; humans are, by nature, philosophical beings.
Shared vision is critical to effective teams … we lose our way when we lose our why.
2. Effective Always Trumps Efficient
David Heinemeier Hansson and his business partner Jason Fried are well-known for their crusade against glorified over-working. While building their company Basecamp, the duo came to a realization: hours worked did not in its own right create more effective teams. Instead, what they found is that individuals need time to reflect and relax.
Connected to the first idea of shared vision, once we know where we’re going, we need time to frequently pause. This allows us to take in our current situation and meditate on our next moves. To come out of thinking about the status quo and instead, think about taking it up a notch. “Amount of time we spent in our seats” or “lines of code” pale into insignificance against delivered value.
We must remind our teams that being effective always trumps being efficient. Doing the right thing is more important than doing the thing right.
3. Challenge Mental Models
One of the greatest threats to effective teams is what Senge defines as mental models. These mental models are the “baggage” that we bring with us to new teams. Working in a scrum format can, at times, be counterintuitive. The reason for these unsettled feelings can often stem from our previous experiences. Rather than challenging our old views, we can begin to project them onto others. If we don’t inspect our mental models, we risk poisoning our ability to see things from a new perspective.
A good example of mental models is the trap of short-term mindset. This mindset isn’t helped by the fact that scrum operates in micro-deliveries. It can be all too easy to become very far removed from the distant vision we have for our product. Instead, we can fall into the trap of focusing on the ever-praised “quick wins” but never solving the “big domino.” The big domino, after all, will topple the rest when it falls.
Our mental models, if not addressed, can bring even the most effective teams to a grinding halt. We must frequently inspect not only our work but our mindsets.
Focus on the Principles to Master Scrum
Effective scrum teams focus on principles, not rules. Achieving this mindset comes with deliberate practice. Effectiveness comes when we analyze the work, our teams, and our mindset.
As humans, our greatest assets are our cooperation, intelligence, and ability to adapt. This potent mix is what led us to become the rulers of our planet. It wasn’t sharp claws or jagged teeth, nor was it the ability to follow rules to the letter. What separates us from the animals is our ability to adapt.
As Senge describes in his aforementioned book, The Fifth Discipline:
“In the long run, the only sustainable source of competitive edge is your organization’s ability to learn faster than its competitors.”
It’s our job as programmers to learn and to adapt. There is no silver bullet—no rule or map that can guide us there. It’s up to us to figure it all out.
| Reference: | Focus on the Basics: The Art of Mastering Scrum from our JCG partner Lou Bichard at the Making the Complex Simple blog. |
