When developing software, one of the key things is to be able to ship something. To release a set of features to the end users. And not just once, but often enough.
From my experience, this is not the default state for most teams & projects.
Team size does not directly translate into team productivity & more features shipped.
Using some form of agile development methodology does not automatically guarantee the team will start shipping all of a sudden.
In HackSoft, we evaluate how a project is going by observing if the team is in “rhythm”.
A team in rhythm will ship features often enough.
A team in rhythm will refactor gradually, maintaining a workable codebase.
A team in rhythm will build abstractions that’ll pay dividends later.
Working within a team in rhythm will feel smooth.
A team in rhythm is a team in motion:
- Most of the time is spent in development.
- Work items are known for at least a week ahead.
- There’s someone responsible for generating those work items.
- Releases are orchestrated well.
- The established process has no major bottlenecks.
Rhythm is not the default state
Rhythm is not the default state of a team. Often enough, slow and painful development is the default.
Increasing the size of a team that’s not in rhythm will not result in increased performance, productivity & more features shipped. On the contrary, it can make things worse.
Rhythm needs to be built, taking into account the specifics of the project and the team.
Rhythm can be established easier, if team responsibilities are well known and there’s enough room to operate.
In the scenario of multiple teams working together, if one team is in rhythm, this does not automatically translate into all teams being in rhythm.
Rhythm can be established
The beautiful thing about rhythm is that it’s specific to the team and the project.
What’s worked for us in the past are the points mentioned below.
Most of the time is spent in development.
Features, rework, refactoring or proof of concepts - they all require development.
Meetings, estimates, plannings & useless discussions can take away time & focus from development.
If you want to establish rhythm, focus on what’s important. In most of the cases - that’s development.
Work items are known for at least a week ahead.
Not knowing what's next can be detrimental to productivity. Changing course every day or two - also.
Knowing priorities for months ahead is a hard task for every business.
But knowing priorities for a week ahead is achievable.
There’s someone responsible for generating those work items.
Trying to focus on development, while being constantly pulled in meetings & discussions is hard.
That’s why there should be someone on the team, who’s responsible for buffering between development and product.
Someone who knows what’s currently being developed & what’s next on the priority list.
Someone who can summarize information to the development team and to the product team.
From our experience, this is usually the technical team lead.
Releases are orchestrated well.
Releases can be great generators of chaos. Nobody knows what’s exactly happening, but we are releasing! And of course things are breaking.
Releases are work items and should be done with great care. If possible, avoid starting new work, before a release is done.
Plan releases accordingly & stick to those plans.
The established process has no major bottlenecks.
The process that leads your team into rhythm is the process that you should use. That is not necessarily agile.
Or to say it in simpler terms - Whatever works for the team & the project is the thing that should be used.
It can be something very simple, like:
- Someone generates work.
- Focus time is 1 week, where priorities don’t change.
- During that week, just pick the next priority.
- Release once there are enough things done to justify a release.
- Don’t rush, be in rhythm.
It can be a full-blown agile, if that’s working for the specific team and project.
If something is creating a bottleneck and is painful for everyone - fix it.
Few examples:
- Two teams sharing a library that gets constant changes, conflicts and bugs? Don’t share it, use it separately.
- 15 people are participating in a call, where only 3 of them need to be? Don’t invite everyone next time.
- Meeting is 1 hour, when it can be 15 minutes? Make it 15 minutes next time.
Rhythm can be changed
Sometimes things change. There’s something super important that needs to be shipped.
Sometimes there’s a proof of concept that needs to be built.
A team in rhythm can change the course of the development & establish a new rhythm, to hit a specific goal.
For example - there’s a team rule that every pull request needs at least 1 approval in order to be merged.
The team has established a rhythm around that and ships features often enough.
But there’s a chunk of repeatable work that needs to be done in a short period of time. Let's say - migrating something existing from one technology to another. Or a redesign.
Then, the team can establish a new rhythm, by ditching the PR review rule for a given period of time & becoming a parallel force, where each developer works & merges on their own.
Once shipped, the team can re-establish the previous rhythm or adjust to something new.
Rhythm can be broken
Of course, rhythm can be broken.
One of the easiest ways to do that is to take a big chunk of everyone’s attention and focus it on something that’s not important right now.
For example: Everyone’s developing happily, then someone decides: “Let's measure team velocity!”.
Boom. The rhythm is gone, because now everyone has to focus on estimates, rather than development.
Rhythm is important
A team in rhythm will develop & ship features often enough.
A team in rhythm is capable of running software development marathons, outpacing teams that rush like crazy, and then crash and burn.
Establishing rhythm is important.
Everything else is a struggle.
