What I Found When I Joined a Team That Had Never Heard of a Sprint

When I joined MoveUp Media in October 2024, the technology team was two people. There was no sprint. No backlog. No way to know, at any given moment, how many things were being worked on, by whom, or in what order.

This isn't unusual. Most small tech teams reach a certain scale — usually around the point where two people can no longer keep everything in their heads — before anyone asks whether there's a better way to work. At MoveUp, that moment had arrived.

What followed was the most instructive Agile implementation I've done — not because the team was resistant or the context was unusual, but because starting from zero forces you to understand what Agile practices are actually for, rather than which ones appear in the Scrum Guide.

Week One: Mapping the Actual State

Before proposing anything, I spent the first week just watching and asking questions.

How did work get assigned? (A conversation, usually.) How did stakeholders request things? (Email, Slack, sometimes a hallway catch-up on a call.) How did the team know something was done? (When the person who built it said so.) How was support handled? (Whoever noticed it first picked it up.)

The team wasn't undisciplined — they were operating exactly as two talented people with good intentions and no system tend to operate. Priorities were implicit. Work was visible only to the person doing it. There was no distinction between "we're working on this" and "this is in a queue somewhere" and "this was requested but nobody has looked at it yet."

The first thing I did was make the invisible visible. Not by introducing a tool — by building a shared list of everything that was actively being worked on or waiting to be worked on, in one place, in a format both people could see and update. That alone changed the texture of our conversations within two weeks.

What I Built, and Why

The framework I introduced was Scrum for delivery cadence and Kanban for ongoing support and maintenance work. I want to explain the reasoning, because "we use Scrum and Kanban" is almost meaningless without the context of why those choices were made.

Scrum for delivery because the team was being asked to manage a growing portfolio of development initiatives alongside ongoing operational work. Sprints create a forcing function: you have to decide, before the sprint starts, what you're actually committing to. That decision — made explicitly, in advance — is where alignment between technical capacity and business expectations either happens or doesn't. Without it, every week becomes a negotiation.

Kanban for support because support work doesn't batch cleanly into two-week cycles. A site goes down on a Thursday. A client reports a bug on a Sunday. Trying to sprint-plan support work creates the illusion of structure while the reality is still reactive. Kanban gave us a visual flow of open issues, WIP limits to prevent overload, and explicit escalation paths for critical items.

The two systems run in parallel and feed each other. Support tickets that reveal systemic problems get escalated into the sprint backlog as development work. Sprint deliverables that introduce regressions feed back into the support board.

The Measurement Problem

One thing I had to establish before any improvement could be meaningfully measured: there was no measurement. Not because the team was careless — because there was no system to measure.

The first operational data we had on support volume, response times, and resolution rates came from the infrastructure I built after I arrived. This is worth noting because it's common for teams to resist process investment with "we don't have a problem" — and the honest answer is often "you don't know whether you have a problem."

What we found when we started measuring:

• Approximately 20 support tickets per week arriving through multiple channels • Average first-response time of around 1 day • Average time-to-resolution of around 3 days • No visibility into whether individual tickets were actually resolved or just forgotten

Over the following months, through the combination of better processes, more intentional UI/UX decisions, and performance work I coordinated:

• Ticket volume dropped to approximately 4 per week — an 80% reduction • First-response time fell to 30 minutes — a 96% reduction • Time-to-resolution fell to 1 day — a 67% reduction • Lighthouse performance scores improved by 80% across the portfolio

I'm not listing these as achievements of the Agile framework specifically. Better process didn't make the bugs disappear — better engineering decisions and performance work did that. What the process did was create the conditions for those decisions to be made intentionally rather than reactively, and create the measurement infrastructure that showed us where to focus.

The Part That Took Longest

The hardest part of this implementation wasn't the framework. It was building the habit of explicit commitment.

In a team that's operated informally, the word "yes" means something different than it does in a team with a sprint board. Informal yes means "I understand this is wanted." Sprint yes means "I am committing to deliver this in this window, and if that's not going to happen, I'll raise it before the sprint ends, not after."

That shift — from implicit to explicit, from vague to committed — is where most Agile implementations break down. Not because people are being evasive, but because explicit commitment creates accountability, and accountability requires trust. You have to trust that saying "I can't get to this in this sprint" will be received as useful information rather than failure.

Building that trust is the actual work of an Agile implementation. Everything else — the board, the ceremonies, the velocity tracking — is scaffolding around it.

What I'd Tell Someone Starting This From Scratch

A few things I know now that I wish I'd been clearer about on day one:

Measure before you change anything. Even rough baseline data — ticket volume, how long things take, how many things are in flight simultaneously — makes the case for change visible to everyone, not just the PM who can feel the chaos.

Don't introduce everything at once. We started with a shared backlog and a one-week cadence. We added ceremonies incrementally as the team built comfort with the basic practices. An 18-item Scrum implementation on day one would have been overwhelming and quickly abandoned.

The tool is the last decision, not the first. We ran our first sprints in a simple spreadsheet. Moving to Jira came later, when the discipline was established and the tool was serving the practice rather than defining it.

The goal is predictability, not speed. Teams that are new to sprinting often expect to go faster. That's not the point. The point is to know, with confidence, what will be done and when — which is a different and more valuable outcome than moving fast without visibility.