Scrum in an SME,who holds the roles when the team is small

Someone suggests moving to Scrum, and you look at your team: four people, one of whom also answers customers and another who does support on Fridays. Scrum in an SME: does it hold up when nobody has just one job?

I am a certified Scrum Master and Product Owner, with a limit I would rather state straight away: I work alone, and I have no transformation figures to show you. What I can show you are the Scrum mechanisms I kept in my own tools, and what I look at before saying yes. Here you will find what you need to decide whether the method suits you, who can hold the roles, and how to run a first two-week sprint without reorganising the company.

01What the Scrum Guide asks for, and what it leaves open

The Scrum Guide is short and free, and I would read it before any training course. It asks for few things, but it asks firmly:

• a team with one Scrum Master, one Product Owner and Developers, typically 10 people or fewer;
• Sprints of a fixed length, one month at most;
• a Sprint Goal, a 15-minute Daily, a review and a retrospective;
• a Definition of Done that everyone follows.

The rest is up to you: the tool, the format of the Daily, how you estimate. The Guide mentions neither story points nor software. It talks about accountabilities, and I do not read that as an obligation to create three jobs.

It is also very clear on one point: you can apply part of Scrum, but the result is no longer Scrum. I do not take that as a reproach. If you keep two practices that help you, keep them, and call them something else. You will avoid concluding that "Scrum doesn't work" after a trial that wasn't one.

The word SME needs a caveat too. For Insee, the French statistics office, an SME employs fewer than 250 people, and that includes micro-businesses with fewer than 10. A company of 200 and a company of 6 do not have the same problem. The Guide thinks in teams: the right question is about the team that would run the Sprint, not the size of the company.

02Three questions to ask before the first sprint

Can your work wait two weeks?

A Sprint assumes you protect a list of work for its whole length. If half your days go on customer emergencies, the Sprint will be fiction by Tuesday. Nielsen Norman Group interviewed eight professionals working in Agile, and one complaint boils down to this: requests arriving outside the process break the planning (Doing UX in an Agile World). The sample is small and the article dates from 2014, but I recognise that complaint.

Can one person make the call?

The Guide says it in a few words: the Product Owner is one person, not a committee. In an SME, the risk often looks like this: the founder, the salesperson and the technical lead each set priorities on their own. Until someone can say no to the other two, the backlog is only a wish list.

Will management agree to stop interrupting?

Christiaan Verwijs and Daniel Russo validated a model on about 5,000 developers and 2,000 Scrum teams, and management support is among its five main effectiveness factors, alongside responsiveness, stakeholder concern, continuous improvement and team autonomy (A Theory of Scrum Team Effectiveness). The study is not specifically about SMEs, and I read the abstract. I take one practical consequence from it: if the person running the company keeps calling a developer directly for "a small thing", the rest will not hold.

03Holding the roles in a small team

The Product Owner

You need someone available, who knows the customers and really has the right to decide. The founder fits if they answer questions the same day. If they are in meetings all week, the team will wait, or decide without them.

The hardest part of this role comes down to one word. Henrik Kniberg gives a simple example in Agile Product Ownership in a Nutshell: stakeholders ask for ten items a week from a team that delivers four to six, and the queue keeps growing. Kniberg sees only one way out, the word "no", presented as the most important word for a Product Owner. The video also explains that capacity is simple to measure, by counting what comes out each week.

The Scrum Master

In a team of five, nobody will spend their whole week on this, and the Guide does not make that a condition. A team member can hold it alongside their own work. The Guide also provides for the Scrum Master and the Product Owner to take part as Developers if they work on the Sprint. One of the people Nielsen Norman Group interviewed sums up the minimum well: a dedicated Scrum Master if you can, otherwise clear roles.

What follows is my opinion, and the Guide does not require it: I would not give both roles to the same person. One pushes to bring work in, the other protects the Sprint. A single person will lose that argument against themselves.

The Developers

The word often puts people off outside engineering. The Guide uses it for anyone committed to creating part of what is delivered, so design or content too if the delivery depends on them. Design has a known difficulty: the people Nielsen Norman Group interviewed advise staying at least one step ahead of the Sprint. I happily use a clickable prototype for that.

04The Definition of Done, the part I keep everywhere

This is the mechanism I reuse even when I am not doing Scrum. In the Guide, an item that does not meet the Definition of Done cannot be presented at the review and goes back to the backlog.

I built my content machine on the same idea. An article is only done if an automatic check finds no red, the image has been looked at, the English version exists and the public page has been verified. Three other things resemble Scrum: a calendar that acts as a backlog, a lock that allows only one article in progress, and proofreading feedback that becomes written rules rather than corrections by hand.

That does not make it Scrum. I have no team, no Sprint, no review with stakeholders. But doing it, I stopped believing "it's done": I ask for the proof. For your team, a first version can fit in five lines:

• the work is live or deliverable, in the environment the customer sees;
• another person has reviewed or tested it;
• the specification or documentation matches what exists;
• the person who asked for it can see it without having it explained;
• nothing known remains broken.

The third point comes from a mission, on an integration between an ERP and an online shop: the specification moved at almost every meeting, and I versioned it so that everyone was talking about the same document.

05A first two-week sprint

This plan describes what I would do, and it is not an account of a real case. The Guide does not set two weeks; I choose them because a month leaves too much time to be wrong without seeing it.

1. The day before: the Product Owner ranks the work by importance, and the team writes its Definition of Done.
2. Day 1, planning: write the Sprint Goal in one sentence, then choose what contributes to it. The Guide caps this at eight hours for a month; for two weeks, I would aim for far less.
3. Every day: the Daily, 15 minutes, same time and same place. Nielsen Norman Group reports meetings of more than 30 minutes getting closer to 15 with practice, so do not worry if the first ones overrun.
4. During the Sprint: every new request goes through the Product Owner, and the team notes each interruption. A breakdown gets handled at once, the rest waits for the next Sprint.
5. Day 10, the review: show what works to the people who asked for it, without slides.
6. Day 10, the retrospective: choose a single change and write it down as a rule.

After this Sprint, look at two numbers: items finished and interruptions. One Sprint proves nothing. Wait for three or four before talking about capacity.

The Sprint does not replace decisions on budget or schedule either. For those, a monthly report that goes out on its own and a committee that decides have seemed more useful to me than a dashboard nobody reads.

06When I would not recommend it

Scrum has a cost people rarely add up. Over two weeks, the Daily alone takes two and a half hours per person, before planning, the review and the retrospective. In a team of five where everyone also carries something else, that time comes from somewhere.

I would not recommend it in these cases:

• the work is mostly a stream of tickets or support, and a simple board with a limit on items in progress will be more honest;
• the team has one or two people, like mine: a ranked list and a Definition of Done are enough;
• people change from one week to the next, a difficulty Nielsen Norman Group also describes;
• the project is not scoped, and Sprints will take you somewhere fast without knowing where: start by scoping the project;
• nobody has the right to say no.

07Where to start on Monday

If you are still hesitating, do this before buying a course or a tool:

1. Read the whole Scrum Guide.
2. Count the team's interruptions for a week.
3. Ask who decides when two requests conflict, and write down the name.
4. Write your Definition of Done in five lines.
5. If the three questions above have an answer, run a two-week Sprint on a single subject.

If the result does not convince you, you will have lost two weeks and kept a Definition of Done, which is not so bad. If you would like an outside view of your project, the services page says how I work; we can talk about it.