Despite better marketing opportunities, the days of big bang releases are gone. In today’s software market, iterative releases are the hallmark of good planning, well organised teams, and software stability.
A few times during the past year I’ve caught myself advocating for iterative changes. Both in software and in terms of our processes I’ve found that I far prefer smaller, incremental improvements over stressful, complicated and far-reaching changes that may or may not improve fulfilment, delivery and other metrics.
1. A software renovation project
The first time was during a renovation project. I had a code base that was built several years prior by someone who no longer worked at the company. Instead of scrapping the code or making huge rewrites, I decided that my first objective was to make the code more modular and easier to understand. I would also try to use what had, since the original person authored the code, become standard approaches.
So I replaced classes with functions, returned new objects instead of adding to existing ones, added a library of types, and isolated code within clearly defined, modular boundaries.
I knew the code needed some work. But if I were to take it further, I would be taking an extra risk: I didn’t fully understand the implications of all of the paths the code could take. I didn’t know the business impact of changing something that looked innocuous and yet could affect users.
Later, with these improvements in place, and a better understanding of what the business needed from the code, I could initiate a larger project to rebuild it into a more suitable shape.
There were also a number of other deliverables which the business needed in the interim. I was able to work on these until an opportunity came up to invest more time in improving what I had already standardised.
2. Implementing a team retrospective
I first saw the benefits of retrospectives a few years ago. When they were first implemented in my team, I saw straight away what an opportunity they created.
Quickly, we were able to voice our concerns about what processes had failed during our sprints. Other team members, including project managers, were able to pinpoint issues without having to focus on an individual team member, which led to less accusative and more collaborative environment. Everyone seemed to be happier.
So when I found at my new place of work we didn’t have a retrospective, I was keen to get one started. I came up with a simple, straightforward board plan which consisted of electronic sticky notes for each team member, and 4 rows, one each for “were the action points for the last retro done?”, “what worked well”, “what went badly”, “ideas” and “action points”.
When someone puts a ticket in the “what went badly” row, I spend a bit more time to identify exactly what caused the issue and try to turn it into an action point.
In the approximately 10 months since we started, some team members have come up with really good ideas which we’ve implemented. We’ve eliminated a large number of things that were causing unwanted friction or frustration, and I hope it has also helped the team’s wellbeing.