Being employed by an organisation that is used to develop products in projects it’s not uncommon to run into some common misconceptions about what Scrum is. This article will deal with some of these misconceptions and address them accordingly.
These misconceptions might seem harmless, but they will lead to Bad Scrum, ultimately resulting in Scrum getting a bad reputation within an organisation.
“We tried Scrum and it didn’t work for us at all”
When you hear someone say this, it is a good indication that Scrum was poorly implemented. Often enough one or more of the following misconceptions are at the root of the problem, why Scrum is broken in your organisation.
“Scrum is for projects”
While it’s undeniably true that you can do projects with Scrum it’s important to realize that the Scrum is centered on the product and not just parts of its life-cycle.
Viewing Scrum as only part of projects also betrays traditional product development dogma, with revolutionary delivery as focus rather than evolutionary, evidence-based optimization of products.
More importantly, projects are temporary organizational structures that get disbanded as soon as the project is done. Maintenance would often be transferred to a different team responsible for keeping things running and fixing problems. This results in a massive amount of wasted time and effort to transfer intricate product knowledge from one team to another, often only partially succeeding.
It makes more sense to have a team responsible for a product, who are expert on that product and are responsible for its health and development throughout its life-cycle.
“The Scrum Master is the (project) manager”
Often a derivative of the prior statement, the traditional project manager role is often projected on the Scrum Master. However, the responsibilities of the traditional Project Manager do no match those of the Scrum Master. A good indicator of this misconception manifesting is when a Scrum Master is asked to produce a plan for the project.
While both roles have a strong focus on the process, a Project Manager is more directive and more focused on the product delivery, whereas the Scrum Master is a facilitating coach that guards the framework in which development takes place.
The major responsibility of planning the development, monitoring progress and reporting results are shared between the Product Owner and the Development Team.
“The Product Owner is the manager of the team”
This misconception stems from the fact that the Product Owner is the authority on the “what” of product development. It’s an easy mistake for a traditional organization to consider him “in charge” of the team, even more so when the original manager of the team takes on the role of Product Owner.
While it is true that the Product Owner does have the mandate to determine the order in which features are being built, he has no hierarchical position or power over the development team. Each has their own role within the Scrum Team. Indeed, it’s important to realise that the Product Owner is part of the Scrum team, not outside of it.
In reality, the Scrum team is manager of the team; from their respective roles, the Product Owner and the Development team are in the lead how to best serve the companies interest within their own defined area.
“Scrum is a toolbox”
Unfortunately I encounter this misconception far too often: “Scrum” implementations, where some of the framework has been altered to better match with the old situation. Examples of this are Part-time scrum, teams with multiple product owners, or teams that are too small because ‘resources’ need to be divided over stakeholders. In essence, it stems from an unwillingness to change the organisation to fit the process.
While Scrum doesn’t specify a lot in terms of rules or behaviour and can be easily enhanced to create a better fit, but the rules of the framework, its events, artefacts and roles are non-negotiable. All of it is essential to make framework function and perform as a whole. Removing some of it is the equivalent of removing the engine or wheels from a car and expecting it to work.
When implementing Scrum a lot is possible within the boundaries of the framework, but the outlines as set by the Scrum guide should be sacred.
Finally, if you think your adaptations will work better for your situation, by all means: go nuts, just don’t call it Scrum. By calling an adaptation Scrum sets false expectations and confuses everyone else.
“There’s no long term plan with Scrum”
If you ever hear anyone saying this you know they’ve been a victim of bad Scrum, or they know someone who is.
Typically this notion that you cannot long term plan with Scrum stems from the fact that everything on the backlog of a Scrum team is potentially subject to change.
While this might be true on a story-level, the strategic goal of the product development is quite stable. What does change the the means how to achieve these goals, based on evidence, user experience, new insights and a changing landscape. Like a colouring picture, the outlines are set, but the materials and colours used to finish the picture are subject to change.
A lack of understanding the product backlog also plays a large part in this notion. Making the product backlog visible is not enough; it should also be understood by everyone. It is part of the transparency, which Scrum aims to achieve.
A good practice that can help visualise product roadmaps is story boarding. This method of organising a backlog allows for a good overall picture of the desired outcome, while allowing the flexibility to adapt to new insights.
To conclude, these are the things you should always remember about Scrum:
- Scrum organises itself around the product and its full lifecycle;
- The Scrum Master is the facilitator of the proces, not its outcome;
- The Scrum Team is a self-driven entity, of which the Product Owner is a fellow member;
- Scrum works as a whole;expect it to break if you remove or alter its components;
- Share your product vision with your stakeholders and them along for the journey.