In the agile world, Scrum has established itself as one of the most popular frameworks for helping teams work efficiently* and flexibly on complex projects. Most people think of teams with 5-9 members. The Scrum guide mentions, that the team must be 10 or less people. But what happens when you apply these proven principles to much smaller teams? In this blog post, I will explore how Scrum functions in teams with only 1-3 members and what adjustments are necessary to fully harness the potential of this method.
*With efficiently it is meant, that you efficiently look for the right path, the right product, the right process – whatever you'd like to change and discover.
According to the official guidelines, the optimal size of a Scrum team is 10 or less. However, many believe that 8 is the ideal number. It is thought to have the full capacity while maintaining a balance of interaction. Only, that it is also considered to be a number representing a team just shortly before team-split. Based on Dunbar’s number, which suggests that a person can effectively maintain only about five close social relationships before experiencing a loss of mental capacity, 8 seems to be pretty big. And let's do not start with teams beyond 10, only that I have witnessed massive psychological insecurities and no belonging that decreases the motivation and personal performance. With more interactions we have we will have a higher effort to align all team members. It's still possible, but about that I write at another time.
This raises the question of how well Scrum works with teams of just 1-3 members. Can the principles developed for larger teams be effectively applied in this smaller context?
Yes, we can!
We just need to understand Scrum as what it is: A framework that is fundamentally based on empiricism!
What is Scrum? What is agile? What is the Agile Methodology? What is empiricism?
And where does it all come from?
Agile is not a new invention. Agilist can name plenty of agile frameworks that work similar or the same way as Scrum.
Agile is often mistaken for "doing things faster" and people believe, their waterfall roadmap broken down in pieces are called iterations and therefore agile is a false believe, too.
Iterations in agility is meant by: "We learn from our step, see if it has worked and go a step back to try a different thing for the same goal and see if it works better." Why is this method working faster? As you learn early, you can adapt early. A waterfall project, broken down into pieces, where the organisation only learns at the end of the entire roadmap is not agile and doesn't learn early, will be very much slow as it sounds.
Fail as early as possible!
Inspect and adapt!
Look at the red graph. Now take out a seemingly very big item from your backlog: Can you size it for me with 100% precision? Take out a seemingly smaller item. The smallest you have. How certain are you about this sizing? When is it done?
Like the weather forecast, the more we try to predict further into the future, the less precise is our prediction. This is also true for every AI aiming to predict the future.
With small teams, you certainly have no time, recourses and energy to do a full-blown project from beginning to the end, only to figure out, that you projects is a failure. You need to use your energy and time wisely to create the most value and the most knowledge.
This is why you have iterations, to check what the product is doing (not what the team is doing – I mean, a small team definitely knows if someone is lacking behind.)
So, let's assume you are an organisation focussing on the product and not on the roadmap (that will change weekly – so don't try), let's turn the cone of uncertainty around and name it cone of certainty.
You are using Scrum, and you have your Sprint Planning, inviting the team to create a Sprint goal. The Scrum Guide says, that the Sprint only has one Sprint goal – Not a collection of features to be finished.
And here comes the first hack to create the right understanding of what a Sprint goal should look like:
Since Scrum is fundamentally based on empiricism, your Sprint Goal shall look and sound like a hypothesis. A hypothesis is something you can verify or falsify
A Sprint goal is only then a good sprint goal, if you if you can verify or falsify the goal.
The aim is NOT a set of items (that is waterfall), it is the acquisition of knowledge.
An example:
Hypothesis:
With this set of features, we are enabling the customer to pay faster and easier.
How to measure:
You notice, that these are KPIs aiming for a standardised set of data of a bigger crowd. This is a nomothetical, approach covering the quantity. But let's also look how this feature is appearing to the user:
The opposite of nomothetical measurements is the ideographical one. You ask the customer about their opinion: How it feels, what steps they took, how easy or difficult they found it. With user interviews you can cover the ideographical measurements and get quality of the results.
Aiming for knowledge is crucial for small teams as you want to know things as early as possible.
Scrum is working in the complex environment – Meaning: At the end of a Sprint, you don't know if your Sprint will be successful or not.
But what you know is that every acquisition of knowledge is a win as you will inspect and adapt and finally find the right path to the right product. This is also true if you know your product market fit and aim for adapting internal processes. Use the same principals.
When I talk about a small team, I don't mean a small backend development team that consists of backend people only. You want to aim for knowledge quickly and how can you do that, of you have external dependencies?
What I mean is a cross-functional team. Also this is mentioned in the Scrum guide. A Scrum team is a cross-functional team.
Wait, does it mean, I have to have a frontend developer, a backend developer and cloud developer in one team? It could be. But let's go a step further, because this is becoming really cool, of we go outside of out imaginary boarders.
A cross-functional team can consist of: Literally anyone of any department, who is required to accompany a hypothesis from the start to the end of it's cycle.
Most organisations are build in knowledge silos. You have a set of experts here, and a set of experts there. But a team of 3 can not forge a 1-man team department here and one here and one there.
The experience I have made with people from design, legal, research, social media marketing is truly an eye-opening experience.
Yes, when you are the only developer, you will eventually end up developing everything on your own, as legal will draft every legal paper on their own, and research do all the research on their own. But in the Scrum events, all of them come together and discuss:
What is it, that we learned in the last Sprint and what is the biggest value, we can create during the next Sprint?
And this is another hack, I'd like to mention. This is not for teams who like or require structure and are starting out in Scrum. The Scrum guide doesn't tell you to fill the Sprint until the bucket is full. Sizing is useless when aiming for knowledge. All you need is a good gut feeling, if you think you might have some knowledge at the end of the Sprint.
And in order to counter-act the believe that a Sprint needs to filled like a full bucket, I tell teams to only define the Sprint goal and then we start the sprint without filling any items in it.
Try it out: People will be tremendously irritated at first, but eventually will get their confidence in aiming for the Sprint goal's knowledge in a self-organized way.
The Scrum guide doesn't tell you to fill the Sprint, but it also doesn't tell you, that team members are not allowed to create items themselves. Any team member is enabled to do so. Here you would like to look at the values: Commitment, Focus, Openness, Respect, and Courage. You commitment and focus is towards the Sprint goal, you are open and courageous to figure out how to get their self-organised and you respect your team members so that they are enabled to do the same.
Let's also look into the pillars of Scrum: Transparency, Inspection, Adaption
What you would like to do, is to create transparency. Inform the team members and let them tell you what they think about your idea.
This creates the highest amount of flexibility.
Those teams definitely should start with a set of items discussed in the Sprint planning, as the Scrum guide suggest. This will enable you and your team to check what level of deep collaboration you need.
And speaking of working mode –
Working in a very small team requires a set of soft skills. because the less team members you have the more you rely on the individual.
Scrum as an agile framework in its principles is not a new idea. We have many adaptions. You may know Lean and XP, but also Design Thinking that aim for the same empiricism and knowledge. This way of working is beneficial for every start up just starting out, but also for every team in a corporate aiming to improve their products and processes.
Please, feel inspired and try some of the approaches out and let me know what you think!
