UnSMART Improvements at Retrospectives — Making Your Scrum Work #18

TL; DR: Unsmart Improvements

There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. One area that typically flies under the radar is improvements. While the Scrum Guide encourages addressing the most impactful ones as soon as possible, it is up to the Scrum team to figure out how to improve. One manifestation of this core team task we often encounter is picking unsmart improvements, though.

Join me and delve into the consequences of picking unsmart improvements as a Scrum Team in less than 90 seconds.

Unsmart Improvements — Making Your Scrum Work #18 — Age-of-Product.com
Continue reading UnSMART Improvements at Retrospectives — Making Your Scrum Work #18

Abandoning Scrum: Can a Scrum Team Decide to Quit Scrum?

TL; DR: Abandoning Scrum

Can a Scrum team simply decide to abandon Scrum? After all, the Scrum team is self-managing, according to the Scrum manual, also known as the Scrum Guide. So, let’s explore this question at the very heart of team autonomy.

Abandoning Scrum: Can a Scrum Team Decide to Quit Scrum? Age-of-Product.com
Continue reading Abandoning Scrum: Can a Scrum Team Decide to Quit Scrum?

When the Management Ignores Self-Management — Making Your Scrum Work #16

TL; DR: Ignoring Self-Management — Undermining Scrum from the Start

There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. One of Scrum’s first principles is self-management. It is based on the idea that the people closest to a problem are best suited to find a solution. Therefore, the task of the management is not to tell people what to do when and how. Instead, its job is to provide the guardrails, the constraints within which a Scrum team identifies the best possible solution. Join me and explore the consequences of management ignoring self-management and what you can do about it.

Ignoring Self-Management — Making Your Scrum Work #16 — Age-of-Product.com
Continue reading When the Management Ignores Self-Management — Making Your Scrum Work #16

Three Common Developer Blunders in 5:05 Minutes—Making Your Scrum Work #14

TL; DR: Common Developer Blunders — When Your Scrum Team Lacks Alignment

There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. While it is common to first look outside our team for impediments, such as dysfunctional processes or other systemic issues, I would advise starting with the Scrum team’s way of collaboration: Are we aligned on the why, what, and how? Otherwise, the three following Developer blunders may diminish the team effectiveness.

📺 Join me and explore the consequences of these Scrum Developer blunders and what you can do about them in a little more than five minutes.

Three Common Developer Blunders in 5:05 Minutes—Making Your Scrum Work #14 — Age-of-Product.com

Update: I am running a poll on LinkedIn—join the voting: “What common ways have you observed how Developers diminish the value creation of their own work?”

Continue reading Three Common Developer Blunders in 5:05 Minutes—Making Your Scrum Work #14

18 Signs of a Systemic Toxic Team Culture

TL; DR: 18 Signs of a Systemic Toxic Team Culture

What looked like a good idea back in the 1990ies—outsourcing software development as a non-essential business area—has meanwhile massively backfired for a lot of legacy organizations. While they try to become more appealing to product and software developers, they still have difficulties understanding what it takes to build an attractive product/engineering culture. Learn more about typical anti-patterns and signs that an organization is causing a toxic team culture, impeding its efforts to become agile.

18 Signs of a Systemic Toxic Team Culture — Age-of-Product.com
Continue reading 18 Signs of a Systemic Toxic Team Culture

Technical Debt & Scrum: Who Is Responsible?

TL; DR: Technical Debt & Scrum

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?

Technical Debt & Scrum: Who Is Responsible?
Continue reading Technical Debt & Scrum: Who Is Responsible?