There is a vicious cycle in software development between doing large changes and slow feedback loops.
When the feedback loop is slow, people will batch more changes together, and when the batch is large, people will procrastinate on the reviews.
It's necessary that we are aware of this cycle to be able to break it. Tackling only one side of the circle is tricky because the other side works against it and aids in reverting to the old habit.
Speeding up feedback loops
Feedback loops are essential for speed.
Slow feedback loops cause people to invest too much time in something before learning it's wrong. People will have to spend more time context switching from other tasks when the feedback is received.
Imagine that you are sitting on an electric piano, trying to learn a tune by ear. You play a note, and you can hear the sound instantly. Was it too high? You can try another lower note right away. In a couple of minutes, a person can learn a part of a simple tune.
Now imagine that the sound of the piano does not play as soon as you press it. It takes a few minutes to come out. This difference between what you do and the sound it plays would make it much harder to learn the song.
Having a slow feedback loop can feel the same way.
That's why it is essential to speed them up.
Which are the feedback loops you should look to accelerate?
You want to speed up the following activities :
- Run automated tests
- Setup or configure a development environment
- Run Continuous Integration & Continuous Delivery/Deployments
- Reviews (design or code reviews)
Reducing the batch size
Reducing the batch size of the work means slicing your projects into smaller parts.
Large changes take a longer time to review, validate and release. Reviewers are known to procrastinate large pull requests. Cramming large pieces of work together tends to cause more back and forth between the reviewers and testers. Releasing small changes more often makes it easier to roll out changes to production and roll them back in case of a problem.
Splitting the work into smaller pieces that can be independently reviewed and released improves the flow of work. More minor changes are easier to validate, which significantly reduces the time of code reviews and testing. Remember that these benefits are valid only if the feedback loops are fast. If people have to wait too much time to get feedback, they will tend to cram many changes together, to avoid the overhead of the feedback cycle for every small case.
That's why it's easier to increase the team velocity if you improve both feedback loops and batch size simultaneously.
Follow me on Twitter for more articles on troubleshooting software engineering teams' problems. I publish twice a week.
