Scrum no doubt has become the popular framework for software product development. Scrum for software development was modelled after "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka published in the Harvard Business Review in 1986. They beleived that the cross-functional teams engaging in the dynamic conflict of ideas that generates "ba," the energy flow that surfaces knowledge that forms new products.
Dr. Jeff Sutherland is one of the inventors of the Scrum software development process. Together with Ken Schwaber, he created Scrum as a formal process at OOPSLA'95. The Scrum Guide was published first in 2010 by Jeff and Ken and further editions of the guide clarified many of the practices and guidelines. In due course of time, people tried to take advantage on the popularity of the scrum framework and have created their own versions. This has led to lots of confusions in the minds of many professionals across industries.
Common Myths about Scrum
Some common myths about Scrum are,
Let’s explore the some of the myths in detail below,
Scrum and Agile are same
Scrum is one of the most popular frameworks and more than 80% of the projects use scrum due to its simplicity and proven results. While Scrum is one of the widely adopted agile methodologies to develop software products, people often think that Scrum and Agile are same. While Agile is a bigger umbrella under which there are multiple methodologies like Scrum, XP, DSDM etc. for software development, Scrum is one of those frameworks.
So Scrum and agile are not synonymous.
Requirements should be written only in the form of User Stories
User stories are powerful constructs expressed from end user perspective for identifying requirements for a software product. The user stories have to be independent and modular so it can be developed and released (potentially) without much dependencies by the development team. User stories are part of eXtreme Programming practice and were adopted in Scrum when people tried to combine Scrum and XP together to realize greater benefits. There is no mandate by Scrum Guide that requirements should be written only in user stories. As long as the requirements are well understood by all the stakeholders, it can be written in any form.
So requirements need not be written in the form of user stories in Scrum.
Only User Stories should be part of Product Backlog
Another common misconception is, only User Stories should be a part of Product Backlog. Product Backlog is nothing but list of anything and everything in order to deliver the product vision. The product backlog could contain defects, nonfunctional requirements like performance improvement features, code refactoring, infrastructure setup etc. There would be often prioritization challenges with the business stakeholders between functional requirements versus rest due to various reasons. It is also the responsibility of the development team to appraise the product owner on the importance of non-functional features which could lead to greater stability of product before adding more features.
So items other than user stories / functional requirements can also be present in the product backlog.
Scrum Masters should have technical knowledge
Now-a-days, it has become imperative that Scrum Master should also have technical knowledge due to the infusion of technology and tools to a great extent in the project. There are lot of job postings which lists the need for Technical Scrum Masters. Scrum Masters are servant leaders and enables the development team to become self-sufficient. Knowing the technical details would actually make scrum master suggest solutions, adopt certain methodology based on his/her prior experience and start managing technical tasks of the team members which beats the very definition of the scrum master. Rather scrum master is a team coach, a facilitator, an impediment remover. Scrum master should be a process expert rather than a technical expert and aid the team in continuous improvement and innovation.
So Scrum master need not have technical knowledge.
Scrum Master in addition can play Product Owner role
Organizations sometimes make a single person play a role of both Scrum Master and Product Owner. This could potentially lead to lots of confusions with the team as the roles and responsibilities are different between both the roles. It’s actually giving too much power to one person which could potentially derail the entire project. The person will not also have enough bandwidth to focus on the priorities as well as facilitate the team. It also requires the scrum master to acquire the domain skills of the product owner which may or may not be his/her forte. The dual role will dilute the responsibilities (both) and the person will not be able to provide justice to either of the roles.
So, a single person can never play a dual role of Scrum Master & Product Owner
Scrum Master is fully responsible for facilitating Scrum Events
Organizations and projects have begun to believe to an extent that Scrum Master (alias Project Manager) is responsible for facilitating and owning scrum ceremonies. Certainly, Scrum Master can facilitate some of the ceremonies initially to break the ice and bring the team together for cohesiveness but it is ultimately the development team’s responsibility for facilitating all of the ceremonies themselves. Scrum master can help in removing the impediments on the way to make development team effectively run these ceremonies on their own. Scrum Master can coach the team on best practices, provide performance feedback (outsider view), resolve conflicts that arise during these meetings and shield the team from external interferences.
So Scrum Master need not facilitate always the Scrum Events, it is the responsibility of the development team
We’ve seen some of the common myths about Scrum but there are other myths as well about Scrum like burn down charts are part of Scrum, planning poker is part of Scrum etc. While people really hold on to these myths to a larger degree, but failing to understand some of the core principles of Scrum which is inspect and adapt. It is important to understand what practices are mandatory and what are optional for any organization that uses Scrum for product development.
Based on your experience in projects, what do you think are other myths that are followed in Scrum based project/product development?