Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
Image
Two companies start an agile transformation in the same quarter. Same training provider, same skilled coaches, same framework, comparable budgets, equally sincere executives. Three years later one of them ships weekly, kills bad bets early, and holds onto its best people. The other has agile ceremonies, an agile maturity dashboard, and delivery that feels exactly like it did in 2022, except with more meetings. Everyone involved will explain the difference with stories about leadership commitment or culture. The real difference was usually settled before the first workshop, in a decision almost nobody frames as part of the transformation at all: whether the organization's structure would change, or only its vocabulary.I recently wrote about the top of this problem, building on Marty Cagan's Great Products, Bad Companies: governance and ownership decide how long a product operating model is allowed to live. This piece is about the layer just below it. Even with benign owners and a supportive board, a transformation succeeds or fails on organizational structure, because structure is not the container the new culture pours into. Structure is the thing that manufactures the culture.Larman Wrote the Spoiler Twenty Years AgoCraig Larman spent decades inside large-scale agile adoptions and compressed what he saw into a short list of laws of organizational behavior. I keep a copy on my own site because they predict the fate of most transformations more reliably than any maturity assessment.The first law says organizations are implicitly optimized to avoid changing the status quo of middle management and specialist positions and power structures. The second says any change initiative will be reduced to redefining the new terminology to mean basically what the old way meant. Project managers become Scrum Masters with the same job description. Requirements documents become epics. The steering committee becomes a scaled planning event. The words rotate, the structure stays, and eighteen months later someone declares that agile does not work here.The fifth law explains why. In large established organizations, culture follows structure. Values workshops, mindset training, and inspirational town halls try to change behavior while leaving intact the reporting lines, the component silos, the incentive plans, and the approval chains that produced the old behavior. The system pushes back with more force than any poster can push forward. John Seddon, whom the same tradition often quotes, put it plainly: attempting to change culture directly is folly, because behavior is a product of the system people work in. Change the system and the culture moves. This is also why Scrum, done honestly, bites harder than most methods. It is not the standups. It is that real Scrum forces structural change on day one, cross-functional teams, a single owner ordering a single backlog, management stepping out of task assignment, and organizations feel that bite, which is exactly why so many of them adopt the vocabulary and dodge the structure.Conway Wrote It Even EarlierThere is a second, stranger reason structure decides the outcome, and it has been in print since 1968. Mel Conway observed that any organization that designs a system will produce a design that copies the organization's communication structure. Martin Fowler treats this as one of the few durable laws in software: coupling in the product mirrors the human communication that built it, and when team structure and intended architecture disagree, the structure wins.Every customer of a large bank has felt Conway's Law without knowing its name. The mortgage, the credit card, and the current account each behave like products of different companies, because they are, internally. Three departments, three backlogs, three roadmaps, one customer forced to integrate what the organization would not. No amount of product mindset training fixes that experience, because the experience is not a mindset artifact. It is a structural printout. The org chart ships, whether or not anyone intends to ship it.Read those two laws together and the standard transformation program starts to look upside down. It invests in changing how people think, then returns them to a structure that copies itself into everything they build. You cannot out-culture Larman, and you cannot out-train Conway.The Teams Are the First Draft of EverythingThe practical consequence is that team design is not an HR detail to settle after the transformation strategy. It is the transformation strategy. Matthew Skelton and Manuel Pais built Team Topologies, freshly updated in a second edition, around exactly this move, sometimes called the reverse Conway maneuver. Decide what architecture and customer experience you want, then deliberately shape the team structure that would naturally produce it, and let the law work for you instead of against you.Their vocabulary is useful because it is concrete. Stream-aligned teams own a full slice of customer value end to end, without handoffs. Platform teams exist to make the stream-aligned teams faster, not to control them. And the whole design is governed by a limit most organizations never think to measure: team cognitive load. A team responsible for more than it can hold in its collective head will queue, wait, and hand off no matter how agile its ceremonies are. Amazon reached the same conclusion from the other direction with its two-pizza teams, small groups owning services end to end, and the famously decoupled architecture followed the team design, not the reverse.Notice what this reframes. Handoffs, the great killer of flow, are not a process problem you fix with better collaboration. They are a structural feature. If the work must pass through four teams to reach a customer, you designed four queues, and the wait time in those queues will dominate your lead time whatever framework you run. I made a version of this argument with flow data a few weeks ago. Structure is where those queues come from.Run the Ninety-Day TestThere is a blunt way to audit any transformation, past or planned. Take the org chart from the day the program launched and the org chart from ninety days later, and lay them side by side. Look for teams reformed around value streams instead of components or functions. Look for a manager role that changed its job, not its title. Look for an approval step that no longer exists, a handoff that disappeared, a team that can now reach production without leaving its own boundary.If the two charts are identical, the organization did not buy a transformation. It bought training, and Larman's second law is already busy converting the new words into the old system. The kindest thing you can say about mindset in that situation is that it never had a chance. People are not failing to think product. They are thinking exactly the way their structure pays them to think, in components, in handoffs, in cover-yourself approvals, and they will keep doing so until the structure asks for something different.So run the sequence in the only order that works. Ownership sets the ceiling, structure sets the behavior, and culture arrives last, on its own, as evidence that the first two actually changed.Ralph Jocham is Europe's first Professional Scrum Trainer, co-author of "Professional Product Owner," and contributor to the Scrum Guide Expansion Pack. As an ICF ACC certified coach, he works with organizations to build Product Operating Models where strategic clarity, operational excellence, and adaptive learning create measurable competitive advantage. Learn more at effective agile.References[1] Larman, C. 'Larman's Laws of Organizational Behavior'. Available at: https://www.craiglarman.com/wiki/index.php?title=Larman's_Laws_of_Organizational_Behavior[2] Jocham, R. 'Larman's Laws of Organizational Behavior', effective agile. Available at: https://effectiveagile.com/larmans-laws-of-organizational-behavior/[3] Fowler, M. 'Conway's Law', martinfowler.com bliki. Available at: https://martinfowler.com/bliki/ConwaysLaw.html[4] Skelton, M. and Pais, M. (2025) 'Team Topologies, 2nd Edition: Organizing Business and Technology for Fast Flow of Value', IT Revolution. Available at: https://www.amazon.com/Team-Topologies-2nd-Organizing-Technology/dp/1966280009[5] Cagan, M. (2026) 'Great Products, Bad Companies', Silicon Valley Product Group, 30 June. Available at: https://www.svpg.com/great-products-bad-companies/
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Great Products Make Great Targets | 0 | 11.1 | 19-07-2026 |
| 2 | Scrum Isn't for Stormtroopers | 0 | 15.26 | 28-07-2026 |
| 3 | Nobody Believes your Values Page. They're Watching the Deeds. | 0 | 6.22 | 23-07-2026 |
| 4 | The Project Manager Isn't Dead. It Was Disassembled on Purpose! | 0 | 16.43 | 27-07-2026 |
| 5 | Beyond Blame: Transforming Team Dynamics Through Feedback | 0 | 16.56 | 22-07-2026 |
| 6 | Flow Metrics in Python: 3 Scripts for Ensuring Transparency | 0 | 14.98 | 23-07-2026 |
| 7 | The New AI Operating Model. Start By Using Scrum | 0 | 6 | 07-07-2026 |
| 8 | You Can't Train Your Way Out of a Project Mindset | 0 | 5 | 21-06-2026 |
| 9 | Der heimliche Feind jedes Product-Owners: 5 Mythen, die Karrieren ruinieren | 0 | 15.23 | 27-07-2026 |
| 10 | How to Manage Product Risk When You Can’t Predict Everything | 0 | 10.55 | 23-07-2026 |