TL; DR: Success Metrics, Maker-User-Gap—Food for Agile Thought #293
Welcome to the 293rd edition of the Food for Agile Thought newsletter, shared with 31,307 peers. This week, we delve into why picking success metrics is so challenging yet critical, and Henrik Kniberg shares some vital insights after years of working with Spotify, LEGO, and Minecraft development. Also, we point at how sociotechnical architecture and systems thinking are key to enabling product thinking in organizations.
We then share an eight-step strategy workshop; we understand why ‘going deep’ is Stripe’s core product principle, and we wonder why some product managers hold on to timeline-based planning while product roadmaps have evolved so rapidly in recent years.
Lastly, we analyze the idea of ‘autonomy’ in the workplace, particularly regarding two challenges: the air sandwich and politics.
TL; DR: The Developers Code Fallacy — They Should Talk to Customers, Too, Though
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. The Developers Code Fallacy starts with the idea that Developers are rare and expensive and should focus on creating code. Business analysts or customer care agents can talk to customers instead. However, in practice, it has a diminishing effect on a Scrum team’s productivity and creativity. It is a sign for an organization still profoundly stuck in industrial paradigm thinking.
Join me and explore the reasons and the consequences of this Scrum anti-pattern in 110 seconds.
There are plenty of Scrum stakeholder failures. Given that Scrum is a framework with a precise and concise yet short “manual,” this effect should not surprise anyone. While the Scrum Guide makes numerous references to stakeholders in Scrum, stakeholders themselves are no official role (accountability), no matter their crucial contribution to a Scrum team’s overall success.
Explore with me three widespread examples of how stakeholders fail their Scrum teams in three short video clips, totaling 6 minutes and 5 seconds.
TL; DR: Bottom of Agile, Velocity Forecasting Spreadsheet—Food for Agile Thought #292
Welcome to the 292nd edition of the Food for Agile Thought newsletter, shared with 31,223 peers. This week, we get to the Bottom of Agile; we point at the benefits of journaling regarding modern leadership competencies, and we delve into the advantages and psychology of slack time. Additionally, we appreciate Troy Magennis’ updated ‘Throughput or Velocity Forecasting Spreadsheet’ for easy Monte Carlo forecasting of agile work.
We then address five PO anti-patterns what you can do about them; we introduce the three-step ‘Not Impossible, Just Too Expensive’ approach to problem-solving, and we point at the danger of merely copying what other companies do without understanding the why behind them.
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.
