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.
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.
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.
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?”
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.
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?
Team building has always been a challenge, not just since the advent of agile frameworks and the resulting emphasis on self-organization, engagement, and achieving a valuable objective. This post covers four team building mental models — or concepts — that have proven useful in understanding the context of creating agile teams: from Taylorism to Tuckman to Lencioni to Dan Pink.
