TL; DR: Hypotheses Validation, Measuring Productivity—Food for Agile Thought #291
Welcome to the 291st edition of the Food for Agile Thought newsletter, shared with 31,152 peers. This week, we delve into hypotheses validation, and we shine a light on why it is often hard to have an authentic conversation and what you can do about it. We also stress the importance of modeling and measuring culture and analyze critical problems at the leadership level of organizations that result in a 70 % failure rate of transformations.
We then wonder why so many product managers want to create strategies while we derive all the signals for further product growth from the operational work in the trenches. We appreciate a new ebook on dealing with difficult stakeholders and critical situations, and we learn a simple approach to measuring team productivity: Don’t touch velocity!
Lastly, we learn that Gitlab identified a new DevOps maturity model.
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.
TL; DR: Design Thinking Scrum—Food for Agile Thought #290
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.
