The Scrum Guide 2020 is available now: Change is coming to make Scrum more accessible and inclusive beyond software development. Learn more about the changes, download the brand new and free Scrum Guide 2020 Reordered to spot patterns quickly, and join the Scrum community discussion.
Last year, I ran a (non-representative) survey on how Scrum Masters are allocating their time when working with a single Scrum Team. Much to the surprise of many readers, the direct Scrum Master engagement with a single Scrum Team of average size and a typical 2-week Sprint turned out to be about 12 hours per week.
This result immediately prompted two additional questions: What is a Scrum Master doing during the rest of the week, and in what way does a Scrum Master’s work manifest itself over time? While answering the above question requires additional research and data collection, the latter can be answered to a certain grade by focusing on a few common scenarios.
The first article of this series will address the Scrum Master engagement with the Development Team.
‘Autonomy without accountability equals anarchy’ summarizes an essential design element of any agile organization. Without these checks and balances in place any aspiration to transform an organization is likely to fail. (Or at best level out at a mechanistic level.) Learn more about how Scrum deals with accountability.
Popularized by Elon Musk, utilizing first principles thinking to solve problems in an innovative, creative, and less biased way has proven popular in the tech community. Given that its sibling empiricism is an integral part of Scrum as a framework, applying Scrum first principles thinking is also a useful exercise.
Learn more about how to Elon Musk the Scrum Guide.
The Scrum Guide Reordered Download is based on about 95 percent of the text of the Scrum Guide 2020, extending its original structure by adding additional categories, for example, on self-management, commitments, or accountability.
The Scrum Guide 2020 Reordered allows you to get a first understanding of Scrum-related questions quickly. For example, it is good at relating specific topics—say “stakeholder”—with Scrum first principles such as Scrum Values, or empiricism.
If technical debt is the plague of our industry, why isn’t the Scrum Guide addressing the question of who is responsibly dealing with it? To make things worse, if the Product Owner’s responsibility is to maximize the value customers derive from the Development Team’s work, and the Development Team’s responsibility is to deliver a product Increment (at least) at the end of the sprint adhering to the definition of “Done,” aren’t those two responsibilities possibly causing a conflict of interest?
This post analyzes the situation by going back to first principles, as laid out in the Scrum Guide to answer a simple question: Who is responsible for keeping technical debt at bay in a Scrum Team?
