TL;DR
Capacity on the shared development pole went to whoever lobbied hardest, and one unit starved on its roadmap. I taught myself Scrum in a week, adapted it to a three-unit micro-team, and left it running. The method outlived the rescue.
The situation as found
The parent group ran its web development through one small pole serving three business units. One lead developer, freshly recruited and helped by one apprentice, carried it all, setting his own time, planning, and tickets with no shared system.
- No shared queue, so nothing set the order.
- No arbitration, so priority favored the loudest voice.
- One developer for three units, so urgent tickets displaced planned ones.
He could not say no, so any project manager who pushed hard enough got an urgent ticket through; the defect was structural, not his goodwill. One unit, Astrocenter, stayed on its roadmap instead of lobbying and fell behind schedule, hurting its performance. I was responsible for that unit, and this site calls that shape rescue and turnaround.
The diagnosis
The presenting symptom was Astrocenter slipping on schedule. The cause was not the developer’s effort or goodwill but the absence of any shared prioritization structure. With no arbitration, capacity flowed to the loudest voice, and the unit that kept to its roadmap instead of pushing went without. That is a structural defect, not a people failure; leaning on him harder would only have moved the unfairness around. Reading it as structure, not as a slow developer, is what opened the next move: the team needed a way to decide, not more effort.
What was decided, and why
The standing expedient was personal persuasion: project managers won their slots by pressing the developer directly. I refused it; that pressure had produced the unfairness.
I did not know Scrum or Agile beyond a few notions. I bought the reference work and, in a week, adapted a model written for far larger teams onto a micro-team of three Product Owners and two developers, while still running my unit. That is the self-taught half of the Crisis-Proof Builder identity. I named myself Scrum Master, and because my own unit was one of the three, I put a manager from that same unit in as Product Owner so I was not judge and party in my own case. I led this myself; the team carried it.
What was actually built or changed
The system had eight parts, each answering something the old arrangement lacked.
- Sprints of fifteen days, a fixed rhythm in place of an open queue.
- A priority sheet per Product Owner, kept in Google Sheets and filled before each sprint so precedence was written down, not lobbied.
- Estimation by the lead developer, who weighed each ticket for feasibility and required time.
- Tickets written by the developer himself in Jira, so control stayed with the person doing the work.
- A good-behavior charter signed by everyone, barring urgent tickets forced outside the chain.
- A retrospective at each sprint end, chained into the next planning, with a prep meeting with each Product Owner beforehand.
- Bandwidth prioritized by medium-term objectives and foundation projects, not a fixed carve of points.
- A standing split between foundation work and new tickets, keeping headroom for bug fixes.
What broke, and what I got wrong
The install was not clean. I was learning the method as I led it, bending a model built for large teams onto a three-Product-Owner micro-team, and some of it did not fit at first. The neutrality problem was real: my own unit was one of the three, and the Product Owner designation and the charter were built to answer it. The charter exists because forcing tickets through had been the standing abuse, and I did not hide that. The method leaned on my own stewardship as Scrum Master before I could ease out and let the team hold it.
The outcome, with its status
Observed within a month: the teams were calmer, projects advanced in parallel, and no business unit found anything to complain about; management was relieved. Observed over the months: I lightened my Scrum Master role and gave the lead developer more autonomy, while making sure the principles and the charter held.
The institutionalization: the method was kept for as long as the group needed it, and the group’s IT direction never imposed the stricter Scrum rules in force in the rest of its teams. It stayed the team’s system for years after I stepped back. A rescue left running without me is the mandate behind the who I am page.
If this is the shape of your problem, let’s talk.