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. However, creating Product Increments that “over-deliver” in scope or quality — also known as gold-plating — with regard to the previous refinement agreement demonstrates that the Developers need to acquire a more entrepreneurial mindset and embrace their responsibility.
Join me and explore the reasons and the consequences of this Sprint anti-pattern in 109 seconds.
Contrary to popular belief, the Scrum Master success principles are tangible, when we guide the analysis with an outside perspective.
Read on and discover four Scrum Master success principles: From when not to use Scrum to product quality to supporting the Product Owner to putting self-management at the center.
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 Retrospective into a Blame Game Retrospective demonstrates a Scrum team’s lack of skills and professionalism.
Join me and explore the reasons and the consequences of this Sprint Retrospective anti-pattern in 83 seconds.
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.
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.
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
