Every RACI chart makes a bet nobody states out loud: that responsibility and accountability travel together because a single person stands behind both letters. Assign someone as Responsible and they do the work. Assign someone as Accountable and they own what the work produces, explain it when asked, and adjust
I have watched this happen enough times now to stop calling it a surprise. A delivery organization adopts AI tooling, coding velocity climbs, dashboards light up green, and three months later the release calendar looks exactly the way it did before the tooling arrived. Leadership is confused. The team is
Program and delivery leaders can define a constraint when asked, but rarely recognize one in the room. Four real-world examples of constraints hiding behind familiar labels, and how to sort them once named.
AI is absorbing the planning, testing, and coordination work that used to define delivery leadership. What it cannot absorb is the judgment to explain why a delivery system produces the outcomes it does. That capability, not speed, is where the next promotion is actually going.
Most leaders can recite the principles. Few ever stop to investigate which ones actually apply to the initiative in front of them, or admit how much reality is forcing them to compromise on the ones that do.
AI can read a code repository the way a radiologist reads film: the structure is right there, waiting to be exposed. A delivery system offers no such courtesy. Its causes live in judgment, not in text, and diagnosing it takes a different instrument entirely.
Most leaders are trained to decide faster and more confidently. What actually improves decision quality is something different: the ability to understand how and why your system is behaving the way it is, before choosing what to change.
"Most organizations are not action-constrained. They are diagnosis-constrained. The leaders who change outcomes are the ones who can explain why."
Agile's manifesto values were not timeless truths. They were a corrective written for a specific failure mode. Agentic development has a different failure mode. Here is what that means for how we lead delivery.
Most delivery improvement efforts collapse because leaders treat measurement and diagnosis as the same activity. The Entrowise five-dimension model is organized around failure, not outcomes, and that choice is what makes a real diagnosis possible.
Agile ceremonies and artifacts were a structural answer to one of the oldest problems in software delivery: how do we stop losing intent as it travels between minds? When the receiver is an AI agent, that same problem resurfaces with no social fabric to absorb it.
Requirement writing evolved from BRDs to User Stories to SDD to IDD. Each solved the handoff. None governed what happens between handoffs.
Unintended System Condition (USC)
Scrum solved something genuinely hard. Inside a sprint, a team's capacity is understood, commitments are visible, and WIP is bounded. For a single team working on well-defined work, this is a real achievement. Most large software organizations have this working reasonably well at the team level. Go
Career
What experienced Scrum Masters, Agile coaches, and program managers find on the other side of framework mastery There comes a point in most Agile coaching careers where something quietly shifts. You have the certifications. You know the ceremonies better than most people in the room. You can facilitate a retrospective
PPA Method
Most delivery leaders I know are good at describing what is going wrong. Missed deadlines. Unstable releases. Teams that feel perpetually overloaded. Forecasts that never hold. What is much harder — and I have seen this across dozens of organizations — is explaining why it keeps happening. Not the surface reason. The
Leadership
You've solved this problem before. You're certain of it. Different quarter, same conversation, same tension, same outcome. Somehow it's back. If you're a good manager, and most people reading this are, your instinct is to work the problem harder. More process, more
Software Delivery Problems
Nobody builds a bad plan on purpose. The scope document looked thorough. The requirements were signed off by the right people. The milestones had owners. The launch date was in the calendar. Six months ago, in the room where all of this was agreed, it felt like the responsible thing
Software Delivery Problems
Here is a conversation that happens in most technology organizations at least once a quarter. A senior stakeholder walks into a planning meeting with a new initiative. It is urgent. There is a real business reason behind it. The ask is reasonable: "Can we fit this in?" The
Software Delivery Problems
After working with dozens of software delivery organizations, I believe almost every delivery problem falls into one of three categories. Most leaders know two of them well. The third is where careers get stuck. The first is the Technical Problem. Something is wrong with how the solution is designed, built,
constraints-track
Why software delivery keeps failing for reasons everyone can see but nobody names I have sat in hundreds of delivery reviews over the past two decades. Retrospectives, quarterly planning sessions, post-mortems, leadership offsites. The problems on the whiteboard change. The faces around the table change. The tools, the frameworks,