TL; DR: Rebels Spark Ideas, CSPO Pathology—Food for Agile Thought #296
Welcome to the 296th edition of the Food for Agile Thought newsletter, shared with 31,704 peers. This week, we acknowledge that rebels spark ideas, and we consider whether OKRs can restore purpose to agile teams and free them from the tyranny of the Product Backlog. Moreover, we get an inside view of how Youtube managed its early hyper-growth, and we point at the advantages of using low-code tooling to build software: Iterating faster.
We then address why the tech industry has such a high proportion of weak product managers and product leaders. We pitch the advantages of collaborative decision-making, leveraging both stakeholders’ and developers’ expertise while creating a shared understanding. Also, we share three tactics that have proven to impact getting buy-in from team members significantly.
Lastly, we enjoy an interview with Christina Wodtke on how OKR can help product managers accomplish more, and we get curious about a new Scrum software: “HappyStack is a Scrum project software tool for developers: Backlog, Sprint Planning, Standups, Reviews, and Retros done the right way.”
TL; DR: When Scrum Masters Fail — Making Your Scrum Work #13
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. Scrum thrives when the Scrum teams are self-managing while Scrum Masters embrace their role as servant-leaders. However, this also implies that Scrum Masters fail when they are overly protective.
📺 Join me and explore the consequences of the overly protective Scrum Master and what you can do about it in less than three minutes.
Update: I am running a poll on LinkedIn—join the voting: “How can Scrum Masters fail their team by being overly protective or supportive?”
TL; DR: Essential Agile Failure Patterns — When Noise Interferes with Signal
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. When Scrum becomes an element of an agile transformation, the following three common essential agile failure patterns prove to be an exceptionally tough nut to crack for any Scrum Master.
📺 Join me and explore the consequences of foreseeable failure patterns and what you can do about them in a little more than seven minutes.
Update: I am running a poll on LinkedIn—join the voting: “What is your top agile failure pattern in organizations?”
TL; DR: Overcoming Team Limits, The Mediocrity Trap—Food for Agile Thought #295
Welcome to the 295th edition of the Food for Agile Thought newsletter, shared with 31,527 peers. This week, we delve into overcoming team limits with Jeff Sutherland, the co-creator of Scrum. We also dive into an adjacent topic: Team-building in organizations that double the employee count at least yearly, and we analyze some psychological issues that might interfere with the core of agility.
We then share ten compelling reasons why to stay out of meh work. Moreover, we reflect on the necessity of loving your customer’s problem, not your solution, and we embrace a comprehensive primer on how innovators can use the JTBD framework to create successful products.
Lastly, we appreciate a new academic paper on the effectiveness of Scrum teams.
TL; DR: The Oversized Product Backlog Problem — When Noise Interferes with Signal
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. Neglecting the critical Scrum artifact for continuous value creation is one of the common Scrum anti-patterns. If your Scrum Team strives to make your customers’ lives easier Sprint after Sprint, beware of the oversized Product Backlog.
📺 Join me and explore the consequences of inadequate Product Backlog management in less than three minutes.
Update: I am running a poll on LinkedIn—join the voting: “What reasons have you observed why Scrum Teams stuff their Product Backlogs — a very costly pattern that diminishes ROI and value creation?”
TL; DR: Spotify Model Fallacy, Pirates & Leadership—Food for Agile Thought #294
Welcome to the 294th edition of the Food for Agile Thought newsletter, shared with 31,412 peers. This week, we dissect the Spotify model fallacy. (By the way, Spotify is no longer using product squads.) We also point at the forward-thinking approach of pirates regarding governance and self-management and why some people have difficulties embracing the idea of autonomous action by self-directed individuals.
We then learn the two only ways of pushing back requests to build features to close deals. Moreover, we list core principles that come with experimentation and what it takes to drive the change; finally, we analyze the popular leadership fallacy to mandate creating ‘innovative feature,’ probably, with a timeline, incentivized by OKRs.
Lastly, we delve into the origins of feature creep, adding on top of the usual suspects—such as gold-plating—the difficulties that distributed teams face. (See also Gold-Plating Beyond Done — Making Your Scrum Work #7.)