Shorten your feedback loops

Short feedback loops are better than longer ones as you learn faster.

Everyone should teach others the value of short feedback loops. When these are short, then you find out things sooner, rather than later. That can have massive impact on your learning, time in development, and spending of your product budget.

If your people follow a slow or leisurely cadence of meetings, and integration of work, then this leads to late discovery of issues. Students seem to think a slow cadence is ok when the deadline is far in the future. They think that’s plenty of time.

This mindset is mistaken. It leads to more waste than necessary. Fortunately, it can be fixed with some discussion amongst the team.

Photo by charlesdeluvio on Unsplash

Teach people to prefer short feedback loops

Shorter feedback loops cumulatively have a large impact on your work. All you need to do is point these out to the people you teach, and they can start gaining the benefits, and then move to the other areas as they see opportunities. If they’re unsure, then get them to experiment.

How long it is until someone else sees your work?

First, the team should look at how long it is until another team member sees their work. Shorter is always better with instantaneous being best. For example, when team members work individually, when do they check their code into the version control repository? At a minimum this should be daily. Only when the code is in the remote repo can other team members try to use it in their work. Until then the code is invisible and no one knows what it does. Yes, they know which ticket the person is working on, but they don’t know ‘how’ the code works.

If you pair, or mob, then there is instantaneous feedback by another team member. This is a good place to be.

How long is it until your code, and the team’s code is tested?

Second, when do the team test their code? This too is feedback. For example, do you only use unit tests, or only do manual testing? This is not a good place to be. You should teach people to test across as much of their codebase as possible. Knowing my unit tests pass is fine, when I check my code into the repo, but is not enough to know that my code doesn’t break your code. You see the problem now, right? If you don’t check in your code, then I can’t tell if my code breaks your code. 

There should be integration tests, which automatically test everyone’s code when it’s checked into the team repository. It might be a challenge to put automated tests into place, but is always better than manually testing.

If you pair, or mob, and write tests at the time, then you’re in a good place.

How long is it until your code is in the main branch?

Third, do you teach the team to do all work on the main trunk of the repository? If the team are using feature branches, or personal branches, then how frequently are these merged to the main branch? Again, I’m always reminding my students, that their code is invisible to the rest of the team until they merge it with the main branch. 

Maybe someone will use another branch to test an idea. If the idea works, then they can merge the code into the main branch. If it doesn’t work, then they throw the code away. This should take at most a day or so. All code should be merged with the main branch at the end of a day. If it takes longer than that, then no one knows what it is doing, and it is accumulating technical debt. 

This means the whole team focus on pushing their code to the main branch. This provides feedback to everyone on the team. People know what other team members are doing because it is visible. Others see their code and can react accordingly. They can point out issues, they can modify their work, the whole can grow. In addition, automated testing is catching issues too, and providing another sort of feedback to the team. 

Teach them to think: when will people see my work?

If you teach people this mindset ‘when will people see my work?’, they will see many opportunities to improve their practice and reduce the length of the feedback loop. From this, they will see improvements. Now, people will go less time before others see their work, and make corrections sooner. Tests will catch errors/bugs sooner too, and hopefully that bit of code will still be in their working memory too, so it’s faster to fix. 

In the best of all worlds, the team collaborates as a mob and is working only on the main branch, and putting tests in place as they do the work. I have yet to see a student team doing this all the time. It happens in phases sometimes. Maybe next time…

---