Venkata Krishna Kalluri (KVK) — Facilitation & Gamification Portfolio

Agile Coaching Skill Suite

Helping organizations improve delivery predictability, planning confidence, stakeholder alignment, and dependency management.

Through enterprise facilitation, coaching, and visualization — not just facilitated meetings.

Story Mapping

Big Room Planning

Facilitation

Visualization

Agile Coaching

Executive Alignment

At a Glance

Whole-product planning, not facilitated meetings.

I run cross-team dependency mapping and structured retrospectives that turn recurring blockers into shipped fixes.

10+

Teams planning off one map

30+

Retrospective formats tested

40%

Of a stuck monolith migrated in 1 quarter

13 yrs

Embedding this as a standing system

✓ 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

Prioritization and stakeholder alignment closed in structured sessions, not chased over weeks of email.

✓ Proven at scale

A monolith stuck for years got a committed migration plan from one retrospective, 40% delivered in 1 quarter.

Core Facilitation & Agile Coaching Capabilities

Seven capabilities, each tied to a business outcome.

Capability	Business Value
User Story Mapping	One shared forecast across 10+ teams, replacing 10+ separate status updates
Big Room Planning	Cross-team dependencies surfaced at planning, not discovered mid-sprint
Agile Coaching	Teams resolving delivery and process challenges without leadership intervention
Retrospectives	Recurring blockers converted into committed sprint actions, not repeated complaints
Visualization	Delivery risks surfaced daily through visual management, reducing status meetings
Product Prioritization	Investment calls made on shared value-vs-effort data, not opinion
Facilitation	Stakeholder decisions closed in the room, not chased over email for weeks

My Coaching Philosophy

A standing system, not a once-a-sprint ritual.

"I don't fix people; I change what the room can see, and let the system correct itself."

01
Thirteen years of coaching taught me the same lesson every time — a team fixes what it can see, and it learns fastest when it's playing, not being lectured.
02
The team layer is the visible half. Alongside it, 1:1 coaching with Scrum Masters and Product Owners — working through their own blockers, decisions, and growth — so the system holds up even when I'm not in the room.
03
The lens underneath all of it is systemic — a team's behaviour is a symptom of its structure, not its character.
04
Planning runs on the same principle — a User Story Map puts the whole product on the wall before a single sprint is planned, so the team plans against the journey, not just the backlog.
05
Retrospectives and facilitation run on varied content and numerous formats, matched to whatever sprint or iteration the team is going through.

How I choose the format

→
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.
→
A team stuck on the same recurring blocker needs something built to surface root cause — that's when 5 Why's or a value stream map comes out, not another generic retro.
→
The format is a diagnosis, not a default — picked for where the team is, not for what ran well last time.

What visibility compounds into

→
Dependencies identified before execution, reducing mid-sprint surprises.
→
Bottlenecks stop being abstract and start being a place people look.
→
WIP limits, Definition of Done, and working agreements stop living on a page — they get checked daily, and that's what makes people accountable.

Reinforcement, Not Decoration

Videos & games that teach from the inside.

I read the context a team is in and match it to the video that fits. Each one hands them a different lens, then gets out of the way and lets them apply it to their own work.

The games that teach from the inside — worked at scale

Ball Point Game

Puts teams through the iterative loop itself, until incorporating feedback early stops being a slogan.

Coin Game

Hands teams Kanban and WIP limits as something to run, not read about.

Jenga Blocks

Makes the cost of skipping testing physical: pull the wrong piece too late, and the structure goes down. No metaphor required.

The System

Five mechanisms, different cadences.

01

Whole-Product Visualization

Story mapping · Big Room Planning

Before planning starts, the whole product goes on the wall — epics, journeys, releases. Every team plans against the same map, not its own slice of a backlog.

02

Visible Delivery & Accountability

Sprint boards · WIP · DoD

Visual boards on the wall, in front of the team, every day. WIP limits, team agreements, and Definition of Done don't get chased — they reinforce accountability.

03

Structured Retrospective Library

30+ formats tested

Set the Stage. Gather Data. Generate Insights. Decide. Close. Thirty-plus formats, one for every stage — picked on purpose, every time.

04

Rotating Engagement Cadence

Every 2–3 weeks

The JIRA dashboard carried a curated video slot, refreshed every cycle and tied to whatever the team was actually going through — never generic, always current.

05

Purpose-Built Training Games

Formats as per the goal

Self-organization. Flow. WIP theory. Early testing. Fast feedback. A game for each lesson, built for whatever the team actually needed to learn.

Case Study

User Story Mapping: visualizing the whole product before planning it.

The wall shown here is an illustrative example — a travel-booking product used to walk through the technique, not a specific client engagement.

A user story map on a wall showing narrative flow across activities with release slices R1 and R2 below

10+ teams, one wall — narrative flow on top, release slices (R1/R2) below.

10+

Teams planning off one map

1 → 5

One backlog item, 5 teams synced to it

1

Forecast, replacing 10+ status updates

A backlog tells you what needs to be done. A map tells you the whole story.

10+ teams, roughly 60 engineers and product managers, one product, one backlog — Payments, Design, Web, iOS, Android, API, Accounting, and more. A backlog doesn't show the journey or the order. I built the map that did, live, in the room, with the people who'd use it.

How It Was Built

Product and Engineering Managers set the product goals and broke them into epics. Those epics went up on the wall as activities — Booking, Payments, Cancellation, Check-in, Support, Admin, Languages — left to right, in narrative flow. Underneath each, the epics broke down further into user tasks: Search Dates, Manage Currencies, Wallet Integration. That's the backbone — the whole product, in one place, for the first time.

Where It Earned Its Keep

One card, Visa/Mastercard integration, looked like a single task. Dug into during Big Room Planning, it became a four-iteration plan across five teams — API explores, then builds; Design builds wireframes in parallel; Payments consumes the API; Web, iOS, and Android pick it up last. One card, mapped to the exact sequence and iteration each team needed to hit it.

The Release

A tape line across the backbone split the forecast into R1/Q1 and R2/Q2. R1 was the smallest set of user tasks that still added up to one complete journey — a walking skeleton every team forecast together, not a wish list. What didn't make either slice stayed visible below the line, not lost.

For Leadership — What It Meant

Before this, a CXO reconciled 10+ status updates by hand, each team's version of "on track." After, one map, one forecast — dependencies named at planning, not explained after a slip. Same product, same teams. Just nothing left hidden in a backlog until it was too late to plan around.

✓One map, built live by the people who'd execute it — not handed down
✓Epics traced to iteration-level ownership across 10+ teams in a single planning cycle
✓Every quarter shipped as one complete user journey, forecast on real capacity and real dependencies

Evidence Wall

Formats spanning the full retrospective arc, plus planning and training.

A sample, not the whole library. Each format is a lever, not a ritual — chosen for the specific outcome a team or a stakeholder group needed at that moment.

Set the Stage

Weather Map

One placement, sun to storm, before a single word gets said in the retro. Fast, honest, and hard to fake.

✓Surfaced concerns that hadn't been voiced during stand-ups, allowing the team to address issues before they affected delivery.
✓Helped quieter team members contribute early, resulting in more balanced participation throughout the retrospective.

Gather Data & Generate Insights

Gather Data

Team Health Radar

Five axes — Collaboration, Trust, Accountability, Process, Product. Scored live, discussed one at a time. Vague sentiment becomes something the team can actually act on.

✓Surfaced trust issues between Product and Engineering that became the basis for three sprint improvements.
✓Created a measurable baseline that teams revisited over successive retrospectives to monitor improvement.

Gather Data

Repeat / Avoid / Add

A matrix across People, Process, and Technology — what to keep doing, what to stop, what to start. Structures the conversation by category instead of letting it turn into a general complaint session.

✓Forced every issue raised to land on a verdict — repeat it, avoid it, or add it — nothing left as just "noted."
✓Every category walked out with its own action list, not a wall of sticky notes nobody revisits.

$Sailboat retrospective format board$ Gather Data

Sailboat

Anchors for what's dragging the team down, wind and sail for what's pushing it forward — a spatial metaphor that makes structural blockers as visible as the things going well.

✓Surfaced what the team was anchored by and what was propelling it forward.
✓Turned named anchors into actions that helped the team sail faster.

Closure

Retro Dart

A target-board format for prioritizing what matters most out of the session — the closer an item sits to centre, the higher the team ranks it for action.

✓Forced the team to rank, not just list, what mattered most.
✓Set a clean cutoff for what actually made it into next sprint's actions.

Thank You and My Action retrospective format board

Closure

Thank You & My Action

Closes the retro on two things: acknowledgment of teammates by name, and one personal commitment each person owns going into the next sprint.

✓Made recognition a habit, not something left to chance.
✓Every one goes into the next sprint with one thing they'd personally committed to.

Planning & Prioritization

Planning

Value / Effort Quadrant

A four-box prioritization exercise — the team plots its own backlog by value against effort, then agrees live on what to attack first, what to schedule, what to ignore. Makes prioritization a team decision instead of a PO call.

✓Helped Product Owners and stakeholders reach prioritization decisions faster by creating a shared view of value versus effort.
✓Shifted discussions from opinion-based debates to collaborative prioritization, resulting in greater alignment before sprint planning.

Training

The Ball Point Game

A live production simulation — five timed iterations, a plan and a retro between each one — used to teach self-organization and iterative flow from the inside rather than off a slide.

✓Left the team with a lived experience of a fast feedback loop, not a diagram of one.
✓After the simulation, the team voluntarily reduced WIP limits and completed the next sprint with fewer carry-overs.

Also in the Toolkit

Stars & Tweets, 4L's, 5 F's, Marginal Gains, Wall — Experiments & Learnings, Build Your Own Scrum, Roles & Values card deck, a physical Sprint Board, and video debriefs — Nordstrom Innovation Lab, Ideo and mob programming and many others in action — all documented.

The Depth Behind the Breadth

One retro, followed through.

Most of this document is breadth — formats, techniques, evidence across many teams. This part is depth: one retrospective, one team, and what actually happened after.

redBus B2C Platform

The Jeep Retro

On a Friday, the redBus B2C platform went down. A payment glitch, four hours of downtime, engineering fixed it. The following week, we ran the retrospective — not a post-mortem, a full team retro, roughly 15 engineers and the product manager, product and engineering in the same room.

4 hrs

Downtime that triggered it

1 video

One question, no answer given

40%

Of the monolith migrated in 3 months

The Intervention

I opened with a four-minute video of Canadian army soldiers dismantling and reassembling a jeep in field conditions. I asked one question: why do the military use jeeps, despite having budgets for anything they want? Early answers came fast — cost, simplicity, availability in remote terrain. Then someone said it: minimal architecture, designed so anyone can fix it, anywhere, fast. No specialist required. I didn't say anything. I let it land, then asked the team to correlate it to their own system.

How the Team Got There

That's when it shifted. Why had the payment fix taken so long? We kept asking why. The answer that came back, from the team, not from me: monolith. When something broke, nobody could isolate where. The whole system had to be touched to fix one part. The action item — move to microservices — was theirs. I hadn't proposed architecture. I'd shown them a jeep.

What Happened Next

The payment and booking critical path — the highest-risk zone — migrated first, within three months, covering roughly 40% of the monolith. That 40% wasn't chosen for ease; it was the highest-traffic, highest-revenue-risk path, the one where the next payment glitch would hurt most. What changed in the room mattered as much as the migration: engineers and product manager who'd been talking past each other for months left that retro having solved something together.

What it didn't fix: the remaining 60% of the monolith stayed as-is — migrating it wasn't worth the risk against lower-traffic paths, and I said so at the time. Not every insight from a retro should turn into a roadmap item; part of the job is knowing which ones shouldn't.

"I never told them the answer. I just made it impossible to miss."

For Leadership

✓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: prioritization and stakeholder alignment closed in structured sessions, not chased over weeks of email.
✓Proven at scale: a monolith stuck for years got a migration plan from one retrospective — the highest-revenue-risk 40% delivered in 1 quarter.

Make it visible, and it holds everyone to it.

Make it a game, and a team stops being told what to think.

Built and run at scale, for thirteen years.