The third Liberating Structures Scrum meetup addressed the Sprint Planning, more precisely the reasons why Sprint Plannings fail—despite all the efforts put into them in advance, from the Product Backlog refinement to the Sprint Review.
Join us for an exciting Liberating Structures Scrum workshop on July 6th, 2019 in Berlin. We will be exploring several microstructures, weave them into strings and apply those to Scrum events like the Daily Scrum, the Sprint Review, or the Sprint Retrospective. The workshop language will be English.
The Liberating Structures 4 Scrum workshop will take place at the Alte Kantine Wedding on Saturday, July 6th, 2019, from 9 am to 5 pm.
Liberating Structures Sprint Retrospective: A few weeks ago, I started an event series with my Berlin-based Hands-on Agile Meetup group on how to improve Scrum events utilizing Liberating Structures — a set of easy to learn, yet powerful ways to collaborate as a team. The results have been fantastic so far, and I like to share these outcomes with those who cannot participate in person.
In this first post, learn more on how you can use Liberating Structures strings to improve the level of collaboration and engagement at Sprint Retrospectives.
The tenth Hands-on Agile webinar Sprint Retrospective anti-patterns covers twelve anti-patterns of the sprint retrospective—from #NoRetro to the dispensable buffer to UNSMART action items to a missing product owner.
Agile failure seems to be increasingly more prominent nowadays despite all the efforts undertaken by numerous organization embarking on their journeys to become agile.
The funny thing is: Who would disagree that the four core principles of the Agile Manifesto —
— are derived from applying common sense to a challenging problem? Moreover, the application of those principles might be suited to fix numerous organizational dysfunctions and reduce an error-prone and complex social setting to maybe just a complicated one?
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?
