Myth: Scrum is an engineering philosophy.
Scrum is a framework for developing, delivering, and sustaining complex products.
That’s all it is. It doesn’t have to be software. It doesn’t tell you to do TDD or how to set up your dev environment or what is the role of manual testing or QA. It doesn’t tell you whether to favor composition or inheritance, nor does it discuss functional vs object-oriented. It is a framework of roles, ceremonies, values, and artifacts within which complex products can be created.
As for how the work is accomplished, not only does Scrum not tell the team how to do the work, it explicitly states that no one has the power to tell the team how to do the work, either. In particular:
No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.
In Scrum, no one tells the Development Team how to do their job, least of all Scrum itself.
Myth: Scrum is just a set of processes
Scrum is not just a set of processes; it’s also a set of values. In particular, the Scrum Guide recognizes five values: Focus, Openness, Respect, Commitment, and Courage. Many of the highest performing Scrum teams don’t necessarily observe all of the ceremonies of Scrum, because they’ve grown to discover new ways of realizing the Scrum values without needing formal reminders to do so.
However, it is dangerous to think that abandoning the Scrum ceremonies is necessary, sufficient, or causative in the formation of a high-performing team. The key is to learn to embody the Scrum values. The Scrum framework of ceremonies and artifacts and roles simply provides formal opportunities and reminders to embody various values in particular ways. Only once this system is mastered can a team be truly ready to embark beyond it.
Myth: Scrum And Agile Are The Same Thing
Scrum is simply one of myriad ways that an Agile philosophy can be realized in an organization. It is not the only one. That said, it is the most popular one and probably the most prescriptive one.
Take another philosophy, say, Kanban. Kanban tells you to reduce your WIP. It tells you to make sure that completed work and WIP are both highly visible. Many Kanban practitioners find value in the famous Kanban Board as a way of realizing these objectives, but Kanban itself does not prescribe the board. It simply tells you the values and the things to strive for and lets you figure out how.
Scrum, however, is different. It doesn’t tell you, say, to reflect and improve; it tells you to have a meeting on a regular basis timeboxed to 45 minutes per week of the Sprint, and that this meeting is explicitly for the purpose of reflecting and improving. You might say that, while other philosophies tell you what medicine to take, Scrum tells you what to take, where the pharmacy is, how to get there, and how and when to take it.
This difference contains both great value and great danger. The value comes from being given a more specific starting point. Many engineers, when instructed to complete a non-technical objective like “reflect and improve”, will start by asking How. How am I supposed to achieve this? What practices should I engage in? Prescriptive philosophies like Scrum answer these questions thoroughly. Of course, Scrum itself doesn’t tell you how exactly to manage your Retrospective, only that you should have one and what its purpose is. How to do it is a question that a single guide like Scrum cannot answer, because it should be flexible depending on the needs of the particular team and the particular Sprint. This, however, is a different rabbit hole that I’ll discuss a different time.
The danger, however, is in missing the forest for the trees. If you get so focused on the Scrum processes that you don’t understand the Scrum values, or the particular value that each Scrum ceremony and artifact is engineered to produce, then you are likely to fall into the all-too-common pattern of calling yourself Agile while realizing none of the Agile or Scrum values.
The first time I was introduced to Scrum was at work several years ago. We had our Sprint Planning meeting, and we had our Daily Stand-up, and we had our Sprint Review, and we had our Sprint Retrospective. No one knew why we were having them; we just knew we were supposed to. The team, therefore, grew to resent the meetings and have hard feelings against Scrum, because no value came from them. This is what happens when you focus on the processes at the exclusion of the value those processes are supposed to bring.
Myth: Scrum, Kanban, and XP are a disjoint cover of agile methodologies
From The History of the Manifesto:
Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.
You can get certifications for Professional Scrum with Kanban. Kanban also mixes with XP. XP practitioners are known to claim that “Scrum is just XP without the engineering practices that make it work.” Clearly, Scrum, Kanban, and XP are neither disjoint nor do they cover all the ways to do Agile, as if such a thing could ever be exhaustively covered.
Myth: Scrum is a framework which you adapt to suit your organization.
I hear the following complaint, in various wordings, all the time from Scrum coaches.
This organization decided to tailor Scrum for their needs instead of adopting it as written. So they didn’t adopt several parts of it. Pretty soon, they’re dropping more parts of it, and eventually they’re just having stand-ups for the sake of having a progress report. Meanwhile, they’re complaining about how Scrum doesn’t work.
It’s true. Scrum doesn’t work if you cut out essential pieces (spoiler alert: if it’s in the Scrum Guide, it’s essential). You wouldn’t expect to clone a functioning tiger by starting with a strand of tiger DNA and then throwing half of it away. So why do people expect to be able to throw away half of Scrum and still get the full value of Scrum out the other end?
There is another, more important point here, though. Scrum does not fix your problems for you; it merely points them out and empowers you to fix them. In other words, do you remember this thing?
This is a scene from Star Wars. That watery stuff that Luke Skywalker is floating in is called “bacta”. It’s made of fairy dust and liquid unobtanium, and it just heals whatever might be ailing you. Pretty awesome.
But things like that don’t exist in the real world, not even for our software processes. Scrum is not bacta; it’s a doctor. It doesn’t automatically fix everything you wanted fixed; it simply points out things that are wrong (which are probably root causes of the symptoms that made you seek out Scrum in the first place) and gives you a prescription for fixing them.
If you look at implementing Scrum and your thoughts can be summarized as “Yeah, certain parts of it sound great, but this one part in particular I just think can’t work for us because of X, Y, and Z”, then the chances are that this is Scrum telling you that something is wrong with your organization, and it can be found at X, Y, and Z. Focus on the thing that is difficult, and fix it. The painful parts of implementing Scrum are the parts of your org that need to be changed, not the parts of Scrum that need to be changed or abandoned. The more painful it is to implement, the more important it is to implement it correctly.
Myth: The Scrum Master just makes sure everyone comes to stand-up.
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
The Scrum Master is responsible for teaching the team to fish, so to speak. This comes in the forms of coaching everyone on Scrum processes and values and especially by removing impediments of the Development Team.
The Scrum Master is not responsible for making sure that daily stand-ups happen. (Scrum itself doesn’t even use the term “stand-up”; they call it “the Daily Scrum”) The Scrum Master is responsible, however, for coaching the Development Team into being self-organizing enough to perform them on their own.
The Scrum Master is not responsible for managing the burndown chart. (the Scrum Guide does not even prescribe a burndown chart) The Scrum Master is responsible, however, for coaching the Development Team into being self-organizing enough to track their progress on their own.
From a developer’s perspective, the nice thing about Scrum is also the worst thing about Scrum: it gives the power to the people who do. As a result, developers have the freedom to manage themselves and self-organize. This can be extremely powerful and creative. However, it also means that the developers have the responsibility to manage themselves and to self-organize. This means that the team itself is responsible for “management” tasks such as updating the burndown and ensuring progress toward the agreed-upon Sprint Goal.
Summary
There are many myths out there surrounding Agile, and I have only covered twelve in this two-part series of posts, but hopefully they’ve given you a better idea of what Agile and Scrum are really about. For further information about Scrum, feel free to check out the Scrum Guide or post a comment here. If I can answer the question, I will! Until then, happy developing.
The Developing Coder 