Words can be funny; more specifically, how the same word can have incredibly different meanings for different people. Take the word scrum for example. For 95% of the population, that word either elicits thoughts of people in jerseys all huddled together about to restart a game, or holds no meaning at all. However, when you change the ‘s’ to a capital, to us, the word Scrum takes on a whole new meaning.
Scrum is on the mind of many engineers, managers, and especially software developers; however, with any widely spread practice, it is usually only a matter of time before misconceptions, misinformation, and myths begin to infiltrate. What’s worse, is that for many, we don’t even realize it is happening.
To separate fact from fiction and in hopes of empowering us all to practice Scrum in its purest form, I have taken the liberty of compiling five of the biggest Scrum myths that many of you may be familiar with but might not know them to be false.
Myth: Scrum Master Leads the Daily Scrum
One of the biggest myths that I have come across happens at the Daily Scrum; and if you have been around as long as I have and attended as many Daily Scrums as myself, you’ve likely seen it too.
Let me know if any or all of these sound familiar:
- You attend a Daily Scrum, and the entire team is giving their updates to the Scrum Master
- The Scrum Master gives his or her input and suggestions, trying to micromanage the efforts of the team
- The main focus of the Daily Scrum is on the Scrum Master
- The meeting lasts for more than 15 minutes
If you answered yes to any of the above, then first off, allow us to tell you that what you witnessed is NOT a Scrum Master leading a Daily Scrum; at least, not how it should be.
The goal of the Scrum Master is not to lead the team, nor do they have any such authority. In fact, the presence of the Scrum Master isn’t even mandatory for the meeting. According to the Scrum Guide, the daily scrum is entirely owned by the Development Team; however, the Scrum Master is responsible that the meeting takes place. This includes sending calendar invitations, choosing the time that works best for everyone, instituting soft penalties for being late, and ensuring all impediments are noted so that they can be resolved later. Remember, the goal of the Daily Scrum is merely a chance for the team to all get on the same page and agree upon a strategy for the following 24 hours. Ideally; within 15 minutes, all the work from the previous day is discussed and analyzed while the work to follow is plotted.
Myth: The Scrum Master Must Resolve Every Problem
Difficulties, problems, issues, complications, hurdles, setbacks, and snags are just par for the course when you are in the midst of development. Actually, that’s just life, but I’ll leave that conversation for another day.
The Scrum Guide, which should be considered holy text for development teams practicing Scrum methodologies, clearly outlines all the various duties that a Scrum Master is expected to fulfil. And one of those is to remove impediments to the Development Team’s progress. I know what your thinking, “Doesn’t that statement seem to validate the myth?” I agree, it looks that way, but the key thing to remember here is the word “impediment,” which many developers assume to be any and all problems that come there way during a sprint.
An impediment, when taken in a Scrum context, should be considered problems that are interfering with a Development Team’s progress that lie OUTSIDE of their capability to resolve. This notion is closely related to one of the most fundamental concepts of Scrum: self-organization.
Development is an often precarious, usually unpredictable, and almost definitely a complex undertaking; however, the use of a teams expertise to collectively solve problems is crucial. Some examples of issues that may arise that deserve the attention of a Scrum Master includes:
- Team member falls ill
- Hardware issues
- Absent Product Owner
- Bugs and glitches in the production environment
- Problems with the development environment
- Internal conflict between team members
Remember, the capacity of a Scrum Master is to solve problems that the Development Team cannot. So if you’re unhappy with your lunch order, you missed your train into the office, or your significant other is giving you a hard time, it is best to save those problems for someone else.
Myth: Velocity Equals Value
The short answer; no. However, as that wouldn’t make for good reading, I feel I should elaborate. But first, let us make sure that we all have a clear understanding of what is meant by Velocity and Value.
According to Scrum.org glossary (because where else would you go for all things Scrum), Velocity is defined as “an optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.” As such, velocity can be an incredibly useful metric for predicting the volume of items that can be delivered in a Sprint, or comparatively, how many Sprints will be required to reach release.
Value, on the other hand, as defined by the Oxford Dictionary is “the regard that something is held to deserve; the importance, worth, or usefulness of something.” Now, when most people think of value, their minds normally turn to money, so for the sake of this point, let us use it as a proxy and a valuable product as being able to increase revenue or decrease cost. In the context of Scrum, value is only created when the product or increment reaches the customer; they find it useful, and they start benefiting from it.
Now that we have two clear definitions of velocity and value it should be clear that they are very different things and one is not indicative of the other. One (velocity) is a tool that a Scrum Team can utilize to self-manage during the development process, and the other (value) is simply a means of the customer assessing the usefulness of the product.
Myth: Sprint Review is a Demo
Development is by no means the easiest of work, which is why the opportunity to showcase and demo your increments to Stakeholders can be so rewarding. However is the Sprint Review really the time to do it?
Do any of these sound familiar:
- You gather for the Sprint Review, and the Stakeholders are on one side and the Development team on the other; not unlike a middle school dance
- There is very little input from Stakeholders (often because they weren’t invited to)
- The mouse and keyboard never actually make it into the hand of a Stakeholder
- None of the Stakeholders present are actually going to use the product
- The Sprint Review gets referred to as a ‘Demo’
If you answer yes to any of the above, then there is a good chance your definition of a Sprint Review may is bit askew. But rather than tell you why all of the above is wrong, let us draw a comparison to how a Sprint Review should look:
- Development team and Stakeholders should appear indistinguishable to an outsider
- The Product Backlog holds a distinguished spot and is continuously adjusted as new insights are uncovered
- Participants are invited to offer up their ideas, feedback, and suggestions actively
- The Increment is presented not just by the Development Team, but by the entire Scrum Team – including Product Owner
- The Product Owner assesses the Product Backlog and discusses progress and expected completion dates
If you think the latter sounds more productive than the former, you’d be right – and the Scrum Guide would agree with you. For it emphasizes that Scrum Team and Stakeholders must collaborate about what was accomplished in the sprint and based on any changes in the Product Backlog, discuss next best actions to optimize value.
Myth: In Scrum, There is no Planning
For some Scrum Teams, the word “Plan” or “Planning” is considered taboo. Certain Scrum Masters may refuse to let their team look past the current Sprint. And from the outside, many seem to believe that Scrum Teams are aimlessly working away trying to create products without a sense of direction or overarching aim. However, despite popular opinion from the outside and some misguided souls within, planning is, in fact, a crucial part to Scrum – and there is no better way to prove it than by the numbers.
The Guide mentions the word ‘Planning’ a whopping 19 times! And the word ‘Plan’ a still impressive 9. And in case you were wondering, use of those words at no point are preceded by the words “You shall not.”
So what are some examples of planning in Scrum?
- During Sprint Planning (see the word ‘Planning’) Scrum Teams work together to plan (see, again) what will be performed during the Sprint. This plan is then captured in an albeit flexible Sprint Backlog that is aligned with an overarching Sprint Goal in order to provide direction and focus
- The Daily Scrum is about planning what the Development Team will do for the next 24 hours
- During the Sprint Review, the Sprint Team and Stakeholders inspect the work completed and based off of it, plan what can be done next to optimize value
The above are just a couple of examples of planning that are imperative to the success of any Scrum endeavour. And while flexibility in approach is undoubtedly of great appeal and one of the most valuable aspects, it should never be thought that Team efforts are lacking specific intent.
While earlier I made the distinction between scrum and Scrum, in reality, they have a lot in common. Both involve groups of people in what often looks like an unorganized mess; however, they are all ultimately working towards a shared goal, passing the ‘ball’ backwards and forwards while the team marches ahead. And although it is unlikely that the Scrum we are all familiar with will result in us wearing matching jerseys, it is always important to understand that you are a part of a team and to succeed and win at the game; you need to understand the rules.
