The company runs 80 engineers across eight teams: catalog, checkout, payments, logistics and platform, among others. Most customer-facing releases need at least two or three of them. A new delivery option, for example, touches checkout, logistics and often payments.
The challenge: green status reports, late releases
On paper, things looked fine. Each team had its own board, its own sprint goals and its own status update, and most of those updates were positive. Catalog was on track. Checkout was on track. Payments was nearly done.
Then the release date came and the feature wasn’t ready.
What was missing was usually a piece of work that one team needed from another. Checkout had finished its part but was waiting on an API change from platform. Logistics was ready but couldn’t test until payments merged something. Each of these was small on its own. Put together, they pushed releases back by days or weeks, and leadership often learned about it in the last week before launch, when there was very little left to do about it.
Only 60% of releases shipped on the date originally agreed with the business. The rest moved, and almost always for the same kind of reason.
The setup: one view across eight teams
Rollout took two to three weeks. The company connected Jira and GitHub, then grouped work from different teams under shared initiatives, so a release was no longer eight separate boards but one piece of work with all its parts visible together.
On top of that, the team set up a risk review: a regular look at each initiative’s completion forecast, the tasks blocking it, and which team those tasks belonged to. Nobody had to fill in a new report for this. The data came from the tickets and pull requests the teams were already working with.
What leaders do differently now
The biggest change was timing. Instead of hearing about a slipped release at the end, engineering leaders now check where each initiative is heading while there is still room to act.
Forecast first. Each review starts with the projected finish date of every shared initiative. If it has moved past the agreed date, that’s the first thing discussed.
Find the blocker. From the initiative, leaders go down to the specific blocked tasks and see which team owns them and how long they’ve been waiting.
Change priorities early. If platform is holding up checkout, the platform work moves up the queue now, not two days before launch.
None of this needed a new process on the teams’ side. It needed a place where the dependencies were visible at all.
Results after four months
Releases on the originally agreed date: 60% → 80%. One in five releases still moves, but far fewer of them slip because of something nobody saw coming.
Median time blocked on dependencies: 5 → 3 working days. Blocked work gets noticed and unblocked sooner because someone is looking for it every week.
No extra reporting for teams. Status comes from Jira and GitHub as they are already used.
| Metric | Before | After 4 months |
|---|---|---|
| Releases shipped on the originally agreed date | 60% | 80% |
| Median time blocked on dependencies | 5 working days | 3 working days |
What’s next
With shared initiatives in place, the company plans to bring more of its roadmap into the same view, so that cross-team work is planned with dependencies in mind from the start rather than discovered halfway through.