The top 5 misunderstandings about Scrum and Agile
The Scrum Guide and the Agile Manifesto are only as good as people read it
As a Scrum Master I sometimes run into serious misunderstandings about Scrum and Agile. Though everybody seems to get it that a daily Scrum meeting is useful, not everyone gets the yeast of the Scrum Guide. Sometimes, people claim the opposite of what Scrum is all about. Here is the top 5 of misunderstandings:
- “Scrum means we do not have to spend time on planning”
Wrong! Scrum is built on the experience that solving complex, adaptive problems (like software and product development) is hard to plan. The longer the planning period is, the higher the likelihood of running into unforeseen issues or dependencies. Scrum therefore limits the planning period to a maximum of 4 weeks. Detailed planning beyond this period is indeed a waste of time according to Scrum. Detailed planning within a sprint, on the contrary, is important. Only if the team plans the sprint with Swiss precision, the team can meet the Sprint Goal and maximize the value of the product at the same time.
- “Agile means we should not spend time on writing documentation”
The Agile Manifesto values working software over comprehensive documentation. The Agile Manifesto also states however that there is value in documentation. The point the Manifesto wants to make is that working software is the primary goal, not the documentation. One cannot draw the conclusion from the Manifesto that writing documentation is not agile. On the contrary: not writing documentation at all decreases the value of the software. The software will be hard to change and maintain, which means that the company owning that software will be less agile in the future: writing documentation therefore can be agile.
- “Scrum means that is it OK to deliver a minimum viable product”
The word “Minimum Viable Product” is not even in the Scrum Guide. Scrum pursuits exactly the opposite: Scrum would like a maximum viable product. In Scrum the Product Owner role is to do just that.
Since Scrum is based on the principle of “Inspect and Adapt”, Scrum ascertains that the Product Owner and the Product Developers meet regularly and structurally to give the Product Owner a chance to see what has been developed and the Developers to get feedback on their work. A minimal viable product at the end of the sprint has a greater value for inspection and adaptation then a higher value product that is not ready for inspection.
To prevent the situation at the end of the sprint that the team is still working on a product that cannot be demonstrated, the starting point of reasoning for the sprint planning is: what is the minimum viable product that we can demonstrate at the end of the sprint? Once this has been determined, the next question is: what more can we do to add value to the product, so we maximize the value of the product and the time of the Development team at the same time? So Scrum means that the team should maximize the value of the product and not be satisfied with a minimum viable product.
- “Scrum means that Senior Management should keep their mouth shut as we are a self-organizing team”
Scrum teams are self-organizing, not self-managing. Self-organizing means indeed that no one outside the development team – including senior management - can tell any developer during a sprint how and when he should do his/her work during the sprint. Every other area however, is the domain of Senior Management. Examples are: the strategy of the company, the product development budgets that can be revised and – if needed – have an immediate effect on the next sprint.
- “Agile means that is always OK to do something else then planned as this is what Agile is all about”
If a team member falls ill during a Sprint, it is likely that the team will re-organize the work and do something else then planned to cope with these circumstances. This is an agile way of working and this is OK. However it is not OK if a Scrum team is surprised by a system that has planned downtime if the team could have known this downtime at or before the sprint planning. It should be discussed in the retrospective how this happened and what the team can do to prevent this in future sprints. So Agile does not mean it is always OK to do something else then planned.
These were the top 5 misunderstandings about Scrum and Agile. I hope this article gives you arguments to counter these misunderstandings if you come across them. Scrum really is light weight and simple to understand, but it is hard to master!
Albert Jan Hartman MSc LLM
Albert Jan Hartman is a certified Scrum Master and Agile Coach.
IMHO, this contribution rather qualifies for a blog post rather than an entry here in the forum. Well written!
"The word “Minimum Viable Product” is not even in the Scrum Guide. Scrum pursuits exactly the opposite: Scrum would like a maximum viable product. In Scrum the Product Owner role is to do just that."
Page 6 of the Scrum Guide does actually use a similar, but also distinctly different term: potentially releasable increment. The terminology is important. When you tell someone that something is viable, it implies that it's acceptable as-is, and requires no additional work. Something that is potentially releasable on the other hand implies that there may be additional steps or requisites that can prevent release.
This is the inherent problem when you start to use terms outside of the Scrum Framework in favor of coining new buzzwords. Minimum Viable Product, Iteration Manager, Tag-Up - these all lose some of the important meaning present in the original words (Potentially Releasable Increment, Scrum Master, and Stand-Up, respectively).
A minimal viable product at the end of the sprint has a greater value for inspection and adaptation then a higher value product that is not ready for inspection.
Somehow, while reading this, I'm getting the feeling that there's confusion over the meaning of "viable". Albert, it sounds to me like you're using "viable" as a synonym for "valuable", which it is not.
A minimal viable product is the "smallest" (i.e. minimal) version of the product that could be sold in the marketplace. That is distinctly not the same thing as a potentially-releasable product increment, Jason. If you are starting a new development offer from scratch, your product increment at the end of Sprint 1 might be potentially releasable, but very likely your PO will decide against releasing it. Why? Because it's not viable yet. The product is probably still missing some key features without which customers will not be willing to pay money for it. Those may take a couple more sprints to achieve and voilá - you have a minimum viable product.
Julien, I believe we are using roughly the same definitions, and I agree with you.
Allow me to clarify. I have a concern with companies that try to rebrand Scrum as something new and sexy by changing the terminology instead of adding to the framework. I think that devalues Scrum and makes it more difficult for those certified in agile practices to navigate the ecosystem.
- Scrum: Release an PRI every sprint. Define MVP. Release a MVP after ~3 sprints.
- Not Scrum: Release an PRI every sprint, but refer to it as an MVP.
I would've pressed the "like" button if there was one. So instead I'll confirm that we are agreeing on this ;)