This is the story of a small team of five people in a fintech company. In late summer their manager asked me if I could have a look at how they work. Before I met them, I looked at their data in Lighthouse, and I could sense there was potential.
One session later, the team dropped sprints and started to pull work. Two months after that, we looked at the data together. This post is about what happened, what the numbers say, and what I took away from it.
I’ll be honest with you: what happened with this team almost felt too easy. And that is exactly why I want to write it down as we often tend to overthink when it comes to improve something.
This change did not happen because I did something clever. I didn’t. But it showed me something about teams, about data, and about how little it sometimes takes.
Where they came from
When I first met them, they were working in what I would call “that Scrum process”. You probably know it. At some point the team started with Scrum. They had the events. They had two-week sprints. They had a board. They called it “doing Scrum”.
And on that board there were around 80 items in progress, spread over different columns.
Every two weeks the sprint was closed, and every unfinished item was moved into the next sprint. That was the process.
As with so many teams in organizations, at some point it stopped working. Or, to put it more bluntly, it never really worked. The reasons are the familiar ones, and plenty of blog posts have been written about them. I won’t add another one here.
The session
Their manager didn’t have anything special in mind. It was more of a “can you have a look, together with them?”. So I went on site for a general session: how they work, how they prioritize, and how work moves through their system.
I would love to tell you that I came in with a plan. I didn’t.
The session was more of a Q&A. I asked the team to share openly what currently does not work in their ways of working, and how they deal with it.
What struck me was how they talked about their process. Almost as if it was a given. As if they had no say in it. As if they might not even be allowed to change it.
The picture that came to my mind was a team with chains around their ankles. But the chains were not locked. They could have walked away at any time.
Nobody forced them to keep this process. And yet they opened a new sprint every two weeks, sprint after sprint.
We see this a lot on an individual level in organizations. What matters here is the context: no one had told this team that the process was set in stone.
So what that session mostly achieved was this: giving them back the sense of their freedom. Their freedom to decide. They can rearrange how they work. They don’t have to stick to a specific process.
How did I do that? Mostly by saying it out loud. I told them that nothing is a given. It’s a clean slate. They can experiment with whatever they want, because what matters is that it works for them. Do something only if it makes sense to you. And if something immediately feels wrong, leave it out.
And then there was a moment when it tipped: the team stopped asking me whether they were allowed to do something.
What we agreed on was simple. Work on a pull principle, the Kanban way, without the sprint boxes.
Looking at reality first
The nice thing was that I could show them the data. With Lighthouse I was able to show them what their reality looked like.
And reality didn’t look nice. You could see that it took them a long time to finish items. You could see how much was in progress at the same time. Which was exactly the point. And which they considered painful and hard to work with.
One of the first exercises was one I really like. Take the list of everything that is “in progress” and clean it up. What is really being worked on right now?
I know a lot of teams struggle with this one. And I’m pretty sure the number this team has in progress today is still too high. Not everything on that board is really in progress. That is something for the next months.
The first weeks
Then the work started. And it was interesting to see how quickly things change once the focus is on finishing.
You could see it in the data. But you could also see it in the spirit of the team, from the very beginning.
In one of the first dailies (I was just observing) someone mentioned that they would start a new item. Very quickly, teammates asked what would happen to the other tasks they still had open, and whether it wouldn’t be wiser to close those first.
That’s what I mean. They really cared, and they looked out for each other. Nobody needed a coach in the room to say it.
After a month we had a checkpoint. I first asked how it feels for them right now. They all said something similar: it feels lighter. Less prescriptive. They even mentioned “flow”.
And then we looked at the data together. And the data said the same.
What the data says
These are snippets from the Lighthouse “Then & Now” report for the team. Two windows of 60 days each: Then is 26 June to 24 August 2026, still in sprints. Now is 1 September to 30 October 2026, after the change.
Think about what that means for someone asking the team “when will this be done?”. Before, the honest answer for most items was “somewhere in the next four to five months”. Now it is “very likely within nine days”.
Being completely honest with you
Sixty days is still short. This is the first two months after the change, not the final result.
Throughput went up by about a quarter. The big change is in how long things take, not in how many get done.
Work in progress came down and became a lot more stable. But the items that are still open are, on average, about as old as before, around 100 days. Those are the old ones the clean-up hasn’t reached yet. Which brings us back to my point from above.
The data is a pointer, not the answer. But it gave the team proof that what they changed made a difference. And in my experience that is like a booster.
What I learned
No transformation was necessary. It was one session. Things were put on the table. A lot of listening, to see where the team struggles. And then one new idea.
I know the argument that the team already knows the solution. And I agree, people generally do know it. And still, this team needed a gentle push. A new idea. Someone to point in a direction. From there they were able to go their own way.
For me the main point is learned helplessness. Once you get a team out of it, once they have the audacity to look at where they are and decide where they want to go, it changes what they can do and how they do it. And you can see it in the data.
What it gave the team was a new sense of themselves, almost a new identity. It’s a relatively small team, so there is a lot they can do on their own. And there is still a lot they can improve. New challenges will come. I hope they keep going, even though my part ends here.
So, the short version: not a lot needs to be done. Release them. Then show them the data, so they have the proof that it is worth investing in.
How many teams around you are still wearing chains that were never locked?
P.S. I’m still pretty sure there is too much in progress on that board. But that is a story for another post.