Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
Image
A while ago I wrote that the Project Manager didn't die under Scrum. The role was taken apart on purpose, its responsibilities distributed across the Scrum Team, and some of them absorbed into the framework itself.Then Daniel Pokrývka read it on LinkedIn and asked the one question that should make you pause:Who is responsible for the deliver of what was promised or paid by the customer?It's a fair challenge. Maybe the fairest one you can throw at the whole idea. Because if everything got distributed, the natural fear is that accountability got diluted, that we spread it so thin nobody actually holds it anymore. Someone signs a contract. Money changes hands. A promise is made. So who, exactly, is on the hook when that promise comes due?Let me try to answer it honestly.First, the part Scrum doesn't talk aboutHere's the thing most people miss when they ask this question. Scrum, as a framework, only describes what happens inside the team. The Product Owner, the Developers, the Scrum Master, and how the three of them turn ideas into a working product. It says nothing about managing contracts, budgets, or proposition managementBut that team doesn't float in space. It sits inside an organisation. And it's the organisation that makes the commercial promise: we'll deliver this, for this money, by roughly this time.That promise is a wrapper. It lives in the organisation, around the team, not inside Scrum. So part of the honest answer to "who's accountable to the customer?" is simply: whoever signed the deal. Scrum doesn't define that role, and it doesn't pretend to. There is, deliberately, no single throat to choke.Which sounds like a dodge. It isn't. Because the interesting question is what happens to that wrapper once the work begins, and that's where a properly functioning Scrum Team gives you a much better answer than a name on a contract.Follow the moneyLet me take a position, because I think it clarifies everything. Budget management should fall under the accountability of the Product Owner.Not metaphorically. Actually. A real Product Owner isn't just ordering the Product Backlog. They're making investment decisions. Is this PBI worth the money it will cost to build and who do I need to include to verify this assumption of value. That is what "maximising value" actually means when you take it seriously. It's not a slogan. It's someone standing at the intersection of cost and value and deciding where the money goes.So when the customer asks "who's accountable for what we paid for?", the cleanest answer is: the Product Owner. They own the value and the purse. The commercial wrapper doesn't need a separate account manager standing off to the side. A genuinely empowered PO is the organisation's answer to the customer.If.The uncomfortable "if"Here's where I have to be honest, because this only holds when the Product Owner is genuinely empowered, and in most organisations, they simply aren't.Look at how the role tends to evolve. You can walk it up a "ladder":Scribe: writes down what others decide.Proxy: relays messages between the business and the team.Business representative: speaks for the business in the room.Sponsor / budget holder: actually controls the money.Entrepreneur: owns the product like it's their own venture.Now the painful part. Most Product Owners never climb past business representative. They can explain what the business wants. They cannot say yes or no to the money. They speak for value without ever owning it.And that changes the answer to the LinkedIn question completely. Below the budget-holder rung, delivery accountability leaks, right back out into the organisation, to a sponsor, a delivery lead, an account manager. Not because Scrum failed, but because the Product Owner was never allowed to be a Product Owner.So the honest answer to "who's accountable to the customer?" is uncomfortable: it depends where your PO sits on that ladder. And most sit too low. If you want a clean answer, don't rewrite the framework. Empower the role.But delivery was never one person's jobEven a fully empowered Product Owner doesn't carry delivery alone. This is the part I don't want to lose, because it's what keeps this from becoming a Product Owner puff piece.Delivery isn't a handoff. It's a weave of three accountabilities.The Product Owner maximises value. That's not "build everything we promised." It's making sure what we build is the most valuable thing we could have built with that money. Concretely, that looks like:Shipping the thin slice that unlocks revenue now instead of the gold-plated version three months later.Cutting a PBI the customer explicitly asked for, because the data says almost no one will use it, and spending that budget somewhere that moves the needle.Sequencing the work so the riskiest, most valuable assumption gets validated first, while there's still time and money to react.That is delivery. It's just delivery measured in value, not in volume.The Developers realise it. They own whether the Increment actually meets the Definition of Done: the real, working thing, not a status update about it. But here's the deeper point, and it's the one that matters most.There is a world of difference between Developers who are told to build something and Developers who feel they own the product.The first produces compliance. The second produces ownership. When people genuinely own their work, quality stops being something you have to demand. It becomes something they refuse to release without. Pride does the job that supervision never could. That sense of ownership is what turns a task-taker into a professional, and it's a huge part of why the same work delivered by two different teams can feel like two entirely different products.And the Scrum Master? Conspicuously, still not delivering anything. That remains the point. The Scrum Master doesn't build the product and doesn't own the budget. They cultivate the environment where that ownership and professionalism can actually grow, and make it transparent whenever something is quietly eroding it. They develop the people and the system that deliver, so that the pride, the craftsmanship, and the understanding of why we work this way don't get flattened by pressure and deadlines.The better question, againSo who's accountable for delivering what the customer paid for?If you were hoping for a single name, I can't give you one, and I'd be suspicious of anyone who could. The truthful answer is a shape, not a person:Value sits with the Product Owner, when they're empowered enough to hold it. Realisation and owning quality sit with the Developers. And the health of the whole system that makes real delivery possible sits with the Scrum Master.The customer contract still exists, wrapped around all of that by the organisation. But a mature Scrum Team doesn't leave that promise dangling in a document. It answers it, every Sprint, with a working Increment.So the next time someone asks who's accountable to the customer, don't reach for a job title. Ask the better question instead:Is our Product Owner actually allowed to own the value, and do our Developers actually feel they own the product?Answer those two honestly, and you'll know exactly how strong your delivery accountability really is. Not because Scrum handed it to one person, but because you finally stopped expecting it to.Hope this helps?
Image
Kiwii is a Singapore-based training company that brings world-class Agile and Scrum training to the vibrant business community of Singapore. As an official Scrum.org Training Partner, Kiwii is among the few globally licensed to offer the full suite of Scrum.org certified courses. Our trainers turn learning into an experience through interactive sessions with posters, games, and practical tools. Kiwii’s mission is to spark curiosity, energize minds, and grow juicy ideas that help people lead, collaborate, and deliver value together.
The potential is in YOU. We're here simply to help you unlock it. Check out our Scrum.org courses in Singapore here.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | The Project Manager Isn't Dead. It Was Disassembled on Purpose! | 0 | 16.43 | 27-07-2026 |
| 2 | 5 Questions Scrum Teams Ask All the Time | 0 | 12.38 | 04-08-2026 |
| 3 | “Scrum didn’t work for us.” | 0 | 8.1 | 30-07-2026 |
| 4 | No Manager in Scrum? | 0 | 13.2 | 20-07-2026 |
| 5 | Cognitive Trap: Scrum Master as a Manager | 0 | 7.34 | 10-08-2026 |
| 6 | Survey Results: Agile to the Product Operating Model | 0 | 8.21 | 10-08-2026 |
| 7 | Scrum Isn't for Stormtroopers | 0 | 15.26 | 28-07-2026 |
| 8 | Die Ergebnisse der „Agile zum Product Operating Model“ Umfrage 🇩🇪 | 0 | 6.96 | 13-08-2026 |
| 9 | AI Tools Evaluation & Approval Framework for Scrum Teams | 0 | 10.27 | 10-08-2026 |
| 10 | 🇩🇪 Konflikte surfen statt lösen | 0 | 18.59 | 30-07-2026 |