What I did, why, and what changed as a result — across four industries and thirteen years.
“I never told them the answer, I just made it impossible to miss.”
Delivery predictability: dependencies and sequencing surfaced at planning, across 10+ teams, before execution starts.
Escalation load reduced: teams resolve architecture and process problems themselves, in the room.
Decisions compressed: CXO-level metric conflicts and prioritisation disputes closed in one conversation, not chased over weeks.
Proven at scale: a monolith stuck for years got a migration plan from one retrospective — the highest-risk 40% delivered in 3 months.
This portfolio is built the way I coach: evidence first, framework second. Every claim traces to a story, a room, or a number — not an adjective.
An Agile Coach's job shows up in outcomes, not activity. What changed across four companies and thirteen years — organised the way outcomes actually get evaluated: delivery, quality, predictability, and the people side that makes the numbers durable.
| Teams coached | 10+ Scrum Masters mentored, 20–30+ teams coordinated, 200+ professionals trained across Seamless Systems alone; portfolio-wide coaching at Seamless, Wells Fargo; 7 teams at redBus. |
| Transformation initiatives | Two acquired companies at Seamless Systems, different tech stacks and cultures with zero shared delivery rhythm, brought fully onto iterative ways of working, with team members trained on-site in France and Romania. |
| Product unification | 15+ client-specific versions of Seamless's own product consolidated into one, with feature toggles for customisation, over 9 months — reducing OpEx by roughly 30% and removing the need for customer-specific teams. |
| Delivery improvements | Features shipped increased 40% during a protected 4-month transition window at Seamless, once CXO leadership agreed to one metric instead of judging a new way of working against the old one. |
| Lead time / launch timelines | International launch timelines cut 25% across Indonesia, Peru, and Colombia at redBus, through Big Room Planning and continuous reprioritisation on market signal. |
| Escaped defects | Defects halved in the same 4-month Seamless transition window — the direct result of protecting the team from being measured on old-world velocity while learning a new way of working. |
| Release frequency & predictability | Shifted teams from output reporting (velocity) to outcome tracking (TTM, NPS, value delivery) at redBus. At Seamless, one agreed metric (iterative delivery) gave CXOs a predictable signal during transition. |
| Stakeholder satisfaction | Business engagement up 40% at Seamless. Sprint review attendance recovered after leadership felt the cost of missing decisions. Weekly CEO / daily CTO+CPO cadence at redBus kept trust current, not quarterly. |
| Dependency visibility | Introduced structured dependency mapping at three companies — redBus (7 teams), Seamless (4 functions: Product, Engineering, Operations, Sales), and S&P Global — each time cutting cross-team delays measurably. |
| Individual growth | 10+ Scrum Masters coached 1:1 into stronger facilitation and stakeholder handling; one Product Manager coached from cold-case remote disengagement, back into the room (see Section 03). |
"I don't hand teams the answer. I design the conditions for them to find it themselves — surface the evidence, ask the question that has no wrong answer, then let the room own the conclusion. That's how resistance turns into ownership: not through argument, but through a diagnosis the team arrives at on its own."
Sit in Events. Stay quiet. Notice where energy drops, where people go silent. The intervention comes after the diagnosis, not before it.
Not the most senior, not the most resistant. Build outward from evidence, one team at a time, until the sceptics run out of reasons.
Evidence first. A one-page summary of what changed carries more weight than a pitch for buy-in ever will.
The team usually knows the problem already; they just haven't said it out loud together. The right question does the rest.
Change the conditions first — the behaviour follows. Teams can't learn a new way of working while being judged on the old one.
One team delivered roughly 60% of forecast, with items pushed into sprints from unclear sources. New to the team, I read it as a trust problem and spent three to four months on retros and physical-wall visualisation. The actual problem was structural: their working pattern didn't fit Scrum's fixed-sprint model, and the EM had said as much early on: "our team doesn't want to do Scrum." I heard that as resistance, not as data.
Once I recognised the mismatch, we moved the team to Kanban: flow visualised, WIP limits in place, EM and PO owning reprioritisation. Delivery stabilised.
The tools I reached for first were right for a trust problem. This wasn't one.
"Agile Coach" gets used as one label for four different jobs. I move between them deliberately, and I know which one I'm in at any given moment — that choice is itself part of the craft.
| Stance | What it looks like | When I use it | Evidence |
|---|---|---|---|
| Coaching | Ask the question that has no wrong answer; let the room reach its own diagnosis | When a team already has the answer but hasn't said it out loud | The jeep retro — architecture decision, team's own conclusion (Section 05) |
| Mentoring | Work alongside one person on their own growth edge, over time | Developing Scrum Masters and Product Owners individually, not just as a group | 10+ SMs mentored at Seamless; one PM coached into re-engaging stance (Section 03) |
| Facilitating | Design and run the room; stay neutral on content, own the process | Multi-team planning, retros, workshops where the group must reach its own output | Big Room Planning at redBus — CPO, CTO, CEO, 10 PMs, 10 EMs in one room |
| Teaching | Give direct instruction or a lived simulation when the team lacks a concept, not just a habit | New-to-Agile teams, or a concept no amount of questioning will surface on its own | The Ball Point Game — self-organisation taught from the inside, not off a slide |
A team's behaviour is a symptom of its structure, not its character. I don't fix people; I change what the room can see, and let the system correct itself. That's why the interventions in this document look different from each other (a jeep video, a dependency wall, a protected metric window), but the underlying move is always the same: change the conditions, then get out of the way.
Both redBus and Seamless Systems put me in a direct reporting line to the top of the organisation: CEO at redBus, COO (owning both product and technology) at Seamless. That wasn't incidental. An Agile Coach who reports into engineering only sees half the problem. Reporting to outcomes means sitting in the gap between what leadership believes is happening and what the delivery data actually shows, and closing it with evidence, not advocacy.
Weekly with the CEO on direction — revisiting product goals against market signal, then translating changes into the roadmap with the CTO and CPO.
Daily Scrum of Scrums with CTO, CPO, and EMs/PMs — run on a physical wall with the full dependency chart visible: what's prioritised, who owns it, ETA, and any blockers.
The gap between the weekly direction conversation and the daily delivery reality was my operating space.
Direct line to the COO — one conversation, both sides of every delivery problem. No translation layer between product and engineering leadership.
Told CXO leadership directly: you cannot run a transformation and a performance review on the same metric. Won a protected 4-month window — and delivered inside it.
The team layer is the visible half of the job. Alongside it, every engagement carries a 1:1 coaching thread — Scrum Masters and Product Owners working through their own blockers, decisions, and growth edges, so the system holds up even when I'm not in the room.
Before choosing an intervention, I read where a team actually is — not where the calendar says they should be. I use a simple forming-to-self-managing lens (adapted from Tuckman) as a working diagnosis, not a scorecard I show the team — it shapes which stance I take and which retrospective format I reach for. Two examples of it actually firing, at opposite ends of the scale:
A team I joined was closed off — a sharp contrast to the openness I'd found at redBus. I read it as a trust gap, not hostility, and started with the lowest-stakes formats I had: Weather Map, Stars & Tweets. No pushing for depth before the team was ready for it. Full arc and outcome in Section 06, Chapter 2 — this is the same team.
A team already strong in iterative delivery didn't need more scaffolding — they needed a stretch. I showed them a Mob Programming video in a retro; I judged them ready for it because they were operating at what I'd call a Performing stage. The team volunteered to run their next sprint story as a mob-programming exercise — their call, prompted by the video, not assigned.
Getting Product into the room. Product wasn't in the room, and the PM was remote — a cold case wouldn't work. I found one Product Owner who already had the PM's trust and coached them 1:1 over several weeks: what to say, when to say it, how to bring evidence instead of an argument. I asked that PO to join backlog refinement and sprint Events for one month, no announcement. Friction dropped visibly; that team's feature rollout was faster and cleaner than anything before it. The PO and I went to the PM together to show what had already changed — he agreed to pilot with two more teams. It scaled from there: all POs embedded in engineering delivery rhythms across the whole product organisation within three quarters.
This is a 1:1 coaching story before it's a room-level one — the PO's own growth (confidence, evidence-led influence, stakeholder handling) was the actual intervention. The room-level result followed from it.
Coaching a peer through her own incentive, not around it. A PM was withholding requirement details from Engineering, and wouldn't say who else on the business side they could go to for clarification — Operations held context the PM wasn't sharing. The root cause wasn't process; it was fear of losing control of the team if she opened that access. I didn't escalate it. I sat with her directly and worked through what withholding access was actually costing her: poor outcomes, and little to show her own manager next quarter. Opening access to Operations meant Engineering would trust her more, not less, and freed her to focus on roadmap and other priorities instead of being the bottleneck for every question. She granted the access. Outcomes improved.
Growth, not just coverage. At Seamless, mentoring 10+ Scrum Masters wasn't a group briefing: each SM had a different gap. One needed help holding a boundary with a demanding PM, another needed to learn to read a room before intervening, another needed to stop solving problems the team should own. The coaching was matched to the person.
Held accountable to their own growth, not mine. The measure of a good 1:1 wasn't whether the SM agreed with me — it was whether they could run the same diagnosis without me in the room three months later.
Hired and trained, not just coached. Beyond mentoring SMs already in place, I hired and trained Scrum Masters as part of transitioning the acquired companies (Section 06, Chapter 3) onto Agile ways of working — including training Engineering and Product teams directly in France and Romania.
PSM II, PSPO II, KMP-I certified. Formal training in Scrum & Kanban coaching sits alongside the practical mentoring — both feed the same 1:1 conversations.
Five companies, four industries, thirteen years — each stage adding a different layer of scale, regulation, or organisational complexity to the same underlying instinct: make the problem visible, and let the team own the fix.
redBus was the largest online bus ticketing platform in India, in hyper-growth and expanding into Indonesia, Peru, and Colombia — an engineering org of 100+ people where speed mattered as much as reliability.
"I didn't tell them their architecture was wrong. I showed them a jeep. Monolith to microservices. Their call, not mine."
Monolith-to-microservices decision made in retro. Payment and booking critical path migrated in 3 months — team-driven, not top-down.
Big Room Planning — CPO, CTO, CEO, 10 PMs, 10 EMs. Rollouts to Indonesia, Peru, Colombia delivered ahead of the 12-month plan through continuous reprioritisation on market signal.
Two-stage: blockers surfaced in planning (nobody could claim ignorance), then lived on a physical wall during delivery — visible daily, impossible to ignore.
30+ formats: story cubes, darts, draw circles. Teams that used to sit through treat retros out of obligation started asking what was running next.
Weekly with CEO on direction. Daily with CTO and CPO on delivery health — grounded in data, not hope.
A different version of the product for every client — separate codebases, separate priorities, separate roadmaps. Product, Engineering, Operations, and Sales never shared a room or a plan. Three chapters, in the order they happened: getting Product into the room, unifying the product line itself, then bringing two acquired companies onto the same way of working.
Chapter 1 — Internal Transformation (Years 1–2)The first challenge wasn't Agile adoption — it was that Product, Engineering, and Operations ran on separate tracks. Dependency mapping became a first-class practice across all four functions: built collaboratively in planning so nobody could claim ignorance, then lived on a physical wall during delivery, visible and updated daily.
Didn't argue. Found the one person willing to try, ran two sprints with visible output. The lead watched. By the third sprint, the sceptics ran out of reasons — he changed his mind because the team next to his was shipping faster, not because of anything said in a meeting.
"I didn't argue with the sceptic. The results did."
Their mental model was the problem, not their calendar. Sent a one-page summary after every review (what was built, what decision it enabled), then followed up directly. After three cycles, leadership started attending: they had felt the cost of not being there.
"I stopped asking for their time. I showed them what they were missing."
One team, when I joined, was closed off — a sharp contrast to the openness I'd found at redBus. I read it as a trust gap and started with the lowest-stakes retro formats I had: Weather Map, Stars & Tweets. Over roughly a quarter, the team opened up (the maturity-lens read behind this choice is in Section 03).
Once that trust existed, I ran Value Stream Mapping with them — a technique that only works if a team hands you the real picture, not a sanitised one. I extended the same exercise with other teams, going deeper with Engineering Managers and Product Managers directly. What it surfaced: the org was carrying 15+ versions of the product, one per client, because every client had asked for different features and nobody had ever stepped back to ask what the actual product was.
I took that finding to my COO, who held both CTO and CPO, and made the business case directly: we were carrying rising OpEx (bug fixes and maintenance duplicated across 15+ versions, different skillsets needed per client) against a CapEx that should have been building one product, not fifteen. That conversation is what authorised the unification effort.
With Engineering, Product, Operations, and Sales in the room, I facilitated a product deep-dig using User Story Mapping, User Journeys, and a Product Pruning Tree — mapping where the product carried the most weight, and what could be cut. Engineering data showed which features were actually used and where the real problems sat. Together, that became a roadmap for one generic product. Around 5 engineering teams, 2 Product Managers, and 3 Engineering Managers worked directly on it, while the rest of the org kept serving existing client work that couldn't be paused.
Nine months later: one version of the product, with feature toggles built by Engineering so any client's configuration could be served from the same base — not, as before, a snapshot of whichever client's release happened to be furthest ahead. OpEx dropped by roughly 30%. Customer-specific teams were no longer needed.
"We didn't have a Product. We had fifteen customers, each with their own copy of one."
A separate, later challenge — two acquired companies, both running waterfall, different tech stacks, different cultures, and different products from Seamless's own line (these stayed separate products; the goal here was working model, not product convergence). The resistance looked the same in both. Around 50 people each, no reason to trust a new way of working.
Teams were being judged on old-world velocity while learning a new way of working. Argued directly: you can't run a transformation and a performance review on the same metric. Won one agreed metric (iterative delivery) for a 4-month window. Features rolled out increased 40%, defects halved, time to market improved.
"I argued against the metrics. Got the window. Delivered."
Beyond the room-level resistance, the underlying work was hiring and training: I hired and trained Scrum Masters for both acquired companies, and trained Engineering and Product teams directly on-site in France and Romania. Both companies kept their own products, genuinely different from each other, but fully adopted iterative ways of working by the end of this chapter.
| Product Unification | 15+ client versions consolidated into one, with feature toggles for customisation, in 9 months — OpEx reduced roughly 30%, customer-specific teams no longer needed. |
| CXO Metrics | Argued against judging a transformation on old-world velocity. Won a protected 4-month window on one agreed metric — features rolled out up 40%, defects halved. |
| Acquisitions Onboarded | Two acquired companies, different tech stacks and cultures, brought fully onto iterative ways of working — teams trained on-site in France and Romania. |
| Leadership Engagement | Sprint review attendance recovered after leadership felt the cost of missing decisions — one-page summaries after every review, followed up directly. |
Observe before acting. Sit in Events. Stay quiet. Notice where energy drops. The intervention comes after the diagnosis.
Make the value visible before asking for commitment. Evidence first. The rest follows.
Remove the barriers to learning. Change the conditions first — the behaviour follows.
Ask questions. Don't give answers. Solutions people find themselves stick. Solutions handed to them don't.
"Make it visible, and it exposes the truth. Make it a game, and a team stops being told what to think — they start working it out themselves."
Thirteen years of coaching taught the same lesson every time: a team fixes what it can see, and it learns fastest when it's playing, not being lectured. This isn't a once-a-sprint ritual; it's a standing system with four mechanisms running underneath every team, every sprint, without exception.
It's a diagnosis, not a default. A team that's gone quiet needs a different opener than one that's openly frustrated. Weather Map reads a room fast; Stars & Tweets gives the quiet ones a low-stakes way in.
Matched to the team's maturity stage. A newly formed team needs Set-the-Stage formats that build psychological safety; a team that's been together a year and gone stale needs something that disrupts the routine.
Built for the recurring blocker. A team stuck on the same issue needs something built to surface root cause — that's when Marginal Gains or a value stream map comes out, not another generic retro.
What visibility compounds into. Bottlenecks stop being abstract and start being a place people look. WIP limits, Definition of Done, and working agreements get checked daily — that's what makes people accountable.
| Stage | Format | What it does | What it produced |
|---|---|---|---|
| Set the Stage | Weather Map | One placement, sun to storm, before a single word is said. | Surfaced mood swings the standup never caught; cut warm-up time by half. |
| Gather Data | Team Health Radar | Five axes — Collaboration, Trust, Accountability, Process, Product — scored live. | Surfaced trust issues between Product and Engineering that became the basis for three sprint improvements. |
| Gather Data | Repeat / Avoid / Add | A People/Process/Technology matrix forcing every issue to a verdict. | Every category walked out with its own action list, not a wall of notes nobody revisits. |
| Generate Insights | Sailboat | Anchors for what's dragging the team down, wind for what's pushing it forward. | Turned named anchors into actions that helped the team ship faster the next sprint. |
| Decide | Value / Effort Quadrant | Team plots its own backlog by value against effort, agrees live on what's next. | Shifted prioritisation from a PO call to a team decision — fewer re-litigated backlogs. |
| Decide / Close | Retro Dart | Target-board prioritisation — closer to centre, higher the rank. | Set a clean cutoff for what actually made next sprint's action list. |
| Close | Thank You & My Action | Closes on acknowledgment by name and one personal commitment. | Made recognition a habit; every person left with one thing they'd personally committed to. |
| Training | The Ball Point Game | A live production simulation — five timed iterations, plan and retro between each. | Team voluntarily reduced WIP limits afterward and ran the next sprint with fewer carry-overs. |
This isn't a pivot away from coaching. It's a differentiator inside it: every team I coach now is being asked to adopt AI into its own workflow, so I put myself through that exact unfamiliar-change experience first, with no coding background, to know what I'm asking of a team before I ask it.
A live, installable PWA for Scrum facilitation. 152 prompts across 14 events, built entirely through AI prompting. Used in the room to coach adoption, not just as a demo.
The most personal build: a contextual banking feature born from my own relocation to Berlin. Full PRD to working prototype, solo, end to end.
A two-agent system grounded in a personal knowledge base (RAG), not generic model output. Parses casual notes into structured profiles, generates localised, budget-matched gift suggestions on request.
A manager agent orchestrating four sub-agents across live calendar, transit, and briefing integrations.
An Agile Coach's credibility with engineering teams comes from having actually built something, not from having read about building. These projects are proof of the same instinct that runs through every case study in this document: don't theorise the change, go through it, then bring back what's true.
Venkata Krishna Kalluri (KVK) — Agile Coach, 13 years across fintech, banking, telecom & e-commerce. Berlin-based.