Person before skill
Considerations for building up a great Scrum team
You can provide the best equipment, pay the highest salaries, have the best (trained) people and still, the output of your team is bad. On the other hand, you can do magic with mediocre tools and new starters. The success of your team is majorly a result of the team itself.
Independent from whether you start from scratch or already partially have a team, whether you’re in a startup or a significantly big company, there are some considerations I found useful when working with or building up teams.
This article and its examples mainly focus on Scrum teams in software development and building a development team. When it comes to application in other areas, YMMV.
Define the product, limit the scope
Similar like for a sprint, define the product you’re about to build. This might sound strange but it helps looking for the right people in your team.
If you’re a single team in a startup, a clear product vision helps focussing on the right content and also to look for the right persons. Do you need specialists or allrounders? Does it make sense to hire someone for a highly specialised but seldomly required activity?
In larger organisations, this applies as well: independent from whether your organisation works with feature or component teams, a clear and defined scope helps building the team.
Too much, too little
Imagine you have a specialist on a certain topic, e.g. a very specialised technology, a rarely used programming language, but also non-technical areas. When working with Scrum, your team has the challenge to always have to find something for that specialist. Also, if there are more topics in the domain, the specialist is on his own.
If your product is too big, you might end up with a highly diverse team. Imagine you have an embedded product along with a web page and a mobile app. While you can argue that a customer value is only created when a feature is implemented throughout the whole stack, the technological diversity is extremely high — and even higher if you include hardware development. So your team gets big, you have to consider backup and different workloads in different areas throughout different sprints. And all the time, there’s the challenge to have stories involving everyone. While this can work, it has significant inefficiencies.
Split and consult
There are many ways on how this can be addressed. In short, when building up a team, define a scope for the team which allows to create customer value while limiting the diversity in the knowledge and technologies required for it.
When a special skill is required, you can always pull it in — either to consult for several days or to extend the team for a certain time. This can be external but also company-internal from another team. Just don’t be too strict on the team boundaries.
Size doesn’t matter
Many fall for the trap that adding more people to a team increases output. I personally found the opposite working better. Usually a size of 3 to 9 people is recommended.
When going for larger teams, group dynamics like the diffusion of responsibility become more present, meetings are getting longer with less active participants, and so forth. Smaller teams avoid many of these dynamics or inefficiencies.
Dealing with too much work
When the backlog increases and there’s nothing to crumble, instead of increasing your team I suggest to split it, e.g. by implement two independent feature teams in a LeSS setup, each creating customer value. A nice side effect is that such a setup usually requires shared code ownership and a good test coverage with CI/CD .
Hire people, not skills
Don’t go for specialists
So it’s 2019, you’re building an iOS app and looking for someone with >10 years experience in Swift? Good luck :-) You probably won’t find an exact match for the technologies you’re using. You also probably won’t find a person with the experience you envisioned. Frankly, I see this as a plus.
Specialists are not ideal in a Scrum team. Instead, you want to have team members which can work in multiple areas of the tech stack. This also requires a willingness to learn and to grow beyond a team member’s home base. Such a team can deal with different workloads in different technical areas, vacations, sickness, changing team members, … .
Go for the mix
“Great minds think alike, though fools seldom differ.”
A homogeneous team in experience, technology, mindset, … can be pretty harmonic, but is has some other disadvantages. A mixed team can expand the horizon of every team member and thereby lead to better products. Some examples on mixes:
- different level of experiences: old-stagers with newbies
- different backgrounds: embedded programming and frontend
- different mindsets and personalities: early and late adaptors, pragmatism vs. perfectionism
Given a good communication culture, the team takes influences from all of these to build great products.
Don’t hire because you can hire
You have a budget, an opening, a headcount or whatever it is called and you struggle to find the right person. Then don’t hire at all!!
The team has to benefit from every person that is added to it. If the skillset or mindset doesn’t fit, it will have negative impact.
Does the person push the team or pull it back? Does the person fit to the mission of the team by e.g. helping value creation, sustainability or creativity? Does your team require pragmatism or perfection?
To give an example: a developer profound in creating quick prototypes might not be the best fit for a health device while a developer driving for perfection in every code path might not be beneficial for a team striving for a 2-week release cycle.
Fire your best employee
Wait, what? No worries, the following article explains it pretty well:
Your building a Scrum team, not a one-person-team-with-satellites. A Scrum team works together towards a common goal. If a team member is working against the team, this is more destructive than any loss of expertise.
Let the development team hire
Do you have an HR department doing the hiring completely for the team? Is the team/SM/PO majorly involved in it? Especially in larger organisations, major parts of this are handled by a HR department. I had very good experiences though to pull more of that responsibility to the team.
Next to classical interviews, some coding exercises together with the team have shown their value to us. Working with some team members on samples in the same environment as the product allows us to judge whether the skills are adequate. But even more important, we could see how the person deals with feedback and criticism and whether the team sees the person fit.
Trust in the development team’s capability to assess new team members. Let them have the last call on this. In the end, they spend more than 8 hours/day together, so it has to be a fit.
You get what you pay for
This might sound like it contradicts what I wrote initially, but it actually doesn’t :-)
Salary can be a sensitive topic, but in the end, it’s not a motivator, but a hygiene factor.
Having that in mind, I learned not to negotiate salary: either it fits the skills, the experience and the team’s salaries or I decline. If it’s lower, we make it fit though :-)
The idea is that any negotiation will have a negative motivational impact. There might be some misjudgements on market level or so, so this can be brought up. But usually good people tend to judge their value quite accurately.
Another effect that has to be taken into account: salaries within a team should be fitting. I find it hard to argue when a similar skillset, experience and level of contribution results in a significantly different salary.
Startups usually have a tighter budget, but there are other means of compensation. I encourage transparency: if an applicant is aware of the situation, a lower salary is usually judged differently.
Summary
The team makes a big difference in Scrum. The team you’re about to build should be very close to each other, and similar to accepting someone new as close friend, integrating a new team member is a very important step which has to be accepted by everyone involved.
The most waking hours of a day the Scrum team members spend with their peers, so it’s just not only the persons skills that matter. It’s so much more.
