A story about reducing feedback loops
Achieving great things is not a matter of an instant. It requires continuous effort, dedication, and perseverance. When we build software, we shouldn’t try to do everything at once. There’s a better way to manage things: take them one step at a time.
Small steps, one after the other, that in the end lead us to our destination.
What happens when we make big steps
There had been a lot planned this month: a change in the user registration to add a new welcome email, an adjustment in the billing system to make it easier for customers to manage, and a change in one of the payment providers.
Mrs. Code made herself the first coffee of the morning and sat down in her seat. She quickly became engaged in development. It had been a long month and she had almost everything completed. Change here, new functionality there, refactor on this other side… Everything was going the way she wanted, she looked at the sprint’s to-do list. Almost all of them finished. Besides, everything seemed to work like a charm because there hadn’t been any errors in production for a couple of weeks…
Oh, of course, how could anything go wrong if she hadn’t deployed yet. When was the last time she did put a new version out in production?
Well, no worries, she prepared a new release: 32 files changed, 2000 lines of code modified. Quite a few changes… She deployed it.
The expected happened.
Slack started ringing, notifications popped up in several channels warning of errors. Some from the payment system, others from billing. Well, at least nothing had happened with users’ new email (yet).
She rolled back to the previous version and the error notifications stopped. She should have done more tests, checked that everything worked as it should… Did she do everything the way she was supposed to?
She finished her coffee. Now she was in a difficult situation. First, she didn’t know which of the modifications had caused the system to fail. She had merged up a lot of changes at once, and figuring out what exactly was going wrong would take her a while. Second, until she fixed all the bugs, she wouldn’t be able to get the changes that worked into production (or she’d have to do the work of separating them from the rest). It wasn’t going to be an easy thing to manage.
If she had released a version when she had made the new email for users, it would have been in production for two weeks now. If she had rolled out the billing part when she finished it last week, she would have caught the bugs earlier and they wouldn’t be mixed up with the bugs in the payment system.
If she had done it step by step, she wouldn’t be in that situation.
What we achieve with small steps
Mr. PM was analyzing some data when Mrs. Code came to his site to show him the changes to new user registration. Did she already have it? But the planning had just been done…
It turns out she hadn’t finished it, but she had implemented some of it so he could try out the new features. He registered a new user and received the new welcome email they had defined. The content was all correct, but… The introductory text was not quite understood. On the design it made all the sense, but now, seeing the email in front of him and putting himself in the user’s shoes, it may not have been quite right.
He talked about it with Ms. Design. In fact, there was clearly room for improvement. Once integrated into the complete product, the truth is that it could be expressed in a different way to bring clarity to the email.
Thanks to being able to test the development first-hand at such an early stage, He had been able to validate that the solution did not fit as well as they had hoped and they could correct in time. They had avoided confusion for their users and had learned about their product.
He went to thank Mrs. Code for involving him in the development process before she had it all finished. They had avoided a lot of problems with it and he had felt more part of the product development cycle.
He found Mrs. Code fixing a bug in the new functionality: the mail wasn’t always reaching the new users. However, she seemed happy, she said that realizing it earlier made it much easier to fix it with the context she had at that time and without having to change a thousand things that would come later.
Doing it step by step had made things easier.
Small, incremental, iterative steps
As we have seen, both Mrs. Code and Mr. PM have been able to take advantage of the advantages of taking small steps. These benefits often come in the form of short feedback loops that provide early and recurring feedback that helps reduce risk, identify potential improvements, and refine the product.
With small steps, we are able to involve all team members in the development cycle and even our users, who can start validating our functionalities before they are fully finished.
It also allows us to catch bugs before they get out of hand and makes them easier to fix. If our change is small and fails, it’s easier to figure out what went wrong and fix it.
When we develop software, we have to do it in small and frequent steps. Short feedback loops will allow us to learn more and much faster.
- The Art of Small Steps in Software Development: A Lean Vision by Eduardo Ferro
- Small Safe Steps 3s workshop by Eduardo Ferro
- Elephant Carpaccio workshop by Alistair Cockburn
The key to successful software development lies in taking small steps rather than attempting big breakthroughs all at once. Ms. Code’s story illustrates how making incremental changes and rolling out functionality gradually not only prevents significant problems, but also allows for valuable feedback early.
Adopting this approach not only makes it easier to identify and fix bugs, but also involves all team members and users in the development process. Short feedback loops are essential for quick learning, continuous improvement, and ensuring that functionalities are effectively tailored to the user’s needs.