Comic Agilé’s Post

Common occurrence in many B2B product companies where shipping just the “MVP” results in lack of feature adoption by Customers because the friction of adoption is way more than the minimal value of the feature. Aim for lovable increments. Do MVP for controlled quick feedback. But consider an MVP as feature half done. The competition and expectations are high. Minimal is not enough. #productManagement #software #goodAgileVsBad

Comic Agilé no. 1 - The Program Board (reshare - our first ever strip!) Use the overview of your many dependencies as fuel for reducing and, ideally, eliminating them by organizing around Value Streams or products, creating teams capable of "end-to-end" value delivery, and slicing features more vertically. We know; it’s easier said than done, but so is everything else in life. #agile #scaledagileframework #piplanning #comicagile

To remove dependencies you might need organizational changes. If an organizational changes introduce dependencies, maybe it's the wrong change. And yes: it’s easier said than done.

Reality will always prevail, no matter how well you plan. And here’s the thing—dependencies are a silent killer of agility. They make teams fragile and reactive, not adaptive. The magic happens when teams are empowered to deliver value end-to-end without needing constant coordination or waiting on others.” What if, instead of tracking dependencies, we focused on removing them? Organizing teams around value streams, slicing work smaller, and delivering incrementally isn’t easy—but neither are firefighting plans that fall apart two weeks in.

I've been there. The yarn charts are a thing of the past. If your tickets are in Jira, use a tool like Clear Path for Jira that will lay your tickets out in the implementation order, based on the dependencies already in Jira. Using Clear Path will make your PI planning go much quicker. Search for it in the Atlassian Marketplace. Enter the digital world for dependency planning, today.

In this video... To theme #retros or not to theme? Tired of same old? want focus? set the scene? Conflicted by barbie retrospective, the gremblins retro, the goonies retrospective? YOU ARE NOT ALONE we look at what are ACTUALLY themed retros + specific examples with PURPOSE AND detailed recent session Here is how and IF 👉 https://lnkd.in/eXANnhmp Whats YOUR take? #agile #retrospective #inspect #adapt

The importance of introducing WIP limits to teams cannot be overemphasised!!! It is common to have dev team and PO insisting on moving so many items into the sprint. A couple of questions to help drive the conversation 1. What kind of conversations do you have during planning? 2. How do you commit to tons of items? 3. Was there a refinement or did the PO dictate all the items that must be in the sprint backlog? 4. Historical and data speaking, how many items does the team deliver every sprint? Team velocity?? Dear Scrum Masters, guide your teams to understand the value derived from WIP limits

I have seen large companies loose hundreds of millions this way. (Dollars or Swedish crowns, depending on the project) In particular, every SAFe project I have ever worked in has utterly failed to limit WIP. Usually, teams do limit WIP in the Sprint backlog, and sometimes in the development process. However, they completely miss that WIP limits must be placed on all product backlogs! Thus, an incredible amount of WIP builds up _between_ the teams. Most of the time, no one understands what happens. A predictable consequence of not teaching queueing theory in Agile anymore. Queueing theory was a hot topic up until around 2010-2011, but now seems almost forgotten.

Every time. Every place. Everywhere. (It's a wonderful world we can share!) I've almost never seen this NOT happen! YES this is about limiting work in progress as a team discipline, but here are some other things I look out for - - Are your definitions of done and acceptance criteria tightly worded and does the team have a shared understanding of them? If they don't then this can lead to "completion anxiety" and scope creep. - Are your stories and tasks sufficiently refined and detailed at the point you start work on them? Sometimes they get stuck waiting for requirement detail. If the product owner can't answer a query immediately this indicates that maybe the requirement isn't ready. - Is there real psychological safety across the team? Perhaps some members are reluctant to seek help when they need it to finish something. - Are there external dependencies that everyone is waiting for? Is it possible to review, split and refine the stories and tasks to focus on what the team can do independently of whatever external factors are causing delays?

Comic Agilé no. 125 - Uncommitted PI Objectives (reshare) If your teams need a way of communicating their intended goals in a PI without committing to delivering them—i.e., using Uncommitted PI Objectives—let's not just not have them entirely. Though they are a way of communicating to stakeholders that the team has some big risks or uncertainties when working on delivering a specific Feature or Enabler, not committing to them at all will hopefully enable everyone to have an open and honest talk about confidence in deliveries. No team should be pressured into committing to deliver something that they are not confident in. And if they are, they would make it a PI Objective, won't they? #agile #scaledagileframework #PIObjectives #comicagile