Part 4: Don’t scale with underperforming teams

There is too much to do and too little being delivered. Let’s hire some more people to increase our capacity. After all, the teams have been saying: “We need at least two more developers to keep up.”

This seems to make sense; if you are overwhelmed with work, get some extra hands to help out. However, adding more people to your organization should be the last resort. First, make sure you do the most with what you already have.

In previous articles, we have covered the environment the teams execute within: ”Part 2: Dependencies kill flow” and ”Part 3: Creating organizational focus.” This time, we look at what’s going on inside the teams.

This is important because optimizing your organization, for example, by applying SAFe, LeSS, the Spotify Model, or the most recent Product Operating Model, doesn’t help if the teams themselves have a long way to go in delivering fast with quality. It just adds complexity and bureaucracy to something that doesn’t work well.

Are they underperforming?

It’s excellent that agile has become mainstream over the last 20+ years. Agile has done wonders for how frequently we can ship software. The norm for delivering stuff has shifted from once or twice per year to bi-weekly or even quicker.

But just look at your phone and read the release messages of apps like LinkedIn, Facebook, YouTube, Spotify, or any other prominent app. They’re mostly ”bugfixes and stability improvements”, rarely new features.

So, while the release frequency has increased, most of the team’s efforts seem to be focused on fixing broken things, which wasn’t the idea behind agile.

If you want to know if teams could do better, just ask this: “Do you feel you are working at your peak ability, or do you think that if you changed some things, your motivation, quality, and speed could be improved?”

I have never met a team that says they are even close to their peak ability. Usually, there are some areas that, if improved, the team would be noticeably better in. So, fix some of those issues instead of hiring more people for increased capacity.

Benchmark against yourself

To know that you are improving as a team, you need to measure your progress. We are measuring to see progress, not to get an absolute benchmark against other teams (to avoid gaming the numbers).

As I wrote in “Part 1: Don’t start at the wrong end,” there are three areas to monitor when improving teams and organizations: motivation, quality, and speed.

Motivation (engagement) in a team can be measured by happiness index, employee NPS, or similar. The important thing is that you measure this often (weekly or monthly) and that it requires little effort from the participants. Focus on trends (is motivation going up or down) rather than absolute values.

Actual quality is measured in production. We measure what we expose our users to by counting defects found, incidents that occurred, customer service requests, star ratings in the app store, and anything else where our users let us know how they experience our work. Most organizations already have these numbers, but they are rarely fed back to the development teams in a structured manner.

Speed is measured by lead time, i.e., how long users must wait for a new feature from when we first started talking about it until they can experience it. Bug fixes and stability improvements don’t count (they are necessary evils that prevent us from adding valuable features to our product). When you ship a new feature, just track backward in time to the point when you decided this needed to become part of your product.

Finally, there is one more thing for every team to measure. When I worked for Skype, we called it Evidence of Continuous Improvement. Track the number of improvements the team has completed (or new habits adopted) every month. The size of the number is unimportant; other than that, it should be >0. A high number is not necessarily better, but we do want some evidence that continuous improvement is happening.

You can’t really call yourself a high-performing team if you aren’t measuring. It’s the difference between thinking you are improving and knowing you are. It also demonstrates that small improvements add up over time. This is generally hard to see in the heat of the moment, but it is so rewarding as a team to look back and notice a nice trend. Remember to celebrate with a beer! 

Self-improvement in the team

In my experience, I have found there are a few areas where the majority of development teams can improve:

1. Engineering practices
2. Team composition
3. Agile practices

Of course, more areas could be on this list; these are the most common and can make a noticeable difference.

Engineering practices

Automate “everything”. 

There is no reason to have repetitive manual procedures in a development team that includes programmers. The mantra should be “automate everything”, or at least everything you must do more than twice. This includes automating:

• Setting up your development environment
• Setting up your test environment
• Building your product
• Running unit tests
• Deploying your product
• Running user story tests, integration tests, and API tests
• Upgrading your database schema
• …

When you automate things like this, you save time and ensure consistency in the procedures, regardless of who initiates them.

Many teams have some automation, but surprisingly, deployment and database upgrades are often missing, making it cumbersome to set up new development and test environments.

Manage your test environment.

The goal is to deploy and run the part of the system a developer is working on locally without having to access a shared database or shared external services.

Besides automating the building and deployment of your product, a productive development environment often also requires:

• Creating a test and development database with known contents that is small enough to be quickly dropped and restored at any time.
• Replace any external services with test doubles run locally that emulate parts of the behavior of the external system.

When the above is achieved, it’s easy to automate all kinds of test cases that require a deployed system and spin up new test environments whenever necessary.

Pair programming and/or mob programming

There has been enough research showing that pair and mob programming are faster than solo programming, produce code with fewer bugs and higher maintainability, and enable cross-training within the team.

If programming were about typing characters on a keyboard, two solo programmers would be more efficient than a programming pair, but that’s not the case. Programming is about problem solving. It’s a stream of small problems that need to be solved to figure out which code to write to make the software behave the way we want.

Problem solving is best done in pairs or groups. We solve problems faster and better when we have others to discuss them with – “two heads are better than one,” as the saying goes.

Code reviews using pull requests are inferior for ensuring we have solid source code and sharing knowledge. The reviewer only looks at what has been changed in the code, not what may have been missed, and gets very few clues about the thinking behind the code. 

Most pull requests lie around for 1-3 days before being merged. That’s a waste and not even close to continuous integration.

A way to move away from pull requests and ease into pair programming is Pair Review. Before pushing your code, you must sit with a programming buddy and explain it to them. If you find improvements that can be made, you do them then and there. Now you are pair programming a little bit!

Team composition

The purpose of having cross-functional teams is that during normal development, you don’t have to reach outside the team to access expertise or someone with a higher mandate. This removes external dependencies and makes the team faster.

There are two more things to consider in terms of cross-functionality, though:

1. The team may not realize they are missing a vital skill set within the team
2. There can still be internal dependencies within the team that hinder their speed

Have testing competence within the team

An often overlooked area of expertise within teams is professional quality assurance and testing. Testers approach a system under test differently from developers. Generally, developers want to prove that the system works, while testers want to confirm that the system isn’t broken in any way and measure the quality level so informed decisions about what to do next can be made.

Ben Simo recently wrote this in a post on LinkedIn:

Testing isn’t just about demonstrating that software can work—it’s about discovering how it may not work as desired.

• Test to discover what is undocumented. 
• Test to discover what is unsafe. 
• Test to discover what is unintended. 
• Test to discover what is unpredictable.
• Test to discover what is unknown.

If you aren’t seeking to discover, you may not be testing.

Everyone should be a generalizing specialist.

In many teams, you may hear things like, “We don’t have enough work in this sprint for our front-end developers, so let’s add some stories for them to do.” 

No! You are not hired as a front-end developer on your team; you’re hired as a developer specialized in front-end work. The role is “developer” or, even better, “team member.” Your specialty is front-end development.

The team’s goal in a sprint is to deliver the most important product enhancement (the one at the top of the product backlog) to the end users and the market, and every team member should prioritize that.

This means sometimes working outside your primary expertise to get things out the door. It’s about optimizing the team effort, not maximizing your personal productivity.

So, if there isn’t enough front-end work to do, you can help out with other team responsibilities like:

• Back-end development
• Testing
• Discovery work
• Automating things so that others become more productive
• …or anything that shortens the lead time for the current product enhancement or makes the team as a whole better

So far, I have used front-end developers as an example, but the same goes for any type of specialist within the team, such as back-end developers, testers, product owners/managers, Ux specialists, etc.

When planning a sprint, it’s a common mistake to implicitly assign everyone some of the work so they can carry on doing what they are best at and prefer to do. This is a suboptimization that slows the team as a whole.

I’m not advocating for everyone in a team having to be an expert at everything. Not at all! Having specialists in a team is often a blessing. However, everyone should have a few secondary skills to help out where they are most needed to optimize the productivity of the team as a whole. 

Agile practices

Underestimating the power of Team Coaches

Being a ScrumMaster or Team Coach is a real profession, and it requires a very different skill set from, for example, being a programmer. Many teams underestimate this and view Team Coaching as mainly an administrative task.

However, the primary responsibilities for a Team Coach are:

1. The well-being of the team
2. The team’s ability to deliver valuable stuff fast and with high quality
3. The continuous improvement of the two above

That list includes very little about booking meetings, managing JIRA, or facilitating ceremonies like daily stand-ups, retrospectives, and demos. Those activities are only tools to help teams reach their potential.

The Team Coach should aim to make themselves redundant so that the team members manage every aspect of being an agile team. That’s when you have a genuinely self-organized team.

Unfortunately, in most organizations I have encountered, ScrumMasters and Team Coaches consider this role part-time work and don’t make it their first priority. When pressed for time, they choose to contribute to the team by writing code, performing tests, or whatever they see as their primary job, rather than making it easier for their teammates to perform.

Again, this is a suboptimization. A Team Coach is a lever for the capabilities of the team. If they can, in a 5-7 person team, increase the team’s productivity by just 20%, their efforts will be worth the time invested. From my own experience, and when talking to other experienced ScrumMasters and Team Coaches, we all agree that you can double the performance of an average team within a year if you put in the effort. That’s much better than hiring twice as many people and expecting capacity to scale linearly.

Low-value retrospectives

Regular retrospectives and continuous improvement are, by far, the two most important Lean/Agile practices. There is always something that could improve our work situation since we never get everything right the first time, and things around us keep changing.

Although most teams have retrospectives regularly, their value diminishes over time in many cases as enthusiasm fades and the easy problems are already addressed. This leads to shorter retros (maybe just 30 minutes), and the improvements decided on are the same things that have been talked about before. This is not improvement work. It’s just going through the motions.

To learn if a team is stuck in this rot, here is an experiment you can try: After the retrospective, ask everyone in the team to write down on a sticky note the answer to; “What sucks the most in your professional life right now?”

Let everyone show their notes and then discuss whether the issue was brought up on today’s retrospective and, if not, why not. Maybe you need to improve the retros themselves.

As a rule of thumb, you should always work on the team’s worst problem, even if it seems very difficult to overcome. Your work situation can only be improved if someone is working on it. In the next chapter of this blog series, “Part 5: Continuous improvement on an organizational level,” I will cover how to support teams in doing that.

Practicing and deliberate learning

Finally, continuous improvement is not just about retrospectives. While that’s one method of improving a team, another is deliberate learning.

Any top-level sports team or serious rock band spends significant time practicing and deliberately learning new things to become better at their profession. There is no reason why business teams (like a development team) should not do the same.

This is about having a learning curve and staying ahead before the team runs into problems (that may be caught after the fact in a retrospective). The best teams I know have regular learning labs, code katas, knowledge sharing, training sessions, etc. It helps the team to keep up with technology and mature as individuals in their profession.

When was the last time your team deliberately practiced just for learning?

Conclusion

Before scaling up with new hires, optimize the teams you already have. If you measure, improve, and empower teams to perform at their best, there is a good chance you can double their capacity without hiring a single person. Isn’t that something?

---

This is the fourth part of a blog series about speeding up your organization. Previously published parts are:

• Intro, Blog Series: What makes your organization slow and how to fix it
• Part 1: Don’t start at the wrong end
• Part 2: Dependencies kill flow
• Part 3: Creating organizational focus