Worrying Interpretations of Scrum

Tuesday, March 22, 2016

Over 80% of all Agile teams worldwide indicate they have adopted Scrum. The mission of Scrum.org is to improve the profession of software development. We are humbled by the improvement Scrum has brought to the industry. We find motivation in continuing the path of maturing the understanding of Scrum around the world.

Scrum is outgrowing its teenage years - in fact, having turned 21 last year, it could buy beer in the States. Yet, like that newly-minted adult trying to pick out his first six-pack, there is still confusion over some of the tenets of Scrum.

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. And a key tenet of our work with Scrum.org is to ensure this.

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 visualized 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.

I find motivation in my ambition to help people use Scrum more effectively. I emphasize the proper use of terminology, not for formal reasons but as an expression of the purpose of the rules.

If you have questions on the topic or want to contact me, you can email me.

If you would like to learn more about Scrum, find Scrum training or take a Professional Scrum certification assessment you can visit Scrum.org.

Read more: http://guntherverheyen.com

This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.