Reflections on Retrospective-Driven Development
Today I want to talk about a common anti-pattern across different development teams in different companies.
I will tell a story that you are probably familiar with. You’ve probably been there before. It’s a sunny day and you are happy and feeling productive. The app is under control, you’re finishing a feature, you did the tests. Everyone is delivering, deadlines are met comfortably.
Suddenly, the bi-weekly reminder, retrospective meeting time. Why do we have to do this? You ask yourself, it’s all good man, you think.
We have to do it because we follow Scrum and Scrum is a good thing. It is an agile methodology, surely it helps us be more productive, how can it harm the project? We need to tick that box, the equivalent of a unit test made merely to increase code coverage.
Follow the Process
We start the chore. What we achieved, what we did wrong and what we can do to improve. Time to praise ourselves, mention all things we have accomplished, such a good team, euphoria takes over.
Things that went wrong. Not much to say, we are developing an app that just calls web APIs right? It has been the same for the past couple of years, no new challenges, no significant changes, same issues as always. APIs were down. Blocked by requirements. Write it down. Outcome as expected : Oh yeah we know about that but we can’t do anything about it. Next topic.
Active participants only
What can we improve? OK guys take ten minutes to think about how we can improve, we are going to ask every single one of you. Now this is the key moment, the moment when the clouds start showing up in the horizon. It looks like it is going to rain a lot and you can’t stop it. There is nothing to improve but Johnny has to say something, it would look bad if he doesn’t, his reputation as a software developer is at risk, maybe people think he doesn’t want to contribute, maybe they think he has been playing COD during the meeting. So Mr. Doe remembers when he heard about the new technology, he saw it in that medium post, or a friend told him, it rings a bell definitely, oh yes, it was in the last Google I/O.
There you go. Johnny Doe suggested it, a few people that didn’t know what to say jumped onboard and added a +1. Phew they thought, it looks bad to say there is nothing to improve, it would seem as if I don’t care. One guy that actually had hands-on experience with the framework stood up against it. This guy knew the new dependency injection system Johnny wanted to add was harder to debug, had a very long learning curve and wasn’t really tested on production yet. But how can you argue against moving from XML to Compose, how can you argue about moving from Koin to Dagger, how can you argue against moving from a bike to a motorcycle. On paper it is impossible, the evidence is overwhelming, besides Google recommends it. There is no point fighting it. That’s it, decision made.
The scrum master doesn’t really know what this new framework is, but devs seem pretty confident. Scrum guidelines say we need to create tickets about the “What to improve” outcome. A productive scrum master is a happy scrum master, a new ticket is on the board.
Easy decisions
That decision, that was really not thought about, kind of small talk, a careless wish, now is a ticket on the board. Is going to shape the future of the app. It will be something to ask in the interviews for new candidates. How on earth did we get here? This morning devs were happy and business people were happy. Productivity was the norm.
So far, everyone did their job, we applied Agile, we followed it as the guidelines says. All the unit tests worked we could say with confidence.
Decisions have consequences
The ticket involved a huge refactor, devs didn’t have real experience on it, Johnny’s arch enemy did end up troubleshooting the rest of the team, bottlenecking the development. Even when everyone learned the technology, a feature that took one day to implement now takes three due to the increased complexity. New issues came up on production. We couldn’t know, it wasn’t mentioned in the articles. The motorbike looked better on paper than the bike. Now we find out it needs insurance, it needs to pass the technical inspection, our devs didn’t have the driving license and the helmet is mandatory. We just needed to ride 10 meters downhill, the bike was more than enough.
Teams must be pragmatic
In a rapidly changing environment such as mobile technologies we need to ask ourselves these questions.
1. Do we have any issue with the current technology?
2. Are the users going to notice any improvement in the app?
3. Is it going to increase development time?
For sure there is one benefit, developers will have an up to date CV, ready for the next role where they will be asked for it, but apart from this and having the app “future proof”, if the answer to three questions above is “NO”, wouldn’t the company have been better off without it?
I’ve had this feeling multiple times and all those times the application didn’t have a 100% user crash free rate, no integration and / or UI tests for all features, not 100% modularised. Not polished and stable enough. Not with automated CI or CD pipelines. Not with the build time reduced. Changes that actually bring value to the business.
In Conclusion
We could argue that, in practice, retros are a healthy form of democracy. Unfortunately, in teams with a stable product or in teams that have a large number of less experienced junior developers, decisions can creep into retrospectives that have unintended consequences.
Be careful to avoid making high impact technical decisions during retrospectives. Rely on your senior developers and technical leads to steer you in the right direction with careful measured thinking and technical strategy.
In our next post, we’ll dig deeper on the topic of team setup and seniority, and how to effectively navigate projects with junior teams.
