Why is Scrum so easy to understand but incredibly hard to master?
It’s been said that scrum is easy to understand, but incredibly hard to master. I don’t know if that’s true. I don’t think that scrum is easy to understand, there are thousands of books, videos, and blogs on the topic so it would be fair to say that scrum can be tough to understand.
Hard versus Easy
There appears to be a school of thought which concludes that if something is difficult to understand, and difficult to master, it must be broken or irrelevant.
I disagree with that.
Running 100 metres in an Olympic record time is incredibly difficult, and it would take me a great deal of time and effort to achieve that, but it doesn’t render that sport broken or irrelevant.
Some things simply take time to understand, implement, and master.
What makes scrum hard to master.
In many ways, it is our accumulated baggage that makes scrum hard to understand and implement.
If you walk into a startup environment, filled with heaps of recent MIT graduates (Massachusetts Institute of Technology) and a dynamic, agile leader leading the flock, you’re likely to find that agile and scrum would be quickly understood, adopted, and mastered within that environment.
If you walk into a bank that has 250 years of history, and you need to integrate the board members with senior managers, and mid-level managers, and junior managers, all the way through to the people who work at the coalface, it’s going to be hard.
If the people who work at the coalface haven’t seen an executive in all their time at the company, but frequently must follow instructions, policies, rules and ‘best practices’ passed down from those senior leaders and executives; it will be hard for that person to grasp the nature of agile leadership and how scrum develops autonomous, collaborative, and creative teams.
They simply have no frame of reference for agile, nor could they imagine taking a decision without getting approval or sign-off on that first. They couldn’t imagine taking the lead and speaking truth to power about what needs fixing, what resources they need, and what great would look like in future.
If they did that today, they would be fired or demoted.
So, adopting scrum and mastering the agile framework effectively depends on your frame of reference for work, product development, or even project management.
Transparency.
One of the pillars of empiricism, which is a foundation of scrum, is transparency.
Transparency means:
- Making language transparent. Say what you mean and mean what you say.
- Making jargon transparent. Everyone understands what you mean when you use a term.
- Making plans transparent. What are we attempting and why does that matter.
- Making strategy transparent. This is what we want to achieve, and this is why.
- Making work transparent. This is what we are doing, this is how it is progressing.
And so forth.
Now, if your team all arrived from Intel, that would be ok because it is common practice to have OKRs (Objectives and Key Results) visible at all times. A kind of visual scoreboard for everyone to see what you are working on, how that aligns with strategic objectives, and how you are performing.
If you work in an organization where things are opaque, mistakes are swept under the rug, and senior managers build fiefdoms rather than strong team environments, adopting scrum is going to be really, really, really hard.
Consumption versus Comprehension
It is easy to read the words in the scrum guide, and straightforward to follow how the agile framework is structured.
It is hard to grasp how this came to be, the underlying principles, theory, and learning from agile environments that underpins Scrum.
It is even harder to apply these theories, principles, values, and concepts in a live environment where people are under pressure to deliver a working solution to a client every few weeks.
They are up against organizational policies and internal working agreements that are completely out of alignment with agile values and principles. Out of alignment with scrum values and philosophies.
In many ways, it’s a clash of culture.
Comprehension
- What is the purpose of scrum?
- What is the purpose of Empirical Process Control that underpins scrum?
- What is the purpose of the scrum values?
- What is the purpose of the Agile values?
- What is the purpose of the Agile principles?
- What is the purpose of each scrum artefact?
- What is the purpose of each scrum event?
Do people understand and embody this strong sense of purpose, this deep connection to values and principles within your environment or do they go through the motions of scrum?
Do they embrace learning and use data and evidence to inform their decisions or is it an assumption or opinion developed behind closed doors?
Do they create environments that are psychologically safe, where people can speak truth to power and safely express their concerns, observations, and ideas?
In traditional environments, organizations value obedience, compliance, and diligence. In agile environments, we value collaboration, inspiration, and creativity. People who are committed to a purpose, a vision, and are inspired to deliver their best work in pursuit of that mission and purpose.
If you keep bumping into walls within your environment because of misalignment between agile values and principles with traditional management and project management policies, you don’t have a communication problem, you have a comprehension problem.
An Example of scrum going wrong.
In almost all the agile consulting calls I make, the one scrum event I see where people completely misunderstand the purpose of the event, is the sprint review.
The purpose of the sprint review is to figure out what needs to happen next.
Since the last sprint review:
- The product has changed.
- The business may have changed.
- The customer needs or requirements may have changed.
- The market may have changed.
And so forth.
How do these factors affect the product backlog?
If the product backlog is a transparent list and demonstration of our current understanding of what needs to happen next;
- how does the past two (2) or four (4) week sprint affect that?
- How does the feedback, review, and insight we receive from customers and product stakeholders affect that?
- How does what we have learned, the data, and evidence affect that product backlog?
It is very seldom that I witness product development or scrum teams walking out of a sprint review with an updated product backlog.
If they understood the true purpose of the sprint review, in addition to receiving feedback and reviews from customers about what has been built in the sprint, they would be leveraging that event to inform what their priorities for the next sprint should be.
Most scrum teams simply demo the product, get limited or zero feedback on what has been built or what needs to happen next, and walk out with very little real insight or valuable information.
The difference between a superficial and deep understanding of scrum. One team walks out none the wiser about how to contribute value and increase customer satisfaction, customer acquisition, and customer retention. The other team hits the ball out of the park and is focused on value creation and backlog refinement before they even enter the next sprint.
Productive versus Effective.
This is why scrum isn’t easy to understand, you don’t just get it from browsing through the scrum guide. This is why it’s hard to do, it requires you to focus on every element of the journey and extract the maximum value from each event and artefact. This is why there is such a big difference between what different scrum teams are able to perform, achieve, and deliver.
This is why a cookie cutter approach to deploying and implementing scrum doesn’t work.
Organize around value creation.
Some people think this is frustrating, but for me, this is where the opportunities lie.
This is where competitive advantage lives.
Every company is unique and every team, within that organization, is unique. The customers they serve are unique, and the context within which they operate is unique. So, it isn’t always about price when it comes to pitching or delivering a product.
There is so much more to it than that.
If every company offered the exact same service, the exact same product, and so forth then there would probably be no need for your company. No need for your product. No need for your team.
It would all boil down to price, but it should never be about price, it should be about value.
When you structure the organize around value creation, bring the right people together, create the right team ethos, and grow your team’s capability and effectiveness, you are perfectly positioned to dominate the markets you serve.
You are perfectly positioned to disrupt competitors who have mediocre teams and limited internal capability. You are perfectly positioned to acquire, satisfy, and retain customers over the long-term.
So, is it hard to understand scrum? Yes. Is it hard to master scrum? Yes. Is it worth it? Yes.
About NKD Agility
Naked Agility is an #agile consultancy that specializes in #scrumtraining, #agilecoaching and #agileconsulting to help teams evolve, integrate, and continuously improve.
We recognize the positive impact that a happy AND inspired workforce can have on customer experience, and we actively help organizations to tap into the power of creative, collaborative, and high-performing teams that is unique to #agile and #scrum environments.
If you are interested in #agiletraining, visit https://nkdagility.com/training/
If you have identified the need for #agilecoaching and #agileconsulting, visit https://nkdagility.com/agile-consulting-coaching/
We would love to work with you.
#scrum #agile #scrumteam #agileprojectmanagement #agileproductdevelopment #projectmanagement #productdevelopment #agilecoach #agileconsultant #agiletraining #scrumtraining #scrumorg