This post is part of a series of shared values in software development teams where I reflect on my personal values in software development.
I value continuous improvement because I believe that elevating improvements in how we work over the work itself is key to becoming a high performing software development organisation. By continually investing in myself, those around me, and the processes my team follows, we can incrementally evolve our capabilities to become more effective and to help our organisation gain a competitive advantage.
In practice this requires a mindset where you:
- regularly reflect on how you and your team
- actively seek out opportunities for small, incremental improvements
- continue to learn & take time to learn through your work
- mentor and help team mates to improve
This all sounds great in theory but naturally there are some challenges to adopting a continuous improvement mindset, especially within a company setting:
- Time pressure (real or self-imposed) of daily work can make you feel to busy to work on improvements
- Identifying valuable improvements and avoiding making changes for the sake of change itself
- Identifying improvements when everything seems to be going well; this could be an opportunity to gain an edge
- Allowing constant improvements to monopolise time
- Prioritising the improvements to make when faced with many opportunities
Handling these challenges is all about finding the right balance; while it is important to continuously improve it is also important to continue to deliver value for the business. This means we need to carefully evaluate the value of the gains to be had from improvements compared to the value we can deliver to the business and prioritise appropriately.
There are always times when making improvements instead of completing daily work will cause conflict. However I firmly believe that it should be the decision of software development teams to decide when to make these improvements and no one outside of the team can overrule this. Of course the expectation here is that teams will be responsible towards the business and customers by not ignoring their needs.
If you approach improvements within a software development team with a data-driven approach then it is easier to justify the value of the gains made. For example, if you are making an automation deployment process more efficient then measure and record the time a deployment takes before and after so you can clearly demonstrate and communicate the improvement.
Continuous improvement doesn't only apply to a business and team setting. I adopt a continuous improvement mindset in my hobbyist development work outside of my professional career. This allows me to adopt some of the practices much more aggressively without the challenges of a company setting. I believe this has helped to get me to where I am today and I expect it to continue to help to push my career forward in the future.