Work around the Hiring Struggle
Left and right I am hearing people mention how much trouble it is to hire right now. There is a huge focus on hiring. Let's take a step back and look at what the real goal of running a software team is. The goal goal for many is to deliver more & faster to beat the competition. Hiring is only one part of the equation. A 40% increase in team speed may seem unrealistic to some but bear with me. Let's first look at a 40% increase and we find a team can deliver in 4 weeks instead of 6 weeks for 260 units of work. That is no laughing matter but let's dig deeper
Let's say that you currently have a team of 20 developers. Increasing speed by 10% is 2 less full-time developers that you need to hire (A value of approximately $260,000). This effectively means 20 developers is doing the work of 22 developers. Here is some simple math
Team 1: 20 Developers working at 40 points per iteration
Team 2: 20 Developers working at 44 points per iteration (10% increase)
Team 1 is roughly 2 points per developer per iteration ( 40 points / 20 developers ). If you add 2 Developers who also contribute 2 points per iteration, you get team 3
Team 3: 22 Developers working at 44 points per iteration
Team 3 is the same speed as Team 2 and costs $260,000 more. Realistically, team 3 actually costs more money due to more lines of communication going on. This is why we focus and help customers increase team speed by 10-50%. Even in the margins, a 10% increase on 2 Developers can be 260,000 in savings.
Unfortunately, I have been a developer for many years, and most software developers are trained to deliver, deliver, deliver. They actually never have time to measure team speed, improve team speed, iterate and learn how to make team's fast. Software Developers concentration and expertise is in learning new technologies. They thrive in this space. If you take a software developer and have them focus on team speed, it is years before they gain the correct experiences and toolsets necessary. There are many things that contribute to team speed that I did not discover until 10 years into my career. While other software developers were off learning new technologies, I could not help but constantly study developer speed and team speed.
Scrum Masters have skills in the other direction around project management. Their expertise concentrates mostly around raising red flags, tracking the schedule and deliveries. They do not help teams with things like where time is spent. It is almost like we need a new role in software, one of increasing software engineering teams' productivity.
Individual Productivity and team productivity is my passion. Reach out on linked-in and I will be happy to give you some tips.