It doesn’t take long to introduce someone to Scrum methodology. Let’s form a team of specialists with different skillsets, typically under 10 people. They will break down all the work into smaller, manageable chunks and deliver them incrementally in iterations called Sprints. After each Sprint the Team will inspect the work and adapt their plan and process to deliver the most value.
Sounds simple, right? That’s why 20 years after the famous Agile Software Development Manifesto was first published, Scrum is the number one framework for software teams around the world.
However easy it is to begin using Scrum, doing it right requires practice, experience and mistakes to learn from. Here I describe some of the most common myths and misconceptions around Scrum so you can spot and avoid them.
1. Agile and Scrum are just for software projects
Not true! Although the Agile movement originates from software development, nothing stops us from applying it elsewhere. It is even encouraged by Scrum creators to use it in other domains – wherever there’s complex work to be done. There have been successful Agile implementations in domains like sales, HR and marketing. And even car manufacturing – Tesla considers agile product development a key factor for their market success.
What is the key to Scrum methodology adoption outside software? I believe it is looking beyond the technical IT-related jargon and understanding the 3 empirical pillars of Scrum. The first one is transparency, second one is inspection and the last one is adaptation. With those in mind, we can look at numerous complex processes and think of ways to make them more agile.
We can increase transparency to make more informed decisions – based on facts rather than assumptions.
We use a periodic inspection to make sure our goals are still valid. As well as to discover problems early, when they are still cheap to fix.
Those two go hand in hand together – as Scrum Guide says, “Transparency enables inspection. Inspection without transparency is misleading and wasteful”.
And finally, we can adapt our work plan every time we learn something new that impacts our goal.
Key takeaways:
- Scrum originates from the software industry but its applications are not limited to it
- Scrum creators actively encourage using Scrum for non-software projects and products
- More and more organizations start to apply Scrum each year – and the trend will be continue
- Modern leaders look at underlying principles of Scrum to make traditionally managed processes more efficient
2. The Daily Scrum is about reporting status
This one is quite common. The team meets at the agreed time and place, and everyone shares their status reports from the previous day. Maybe it’s something like “I was working on this new authentication API; I will probably continue today”. Each team member says their part and everyone goes back to their desks.
This can work but is far from perfect. So how can we improve it? Focus on the Sprint Goal and collaboration. Don’t fear discussing things, ask for clarifications if you don’t understand. When observing the best performing teams, I noticed that their Daily Scrum flows like a conversation between athletes on the same team. Focused on establishing a winning strategy (to meet the Sprint Goal) rather than mechanically answering questions.
Different point of view
There’s another angle to this problem – and it is more focused on workplace relationship dynamics. Scrum describes the Daily Scrum as an event for Developers of the Scrum Team. In practice though, other people often attend those meetings too – as listeners or active participants. This can profit the team but also cripple the benefits of Daily Scrum.
If Product Owners, Scrum Masters, Managers and even stakeholders attend Daily Scrum events on a daily basis, team members may feel intimidated and insecure to speak up about the problems they experience. Fear of judgement and looking incompetent is very real and more common that we think. That’s why Daily Scrum need to be a safe space for discussions. Scrum Masters, look at team dynamics to spot problems like this!
On the other hand, Product Owner and stakeholders often fear losing control over the project. They feel they NEED to be in every meeting to make sure everything goes according to plan and be able to react immediately. In that case, the Developers should focus on establishing trust. They ought to show that they actually understand the business context. And can be relied upon to achieve planned Sprint Goals without constant looks over their shoulders.
Key takeaways:
- The team should collaborate during Daily Scrum – discussions are welcome
- Daily Scrum shouldn’t be about reporting status to managers
- Scrum Master and Product Owner are not even required to attend
- Scrum Masters: cultivate a safe, non-judgmental environment
- Make sure your online project management tracking tool is updated daily so that managers and stakeholders know the current status
3. The team must deliver everything planned for the Sprint
You might have experienced this. We plan to complete 7 User Stories in this sprint so delivering anything less is a failure. 100 percent completion and meeting the plan is our goal, right? Well, no.
The aim for the sprint should be meeting the Sprint Goal, rather than just completing all backlog items. As we know more about the problem we wish to solve, the scope of the sprint may be adapted. To make sure the Sprint Goal is fulfilled. After all – it’s often impossible to predict all the complexity for a given task.
As Scrum promotes self-organization, the Developers should have the authority and autonomy. Autonomy to choose the best way for the Product Goal to be achieved. If after interviewing the end users we learn that current plans make no business sense, the sprint scope can and should be modified. Just remember to be transparent about it and be able to support your decisions with facts. In case you are confronted by your stakeholders!
Focusing on Sprint Goal also means that some lower priority items in Sprint backlog might not be completed. And that’s ok if they don’t impact the Goal. Scrum is about delivering value, not just crossing all items off a to-do list.
Key takeaways:
- Sprint Goal is the most important
- Sprint scope is more like a forecast rather than a hard commitment written in blood
- The Developers should have enough autonomy to choose the best way to achieve Sprint Goal
- Sprint scope may change and that’s ok if Sprint Goal is met
4. Product backlog consists of user stories
For sure, user stories have become popular with agile teams. They capture a real scenario from the user’s perspective and encourage discussion to work out the best way to achieve the planned objective. However, some teams may feel that everything that sits in Product Backlog must be described this way. Let’s clarify this!
Firstly, user stories are not a part of Scrum methodology, but just another tool in your toolbox to capture the requirements in a certain way. If something doesn’t fit this format, use a more appropriate technique. Other than obvious types of backlog items like bugs, some items might be purely technical – sometimes a certain module just needs to be refactored. Or an implementation must be adjusted to meet new legal requirements for the product. In cases like these, it makes no sense to struggle and come up with a user story – a well described set of expectations will be enough. Remember to create backlog items that are manageable and possible to estimate.
Remember that the Product Backlog is a living artifact – not a “one-and-done” document. It’s fine if the most important items at the top of it are described in detail, while lower priority ones are just more general “epics”. As the team progresses and learns more about the business context, product backlog items evolve into specific user stories and tasks.
Key takeaways:
- User stories are not required by Scrum methodology
- When creating backlog items, think about the most effective way to capture requirements
- Backlog items shouldn’t be too big
- Product backlog is an ever-evolving document that lives throughout the product lifecycle
5. Scrum methodology is just for the implementation phase
In some organizations, there is a pattern of trying to fit scrum into an existing predictive process. Let’s see what it looks like. Typically, there’s a big planning and analysis phase upfront. Detailed designs and long requirement documents are produced while various stakeholders and committees might be spending weeks or months in lengthy email conversations. When certain things are finally agreed on, the appropriate Manager or Director forms a Scrum Team and developers are handed an overwhelming load of documents.
At first glance, the team is on a clear path to success. The massive analysis and design phase was carried out to cover every possible corner case and narrow down those tricky technical specs. In reality though, a couple of sprints into the project it often turns out that 50-70% of those detailed specification documents are not relevant anymore.
This phenomenon is sometimes called Water-Scrum-Fall and is basically a partial Scrum implementation. In an optimistic scenario, the organization can utilize new knowledge from the Scrum Team to adapt the product (sometimes this means changing its direction entirely!). In a more pessimistic one, the company stays fixed on initial assumptions – and burns money to create things nobody actually uses.
If you’re a Developer or a Scrum Master working in organizations where Water-Scrum-Fall occurs, changes need to be applied not at team-level, but at organization level. Moreover it is important for Scrum Masters to look outside their project-focused context and find ways to transform the entire organization to be more agile.
„Don’t let working software be a by-product of technical specifications. Embrace the adaptive nature of Scrum and practice smarter ways to craft product requirements like Product Discovery or Design Sprint.”
Key takeaways:
- Don’t use Scrum as a cool-sounding block between Design Phase and Deployment Phase
- Knowledge about a problem is gained faster while actually working on it
- Ask yourself: What is the minimal set of requirements to get started?
- In the analysis, focus on user goals and needs, rather than a detailed execution plan
- Be prepared for a change of initial assumptions
6. Scrum Master role is not really important
The Scrum Master’s responsibilities aren’t so obvious to grasp when teams start using Scrum methodology, or a new team is formed. Some people feel that this person just moderates meetings and asks questions like “what went well this sprint?”, while others are doing “real work”. Where’s the real value? – they ask.
Those doubts are sometimes justified. Some of us just had bad experiences with Scrum Masters. Maybe Scrum Masters we worked with were not really fit for that role? Maybe the Scrum Master we had in last job was just a re-branded Team Manager with a controlling attitude? There can be multiple examples of Scrum Master anti-patterns. However, don’t let bad examples form your opinion on the role as a whole.
There is one common thing I noticed while working with good Scrum Masters. They all strived to create an environment where team members could perform at their best. This can mean many things. It can be identifying and removing obstacles that limit the pace of the team. Other times it might be working with stakeholders to develop trust and understanding of the process. And sometimes it can even be coaching individual team members or acting as a mediator when a conflict arises. A skilled Scrum Master knows how to spot potential problems and acts proactively!
Key takeaways:
- Scrum Master is a real leader accountable for team effectiveness
- A Good Scrum Master can supercharge team productivity by optimizing processes and work environment
- Smart organizations utilize Scrum Masters to improve things on a company-wide level
Closing Thoughts
Those are only a couple of examples how Agile and Scrum methodology might be poorly understood. If you noticed that some of those cases fit the picture of your team or organization, don’t panic! The first step for fixing any problem is awareness – try to educate others and share good practices rather than just handing in your termination notice. Taking up a challenge to change things for better might be an incredible career opportunity to grow.
If you’re an executive and are want to steer your organization using an agile approach, consider our services to hire skilled agile professionals as consultants for your next venture. We are proud to work with industry leaders like OneSpan, Gentherm, Capula to help them drive multi-million projects to successful completion.
Contact us to learn how you can benefit from working together. We are more than willing to share our success stories with you
Read more about Scrum Guide Update 2020 and 5 TOP changes.