Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASAThe most dependent teams I've seen were built by the most generous people in the building. That isn't a coincidence. It's a pattern, and it's almost always invisible to the people causing it. Picture the support an organization builds with the best of intentions. Every team gets an agile coach with a playbook. A transformation office owns the roadmap so teams "can focus on delivery." There's a center of excellence to set the standards, a templates library, a guardrail for every decision that used to feel risky. Impediments get cleared before most teams even notice them. From the outside it looks like care. It is care. Then something moves. A reorg. A budget cut. The coaches roll off to the next program. The transformation office gets folded into something else. And the teams don't stand up. They wobble, then they stall. Decisions that should take an afternoon sit for two weeks, because nobody on the team has ever actually made one. The standards drift, because nobody owned them, they were issued. It turns out the organization wasn't holding the teams up. It was holding them. Nobody meant for that to happen. That's the whole point. In Terry Goodkind's Sword of Truth, the second rule a wizard learns is shorter and meaner than the first: "The greatest harm can result from the best intentions." In the story, the Rule first shows up as a way to gain control. Someone offers to carry your burdens. I'll cover it, just come with me, the others are wrong and only want you working harder where you don't need to. The offer lands because it's a relief, and the person who accepts it slowly hands over the ability to stand on their own. Carry someone's weight long enough and they grow dependent, then helpless, then bound to the very person who lifted it. That's the move, and it doesn't need malice to work. The same mechanism runs just as well from inside genuine kindness: someone who truly wants to help takes the hard thing off your plate, keeps taking it, and weakens you in exactly the same way. Good intentions or bad, the result is identical. That's what makes the Rule so hard to see, and so hard to stop. Goodkind put that in a story about magic, wizards, and rulers. It describes a transformation office just as well, and it doesn't stop at the transformation office.The same kindness, four disguisesThe harm in your organization isn't coming from the people who don't care. It's coming from the people who care most, and express it by doing the team's hardest work for them. Once you see that, you start seeing it everywhere, not just in the program office. Look at the Scrum Master who's a little too good at the job. Every impediment vanishes before the team feels it. Every awkward conflict gets smoothed over before it surfaces. Every hard conversation with a stakeholder gets handled, quietly, off to the side. The team loves this Scrum Master. The team is also, slowly, forgetting how to remove an impediment, sit in a conflict, or manage a stakeholder, because they never have to. Self-management is a muscle, and someone keeps doing the reps for them. Look at the manager who buffers the team from "difficult" stakeholders. It feels protective. It is protective. It also cuts the team off from the exact feedback that would tell them they're building the wrong thing. Honest Inspection needs the stakeholder in the room being honest. Filter the stakeholder, and you've filtered the inspection. Look at the governance layer added "for safety." Two more approvals on every release, introduced after something once went wrong, with the entirely reasonable goal of reducing risk. A year later, learning has slowed to the speed of the slowest approver, teams ship later and in bigger, riskier batches to make the approval worth the wait, and the control added to reduce risk is now the thing manufacturing it. Beautiful irony, and nobody chose it on purpose. Look at the single Product Owner crowned "one throat to choke." Centralizing every product decision in one person feels efficient and accountable. It also means the team stops doing its own product thinking, because there's no point: someone else decides. The day that person is on holiday, the product brain of the team turns out to be one calendar away from offline. Four disguises, one move. A coach, a manager, a governance board, a Product Owner. Every one of them helping. Every one of them, in the act of helping, removing the thing the team needed to grow. There's a line that gets crossed in all four without anyone noticing. Supporting a team is not the same as rescuing it. A coach who builds capability and a coach who builds dependence look identical on a Tuesday. Both are in the room. Both are helping. The difference only shows up later, when the help leaves and you find out whether anything was actually built, or just borrowed.What the rescue removesThis is exactly where it touches fundamentals, because the thing agile is built on is self-managing teams that own their outcomes. That has a name: Outcome Ownership, where the team collectively owns getting to the result, not just finishing the tickets, and nobody hides behind "my part was done." It travels with a second fundamental, Decision Mandate, because a team can't own an outcome it isn't allowed to make the decisions about. The point is blunt: responsibility comes with a mandate. You don't get to hold a team accountable for outcomes while taking away the decisions that shape them. Both are exactly what kind dependence removes. The over-helpful Scrum Master removes the decisions. The single Product Owner removes the ownership. The governance layer removes both and calls it safety. Take ownership and decisions off a team, however gently, and there's nothing left to be agile with. That's the trap in the Second Rule. The most natural way to be good to a team, take the hard thing off their plate, is also the most reliable way to keep them from ever growing the muscle that hard thing would have built. You can't hand someone ownership and shield them from its weight at the same time. The weight is the thing. A servant leader builds the capability that lets a team carry its own weight. A rescuer builds a need for themselves, then mistakes that need for being valued. The counteraction to the Second Rule has a name of its own: Skill Completeness. External help should accelerate a team, not rescue it. Specialists can pitch in. The team shouldn't be helpless without them. Call it kind dependence. Everyone is being good to each other. Coaches coach, managers shield, the office handles the messy parts, the Product Owner decides, and the team delivers in the clean lane that's been built for them. It runs beautifully, right up until the lane disappears. If you read the last post in this series, you'll notice every one of these helpers is running Wizard's First Rule on themselves. They believe a comfortable lie because they want it to be true: "I'm helping." And they avoid an uncomfortable one because they're afraid of it: "If I let them struggle, they might fail, and that's on me." Hope and fear again, this time wearing the face of generosity.Four signals of kind dependenceYou can spot it before the support ever leaves. 1. Teams escalate decisions they're fully equipped to make. Every non-trivial call routes upward, or sideways to the coach, or up to the Product Owner. The organization reads this as "they need more support" and adds more, which teaches the team to escalate sooner next time. The help is manufacturing the helplessness it's responding to. 2. Pull one person out and the team stops. Remove the coach, the lead, the Product Owner, the transformation office, and capability leaves with them. If competence walks out the door when a person does, you built dependence and called it enablement. 3. A control added "for safety" now sets the pace. There's an approval, a template, a checkpoint that was introduced to reduce risk, and the honest version of its job description today is "the reason learning is slow." Nobody will say that out loud, because it was added by someone reasonable, for a reasonable reason. 4. "Protecting the team" is a stated value. Stakeholders get filtered. Hard news gets softened. Discomfort gets absorbed by a layer of management before it reaches the people doing the work. The team stays comfortable and stays small, because someone keeps taking the hit that would have grown them.One move, and it costs the helpers more than the teamPick one accountability your organization currently carries on behalf of its teams. Prioritization. Impediment removal. Stakeholder management. The product decisions. The approval everyone routes through. Pick one, and for one quarter, hand it back. Fully. Not "we'll support you with it." Hand it over and let the team carry the weight. Then do the hard part. When they wobble, don't catch them. Sit on your hands. Answer "I'll handle it" with "how will you handle it?" The wobble isn't the support failing. The wobble is the muscle finally being asked to work. Before you solve another team's problem for them, ask one question. If we disappeared tomorrow, would this team be more capable, or just stuck? If the honest answer is stuck, you haven't been building agility into them. You've been renting it to them, and the lease is the only thing holding the place up. The kindest thing you can do for a team is also the thing that feels least kind in the moment: let them own the hard part, and stay close while they struggle through it. No framework teaches you the difference between support and rescue. Only the willingness to watch someone you could rescue learn to stand on their own. The Rule doesn't care whether you believe it. That's what makes it a Rule. Take this Rule into your next conversation with a struggling team and ask: is the most helpful thing I can do here to step in, or to stay close and let them carry it? If this Rule cut close, pass the blade on. Share.
Welcoming your comments on this!
Don't want to miss any of these articles? Have the “Fundamentals before Frameworks” series in your mailbox.Wishing you an inspiring read and a wonderful journey.Scrum on!
Image
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | The Wizard's Rules: A Field Guide to How Your Organization Lies to Itself | -2 | 6 | 18-06-2026 |
| 2 | Your Agile Transformation is a Lie You Wanted to Be True | -6 | 4 | 25-06-2026 |
| 3 | The Most Passionate Transformations Make the Worst Decisions | -2 | 6 | 09-07-2026 |
| 4 | Wird Product-Ownership zum Flaschenhals im KI-Zeitalter? Warum viele Product-Owner schlecht priorisieren, warum KI das sichtbar macht und 10 Werkzeuge, um besser zu entscheiden | 0 | 7 | 07-07-2026 |
| 5 | Prioritizing Is the Hardest Thing Your Brain Does. Your Calendar Treats It Like the Easiest. | 0 | 5 | 05-07-2026 |
| 6 | The New AI Operating Model. Start By Using Scrum | 0 | 6 | 07-07-2026 |
| 7 | Ordering the Product Backlog with RICE: From Opinion to Evidence | 0 | 5 | 09-07-2026 |
| 8 | If You Can Write Acceptance Criteria, You Can Write an AI Routing Policy | 0 | 7 | 05-07-2026 |
| 9 | Der kleine Schritt von Akzeptanzkriterien zu einer KI-Routing-Richtlinie 🇩🇪 | 0 | 7 | 08-07-2026 |
| 10 | Discovery Is De-Risking, Not Requirements Gathering | 0 | 6 | 04-07-2026 |