Floor and ceiling raisers have been on my mind lately regarding software development.

Yes, another sport analogy… but one I believe is fitting.

What does it even mean?

I heard of this concept as related to basketball initially.

A floor raiser is a player (or concept) that raises the lower level you operate at.

On the contrary, a ceiling raisers will raise the highest level you can operate at.

In a software development team, I think of these concepts as:

Floor raising => We are better within our ‘possibility space'

Ceiling raising => We expand the horizon of our ‘possibility space’

How does it relate to software?

While the decisions are, at it's simplest, much more intuitive in basketball, I believe a good software team is first and foremost a team.

And as such, other than the obvious ‘you are as strong as your weakest link'. There are practices you can adopt to raise your team’s floor (and a couple of hints on raising its ceiling).

And I will focus more on the floor, because contrary to basketball, ‘peaks’ matter less than ‘valleys’ in software development.

In the long term, the productivity of a software team will be determined by its valleys.

Raising the floor

So, what can you do to raise the floor? And how can we measure the floor of a software team?

The floor

The baseline measure I will consider for a piece of software is:

• Ease of change,

• amount of defects,

• the software works as expected

In the scope of a team:

• Deploys per period,

• defects per deploy

• time to fix defects

Apart from the practices described below, hiring a senior or raising the seniority of your team will raise the floor of your team.

Practices

Test Driven Development

This is I believe one of the biggest floor raisers, and one of the easy pickings.

Code designed with Test Driven Development, is easier to change, produces less defects and can be deployed continuously.

Short lived branches

By reducing the overhead of reviews, and the size of code reviews, you again, by design raise the floor of the team. Trunk Based Development, while needing of quite a few preexisting conditions, is even more effective at that.

Ensemble/Pair Programming

By reducing the feedback loop: the review happens ‘as you code'. And, helping maintain a higher base level of care. Coding in group helps elevate the floor of a team.

Thin vertical slicing

By creating thin vertical slices for your projects/features, you lower the risk of any one slice, you facilitate the review process and shorten the feedback loop.

Retrospectives

By having frequent retrospectives (the 6 thinking hats framework worked quite well on our team) you open the door of adapting your way of work. This will allow you to progressively raise the floor of your team.

Raising the ceiling

The ceiling

The ceiling is derived from the capabilities your team has. What domains they can work on and for what types of technological problems they can intervene effectively.

How to raise it

If the technological or domain proficiency of certain members of your team grow, the ceiling will move up.

There are two obvious ways to achieve that:

• Hiring a specialist,

• forming members of your team in new technologies or specialist subjects.

Conclusion

At its limit, the productivity of a software development team is determined by its ‘floor’ so when thinking which practices to introduce to your team, think which would be the most effective floor raiser.

The floor is also, the limit where you can have more impact in the long run. Although you can have bursts of impact on the ceiling.