Home → Scrum

Does Scrum Make Customers Happy?

Short answer: Scrum alone does not. Scrum that brings the customer inside does. I learned the difference the hard way, over four years, on a defence industry project.

Sertaç Yıldırım · 7 September 2026 · 10 min read

How it started: one person, one project, monthly meetings

I started with a single software project at one of Turkey's leading defence industry companies. The team: me. On the customer side: a technical lead and a handful of users behind them. The working rhythm was the classic one — a monthly status meeting and email in between.

What happened at the first delivery was equally classic. I showed the screen, they looked at it for a few seconds, and said:

Nothing was broken. What I built matched what had been discussed exactly. The problem was that what had been discussed was not the work they actually did. They only noticed the gap when they saw the screen — and it had taken us six weeks to get there.

The bill for that day was two weeks of rework. What I really lost was something else: in their eyes I had become "the developer who does not understand". Once you wear that label, every meeting is spent defending yourself.

The one thing I changed

No process document, no methodology presentation. I said one thing:

In defence there is a confidentiality dimension too: screen sharing, environment access, who is allowed to see what. We settled that up front — the demo ran on a machine on their own network, with representative data instead of real data. That detail matters, because "security does not allow it" is the easiest excuse for keeping customers out, and it is usually a solvable problem.

The first three meetings

• First: Silence. Nobody said anything except "looks good". Expected; nobody criticises on the first try.
• Second: The technical lead pointed at a field on screen: "we do not type this in, it comes over the radio from the field." That is exactly the sentence I would only have heard at delivery under the old setup. It was fixed within a sprint.
• Third: Two more people showed up. I had not invited them. Their colleagues had told them about it.

Those two extra people are the turning point of the whole story. From that moment the meeting stopped being a place where I got approval and became a place where they discussed their own work.

What happened next: the requests started

Around month six something unexpected happened. Someone in the meeting asked: "Since you can do this, could you do the same for our other form?"

That sentence did not come out of a sales meeting. It came from a person using a screen I had built, wanting to make their own job easier. That is how the second project started. And the third.

Four years later the picture was this:

The last row is the important one. For none of those nine projects did I prepare a deck and ask for work. All of them came because the people using the product advocated for us inside their own company. A customer who owns the product is your best salesperson — and they do not charge.

Why it works: four mechanisms

1. Misunderstandings surface in two weeks

The best known benefit. "This is not how we do it" learned after six weeks is a disaster; learned after two weeks it is a correction. The cost is a tenth.

2. Contribution creates ownership

People value disproportionately what they helped create. A user who says "put that field on the right" and sees it on the right two weeks later becomes part of that screen. The person who takes the critic's seat at delivery does so precisely because they were kept outside the process.

3. The customer becomes your advocate

I had not planned for this one; I noticed it later. When a project's budget is discussed in a meeting room, you are not there. Someone either speaks for you or nobody does. A user who owns the product speaks for you in that room.

4. The team sees the result of its work

This is the least discussed of the four and the one I value most. On the way from one person to fourteen we did this: a different developer ran the demo every sprint. Not me.

The first time, everyone was nervous. After the second, people started queueing up. The reason is simple: opening the screen you built in front of the person who will use it and hearing "this is exactly what we wanted" first-hand gives you something no bonus scheme can.

And the real point: energy comes from the leader

Everything above looks like technique: meeting cadence, live screens, demo rotation. But one thing holds it all together, and it is not technical.

There was a period when work got heavy and I went into two reviews unprepared. "Let me just show this quickly," and moved on. In the third review, one of the team rushed the demo the same way. I did not say anything, because I had no standing to: I had taught them that behaviour.

A team's attitude towards a meeting is a copy of yours. That is neither good news nor bad news, just a fact. What it looks like in practice:

None of these is charisma. All of them are repeatable behaviours. And all of them are done every sprint — not once and then forgotten.

How do you set this up?

1. Start with one person. Do not try to convince the whole customer. Find the one curious person who actually uses the thing and invite them to every review.
2. Drop the slides, hand over the keyboard. The difference between telling and letting them try is the whole point of this post.
3. Show the output of the last meeting. "You said this last time, here it is." That sentence is the one thing that guarantees attendance.
4. Say what you will not do, too. "We are not doing this, and here is why" builds trust; quietly swallowing it destroys trust.
5. Rotate the demo. A different developer each sprint — for the team, and so the customer recognises more faces.
6. Deliver bad news early. Early bad news is a risk to manage; bad news on the last day is a failure.

The three numbers I tracked

Checklist

Conclusion

The answer to "does Scrum make customers happy" is not in the ceremonies. Customers become happy when they see the thing they asked for appear on screen two weeks later. That is not a methodology benefit but a relationship benefit; Scrum just reserves a regular slot for it.

And what keeps that slot alive is the leader. If you do not believe in that meeting, nobody will. Nine projects and a team of fourteen were not the result of a methodology, but of a habit repeated every two weeks.