At an Agile event I attended recently the speaker surveyed the audience about the 9 elements that form Scrum. My suspicion was immediately raised with mentioning of “9”. It only got worse when the speaker came up with:
It got me wondering how many misconceptions of Scrum can be expressed in no more than two minutes:
I was hoping that by now (2016), and certainly given the availability of the Scrum Guide (since 2010), the basic understanding of Scrum was better.
What worries me the most however is not the formality of the wrong and missing elements, but how this reflects an ineffective use of the Scrum framework, a limitation to how Scrum supports teams in creating great software products:
- Accountability over the self-organized creation of Increments belongs to the Development Team as a whole. Synergy is key, not individualism.
- Transparency is optimized when Product Backlog holds all types of work and requirements for the product. The format and syntax of Product Backlog items is open for the teams to decide over. User Stories are certainly not mandatory.
- Burn-down charts were removed as mandatory from Scrum some years ago. It was replaced by the expectation that progress, regardless the format, is visualised on Product Backlog and Sprint Backlog.
- If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a releasable Increment in a Sprint. It is the basis of empiricism, of business agility. Imagine my surprise that this was not even mentioned, THE core purpose of Scrum.
- Scrum has no prescription that the Daily Scrum needs to happen standing up. Scrum’s interest is making sure that the team’s progress toward the Sprint Goal is inspected on a daily base, in order to allow the team to adapt.
- The Sprint Review is a collaborative event at which the Scrum Team and the stakeholders work together, and identify what is most important to work on next. Adding input from the stakeholders to the inspected, current state of the software (via the Increment), improves that decision. It is so much richer than a demo.
- All events in Scrum are contained within a Sprint. Sprints take no more than 30 days, and often less. Not mentioning the Sprint as such (container) event might allow to overlook that aspect.
[…] чтобы попытаться исправить повторяющиеся и тревожные интерпретации Scrum которые там. Иногда это весело. Часто это не так. Это […]
[…] (原文: Worrying interpretations of Scrum) […]
[…] AKA Worrying interpretations of Scrum, pt.2 – This week I had the pleasure to facilitate two days of learning. One day was all about working towards the Scrum.org PSMI certification with a Dash of Scrum (master) practice. The other was more about Scrum & Agile basics. […]
Reblogged this on Technology Unplugged. and commented:
Misconceptions about Scrum. Why don’t you read and understand the Scrum guide?
[…] Worrying interpretations of Scrum […]
[…] Worrying interpretations of Scrum […]
Hi Gunther,
Even if the 11 elements of Scrum are satisfied, I believe there need to be organizational wide Scrum implementation strategy. I found often the lack of Transparency as defined in Scrum Guide 2013 is major obstacle towards effective Scrum implementation. Implementing Scrum under the radar with no consensus from the main groups (e.g. PMO, Product/Business Team, IT, Infrastructure, Operations, …..) will only lead to local optimization at best and usually to superficial. Ignoring to address the organizational structure that is not suitable for Scrum implementation can be a key inhibitor.
Although these 11 elements are foundation but without optimizing the overall system, we will get only distorted and probably non-sense Scrum rituals.
Thanks,
Sameh
Hi Sameh, you are right. Here are similar considerations that I jotted down on stealth Scrum. That was 5 years ago, imagine. G.