Dealing with Inconsistencies regarding Scrum
Hi Everyone,
In my pursuit of understanding scrum well, I've come across instances and materials where there are inconsistencies in how scrum is referenced.
For example, the scrum guide says that scrum is a framework but then, as I was reading the material in the PMI-ACP Exam Prep, there is a line that says "The Scrum Master is responsible for ensuring that the scrum methodology is understood...."
Similarly, scrum has only 4 meetings (backlog refinement is not a formal meeting as per the guide) i.e. Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective, however, this book states "The Scrum methodology defines five "activities"......These include product backlog refinement, sprint planning meetings, daily scrums, sprint reviews and sprint retrospectives."
My point here is that, people keep referencing scrum as a methodology instead of a framework. This further becomes a problem when other interpretations like in the second example above are introduced by others and are then circulated or preached/coached/trained to others.
Based on my knowledge of the scrum guide, if I had to answer a question for a test based on what is written in this book, I could easily get questions wrong; take this simple question for example Scrum is a _______. 1. Framework, 2. Methodology
Is there a way to deal with these inconsistencies or am I thinking this too much?
Steve, always refer back to the Scrum Guide It is written by the creators of Scrum and is the official rules of Scrum.
I echo Eric's sentiment. In addition, PMI promotes methodologies and "Agile" project management, which have nothing to do with Scrum.
@Eric, Timothy, Thanks for the support and re-assurance. My concern and disappointment however is that many such falsehoods are being taught and exist in the workplace. When it comes to exercising one's knowledge, there are the so called coaches who defend such things and there is no way we can correct them in order to ensure that the knowledge and understanding is consistent for everyone.
For example, When I coach my team to be self organizing and manage the daily scrum on their own, enterprise coaches say "It is the scrum master who should lead the scrum call, always!"
@Steve, it sounds like your "enterprise coaches" are project management coaches and not agile coaches. As @Timothy pointed out there is a concept of Agile Project Management. Many people think that because the word "Agile" is in it then it is really agile. But that is one of the problems with using the word agile. Everyone wants to interpret it differently. Many of the original signatories for the Agile Manifesto for Software Development have stated that those misconceptions of their purpose has actually caused degrees of failure in what they intended.
Scrum Guide defines what Scrum is. Books you read, PMI Agile certifications, even "Agile Coaches" may not agree with the guide. But as it says
Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
If you really understand, believe in, and appreciate Scrum as defined in the guide, maybe you as a Scrum Master should spend some time with your Enterprise Coaches helping them to understand the difference in Scrum as you understand and Agile Project Management as they are coaching. It may be that your organization wants Agile Project Management and not Scrum.
Steve,
There are many out there who attempt to practice an imperfect version of Scrum or Agile. In those instances (like your example where enterprise coaches believe SMs should always lead the Scrum call), the Scrum Guide is your friend!
When you encounter behavior that seems counter to your understanding of Scrum, use the Scrum Guide as a reference, and point to it when you question others about their understanding of Scrum.
Your enterprise coaches are not completely wrong, but rigidity and process are really not compatible with Scrum and Agile. According to the Scrum Guide:
The Scrum Master... facilitates Scrum events as requested or needed.
That said, the Scrum Guide says the following about the Daily Scrum:
The structure of the meeting is set by the Development Team... The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.
Your enterprise coaches are not completely wrong
@Timothy Baffa, How are they not wrong?
Thanks Daniel Wilhite for clarifying the difference. I didnt know that Agile Project management would cause people to have their own interpretations. I believed following the true practices of scrum or kanban were the foundations of agile project management.
Many of the original signatories for the Agile Manifesto for Software Development have stated that those misconceptions of their purpose has actually caused degrees of failure in what they intended.
Do you have a reference to an article where the above was mentioned? I'd like to read this in detail.
@Steve, I stated that your Agile Transformation coaches were not completely wrong, since the Scrum Guide does state that the SM facilitates as needed. Perhaps they are working from an imperfect interpretation of Scrum?
The key question is to ask the Development Team if your facilitation of their Daily Scrum is of benefit to them. It seems you're already asking these questions since you reference your ongoing coaching of them.
Maybe you also need to invest some time in coaching your coaches?
@Steve, I have numerous places where this has been stated. There are interviews, blogs and more that you can find. I just did this google "agile manifesto signatories agile failed" and it listed quite a few. Some of them are not the original signatories but many of them mention it. The first in the list (https://techbeacon.com/app-dev-testing/agile-manifesto-dead-not-long-sh…) has this paragraph.
In, Agile is Dead (Long Live Agility), Dave Thomas, one of the Agile Manifesto's signatories, says "The word 'agile' has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products."
There are other places and you can find them better if you google the signatories name with the word agile.