The most important foundations of high performing Scrum teams is not fun, trust, common values and all soft-skills, but hard engineering skills. Developers are problem solvers. The code is a solution for a given problem or customer business need. We could add one more statement to the Agile Manifesto:

“Developers’ skills are more important than number of developers”

10x developers

There is a popular theory in software development world, that the best developers are 10 times better than bad developers. This theory is supported by studies and data. In 1968 Sackman, Erikson, and Grant conducted research and found that ratio of solving problems between the best and worst programmers was about 20 to 1. The ratio of debugging times was over 25 to 1. Program size ratio was 5 to 1 and program execution speed difference was about 10 to 1. Comparing to the salary ranges it seems that having a few very good developers makes more sense than having a large group of moderate or poor programmers. Additional benefit is the fact that limited number of people working on the solution significantly reduces the complexity of the product and an organization.

Misunderstanding of efficiency measurement

One of the reasons why organizations still put more attention to number of developers than their skills is that it’s so hard to measure a programmer’s efficiency. Ability to measure developers’ productivity still lure managers. If what we said about “10x developers” is true, the temptation of measuring people’s efficiency is even higher. There are plenty of very bad metrics like: hours at work, lines of code written (SLOC), bugs closed (sic!), story points (ups!). Those metrics are bad and drive bad behaviours. Albert Einstein said:

“Not everything that can be counted counts, and not everything that counts can be counted.”

Lack of skills leads to poor products, higher code complexity, bigger teams (higher organization complexity) and demotivation. On the other hand skilled programmers build a company culture which attracts good programmers, so it’s a positive feedback loop which helps to recruit the right people.

If the most successful companies and scholars did not find a good metrics for developers’ productivity, than I’m convinced that the average company cannot find it either. It’s hard to measure individual skills, but it’s much easier to invest in skills.

Do not measure, but invest in skills

Knowing all of that, it’s better to focus on engineering culture, recruitment process and continuous skills building. Companies need to look for the people whose skills fit to the organization. There are couple of good practices which you can use. First, include team members in the recruitment process. Team can better assess if the new person fits to the team. Second, candidates should be thrown into the real life cases. Why not having a one hour of pair programming with somebody from the team, rather than spending an hour on reading a CV.

If you succeed with the recruitment process and have a good people on board give them a space for learning.

“I have no time to learn”

I can hear that statement in many organizations. You need to create space for developers to upskill and “sharpen the saw”, but the important thing is that increasing skills is primarily a personal responsibility. Leaders can support those individual efforts by mentoring, coaching or training, but it’s one of the most healthy expectations from the leader:

“I expect you will never stop learning” 

ScrumTale reflections

Motivation to write this article was an observation from our ScrumTale workshops. Writing skills are among the most crucial success factors, which are required to write the best crime stories. Teams who have people who write with flair usually deliver a crime story which is just great.

Photo source: https://www.flickr.com/photos/timevanson/8502199860 (Creative Commons BY-SA 2.0)