Leadership
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.
Software Delivery Problems
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.
Unintended System Condition (USC)
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,