There are plenty of Product Owner failures. Given that Scrum is a framework with a precise and concise yet short “manual,” this effect should not surprise anyone.
Explore with me three widespread examples of how Product Owners fail their team in three short video clips, totaling 6 minutes and 9 seconds.
Welcome to the 290th edition of the Food for Agile Thought newsletter, shared with 31,083 peers. This week, we delve into Design Thinking Scrum, and we note that most frameworks pay a lot of attention to decision making, less, though, to understanding decisions. We also share the agile leadership practice library, and we point at the12th principle of the Agile Manifesto: A self-managing team also needs to be a self-learning team.
We then point at the advantages of product teams over project teams, and we learn when and how to get involved with Lean, Agile, and Design Thinking regarding your product lifecycle. Moreover, we enjoy describing a hiring process based on auditioning, not interviewing, the best candidates.
Lastly, we appreciate ThoughtWork’s latest version of its tech radar, and we ask: Who Disrupts the Disrupters?
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. Turning the Sprint Review into a Sprint acceptance gate where stakeholders sign off features is unfortunately prominent and defies the idea of self-management.
Join me and explore the reasons and the consequences of this Sprint Review anti-pattern in 80 seconds.
In their book Agile Retrospectives, Esther Derby and Diana Larsen popularized the idea that a Sprint Retrospect comprises five stages. The second stage refers to gathering data so that the Scrum Team can have data-informed Retrospectives.
As I have observed in practice, many Scrum Teams either limit the data gathering part of the Retrospective, thus lacking vital information. Or they invest too much time doing so, leaving little capacity to analyze the data and come to conclusions on how to best improve as a team.
Read on and learn how you can avoid falling victim to both scenarios by gathering data continuously and asynchronously.
Welcome to the 289th edition of the Food for Agile Thought newsletter, shared with 31,016 peers. This week, we delve into FAST Agile to fill the gap for a purely complex agile method. We examine the Boeing 737 Max crashes through the lens of industry and corporate culture, and we point at OKRs’ dark side—their dual-use nature and the inherent prospective misuse potential in the hands of traditional performance management protagonists.
We then share the open-source template of the ‘Product Management Competency Framework;’ we explore the topic of design justice, and we enjoy a teacher’s story of breaking into product management without a CS degree.
Lastly, we point at the pre-requisits of shifting from a traditional management style to genuinely remote leadership, from remote-first to avoiding the rookie mistake of applying controlling tools.
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. A Sprint Review without stakeholders may create an unhealthy bubble for the Scrum Team due to the disconnect, thus resulting in lower effectiveness.
Join me and explore the reasons and the consequences of stakeholders avoiding participating in the Sprint Review in less than 150 seconds.
