Scrum is NOT simple
The 2020 Scrum Guide says, “Scrum is simple”, but it is not!
Scrum, at its core, is heralded for its simplicity. The Scrum Guide states a powerful assertion: "Scrum is simple." Yet, a paradox emerges if we pause and reflect on the global landscape of Scrum implementation. This simplicity is often shrouded in misinterpretation and challenges, leading to the questions: If Scrum is so simple, why is it so commonly misunderstood and misapplied? Why do so many people struggle with Scrum? Why are people turning away from Scrum?
Reflecting on my career, I can confidently say “Scrum is not simple”. It does not mean I don’t think Scrum works; quite the opposite, it is what is needed in organisations. But the reality is so many organisations cannot even get the basics right and fail. Also, becoming a Professional Scrum Trainer about two years to four of intensive learning to master Scrum at different levels. It's not simple; because everyone would be a PST if it were.
The essence of Scrum's simplicity is not about the ease of understanding its framework on a superficial level. Rather, it's about the profound simplicity achieved through deep mastery. This journey to simplicity is anything but straightforward. It encompasses a phased learning process, beginning with the Agile values and principles, moving through empirical process control, and navigating through the intricacies of the Scrum framework, self-managing teams, engineering practices, and beyond.
The journey to simplicity is anything but simple. It encompasses a long and hard learning process, beginning with the Agile values and principles, moving through empirical process control, and navigating through the intricacies of the Scrum framework, self-managing teams, engineering practices, and beyond. For many, this is not a linear progression either, as challenges are unique to different organisations.
Agile Values and Principles: Mastery begins by internalising the core Agile goal, values, and principles and seeing agile as values and principles that guide our decisions.
Empiricism: The journey continues with mastering empiricism—understanding that knowledge comes from experience and making decisions based on what is known and learned. It is mastering the transparency, inspection, and adaptation.
The Scrum Framework: Achieving proficiency in the Scrum framework involves a nuanced understanding of its accountabilities, events, artifacts, and commitments. Mastery here means moving beyond mere knowledge of these components to skillfully apply them to create value.
Self-Managing Teams: The evolution towards mastery involves empowering teams to self-manage and embrace the scrum values. This includes cross-functional teams and self-organisation. It is establishing the right behaviours and psychological safety.
Engineering Practices and Quality: Mastering Scrum includes a commitment to technical excellence and the engineering practices that ensure high-quality products. This aspect of the journey emphasises the Definition of Done and the continuous improvement of practices that allow teams to create the right quality products.
Adjacent Processes: Scrum Teams are not islands and work with other teams, departments and other product teams. Mastering scaling and cross-team collaboration becomes key when Scrum gets used more throughout the organisation. This leads to learning to apply Scrum in different types of teams that are not software.
Organisational Processes: The culmination of mastery involves embedding Scrum within the organisation as a core framework, thus facilitating true agility. It influences how the organisation funds, hires, runs processes, governs, and takes its products to market. It will likely affect the organisational strategy.
As one progresses through these phases of mastery, the initial complexity of Scrum begins to unravel, revealing the simplicity on the other side of mastery. The pyramid flips as there is a realisation that everything revolves around empiricism, and agile values and principles. One does not realise that until you have travelled the road and mastered the pains.
This journey is akin to learning to ride a bicycle—challenging at first but eventually becoming second nature where you don’t even think about it.
However, to overlook the arduous path to this simplicity is to oversimplify the Scrum journey. It can be seen as dismissive of the genuine struggles faced by those in the trenches, learning and applying Scrum principles. The assertion that "Scrum is simple" can indeed feel condescending to those amidst the throes of mastering its nuances. It's crucial to acknowledge that simplicity in Scrum is the result of mastery, not a starting point.
Understanding and respecting the complexity behind Scrum is essential. This perspective fosters a more inclusive and empathetic community, encouraging learners and practitioners alike to embrace the journey with perseverance and openness. It is through this journey that the true simplicity and beauty of Scrum can be appreciated, not as a trivial endeavour but as a profound achievement born out of dedication and hard work.
It’s time to reframe Scrum's simplicity to “Scrum eventually becomes simple”. it’s not a marker of effortlessness but a testament to the mastery achieved through overcoming complexity. As we guide others through their Scrum journey, let's do so with empathy and support, recognising the dedication required to uncover the simplicity on the other side of complexity.
I am getting much feedback where people debate about simplicity versus ease. They say it is still simple, but it is not easy. Whilst I respect and appreciate their comments, I disagree as I see it as WHAT versus HOW.
If it were simple versus easy, people would understand the problem and understand WHAT they need to do, but they may struggle to do HOW to do it. Thus simplicity is WHAT and ease is HOW.
Empirically looking in the market there is more a widespread misunderstanding is on WHAT to do, and that is because it is NOT simple. On top of that, the HOW is also hard. If it were truly simple, people will understand the WHAT and the reasoning behind the WHAT.
PS. On a tangent, I also believe the way the Scrum Guide is written is part of the problem. Ken and Jeff have obscured the WHAT to the point it is not simple.