By Sarah Gruneisen & The Engineering Team
Continuous improvement is a practice that involves a loop of reflection and adaptation and improvement as part of the work process. It encourages learning and iterating, which is a vital element of a successful Mobile DevOps strategy.
Having a culture of continuous improvement within your mobile developer teams ensures you remain effective as you scale – and most importantly, that you don’t scale problems with solutions.
In this blog, we delve deep into how to create a culture of continuous improvement within your mobile teams and why it matters if your organisation wants to master a mobile-first mindset and approach.
Scaling products without scaling problems
When you write new software, you start out small. Most likely you’ll take a pragmatic approach that works within your existing business context. And that’s quite right, because when you’re just starting out you don’t want to over-engineer your processes – the priority is getting your product out there into the world.
The trouble is, if you don’t have a system for continuous improvement in place as you scale, then you’re in danger of ending up with a bigger version of that first prototype – and as most of us will agree, first prototypes are horrible.
Balancing simplicity and over-engineering
At Novoda, we’re rarely involved in a product from the start, which means we often end up coming in to work on a product that’s been around for a while. Consequently, we often see one of two problems:
- The team have never learned how to build mobile products at scale. They’re learnt as they go and they’ve gotten pretty good. But then things have plateaued. In these cases, we’ll usually end up taking them back to the beginning to rebuild things from the ground up. Not only does this take a lot of time, but it can be daunting when everything you’ve built needs to come apart and be built back the ‘proper’ way.
- Products have been over-engineered from the start because the team of engineers felt that they had to tick every box before they scaled and plan for every eventuality. This means they’ve spent a lot of time and effort building things their users don’t need, or they’ve taken so long to get to a point of delivery that the feature isn’t needed anymore.
Embedding a culture of continuous improvement within your mobile teams aims to stop either of these scenarios from happening.
Channelling creativity towards solutions
Engineers are creatives and often have a siren pull to their ideas. Within mobile teams, there is always a tension to be managed between giving space for people to experiment and explore those new ideas and innovations without encouraging them to go off and do whatever they want regardless of whether it benefits the business in a real, commercial way.
When you have a robust continuous improvement process in place, it’s much easier to strike the balance between allowing that creative freedom and ensuring it’s channelled towards the highest priority solutions.
Balancing long-term objectives with responsiveness
A lot of people think ‘agile’ means working without a roadmap in order to be wholly responsive, but that isn’t the case. Agile doesn’t mean reactive. In fact, it’s all about continuous improvement.
When you’re building any mobile product for a large, scaling organisation, it’s vitally important to have a clear roadmap with key objectives to hit along the way. That doesn’t mean you don’t leave space to be responsive to customers’ feedback – this is a hugely important part of an agile methodology – but it does mean that you can conduct a risk vs reward analysis on improvements and new features before you start to engineer them.
Your product managers may be pushing to put out feature after feature – and quite rightly because the customers are asking for them. But what the customer is asking for might not always be the right next step for the business’s long-term success.
If you’re asking developers to churn out feature after feature and by doing so they neglect something that slows down the overall development of a project, then ultimately you’re going to end up rolling out fewer features because a bigger problem will arise that needs fixing.
Ensuring retrospectives are effective
Within a culture of continuous improvement, you need effective retrospectives with concrete actions, assigned to individuals. It’s easy for retros to become a complaining session where people moan about the same things week after week, but they need to be focused on immediate solutions and the bigger picture.
Often in retros, people focus solely on existing processes – what has been done and what needs to be done. Less often, teams step back and ask: do we actually have the right process? Do we need to remove some aspects? Are we doing the right thing here? Effective retros aren’t necessarily about how to do things better, but whether you’re even doing the right thing.
Following on from retros, you then need to measure the impact of any improvements or changes you’re making. You don’t want to keep jumping into new ways of doing things if you don’t have proof that productivity and quality are improving.
Prioritising changes
Without a framework in place for objectively prioritising work, meetings around priorities can easily descend into conflict with everyone wanting their priorities to be everyone else’s.
One of the ways we use to objectively prioritise work is the RICE method, which asks:
- Reach – how many people will this reach and affect?
- Impact – what impact will this have on our business?
- Confidence – how likely is it that this project will be successful?
- Effort – how much effort will this take to implement?
Using this framework, everyone in the team scores each proposed change anonymously which produces a number or ranking that determines a task’s priority.
Moving people between teams
Considering different perspectives and alternative ways of thinking is vital for a culture of continuous improvement within mobile engineering teams. As Conway’s Law states:
“Organisations who design systems are constrained to produce designs which are copies of the communication structures of these organisations.”
If you have multiple product teams within your company who work in silos, you can end up fostering an ‘us vs them’ mentality, with each team bringing different perspectives to meetings and arguing their points of view.
However, if you move people around between teams means, you can introduce new perspectives and bring in fresh knowledge, ideas and creativity. Not only does this lead to greater innovation and faster improvement, but it can result in greater job satisfaction for your team too.
Engineers tend to change jobs every couple of years, but by allowing people to regularly work on new projects with new teams, you can offer them a new challenge and learning environment without them having to change jobs.
Balancing maintenance and innovation
One of the biggest threats to continuous improvement within an organisation is not getting the balance right – often, we see companies doing too much or too little.
Every time you make a change, your mobile teams will go through the process of:
- Forming – getting used to changes and forming new ways of working
- Norming – embedding changes so that they become the norm
- Performing – hitting their objectives and performing well together
- Storming – ramping up innovation and creativity to exceed objectives
If you’re shifting your processes or your team structures too often, it’s difficult for teams to get to a place of performing because you’re keeping teams in the forming and norming stages and they miss out on opportunities to grow together.
As soon as you add a new team member or change a process, your mobile teams are back in a place of forming, trying to get to norming. They never get to perform and storm which can have a detrimental impact on your product quality and innovation.
What’s more, if you’re continually bringing in new things which your engineering teams need to spend extra time and brainpower getting used to, this might cause them to neglect maintenance, leading to cracks in your foundations. Worse, you might even end up with dysfunctional situations where people are having to work overtime to keep on top of everything which is more likely to lead to burnout.
Ensuring observability is meaningful
Within a continuous improvement culture, observability is essential to ensure that processes are not deteriorating over time and that improvements are adding genuine value.
Observability can be defined as the ability to ask any question of your system and have it answered. It’s not about micro-management, it’s about ensuring you can identify what happened whenever things go wrong and spot small issues before they become large-scale problems. It’s about observing the right things that are going to tell you what you need to know about the quality of your work.
For observability to be effective and accurate, it’s crucial to ensure you aren’t measuring something that can be easily manipulated. For example, you might want to bring down the number of bugs as an indicator of work quality. But on the other hand, you want people to find bugs so they can fix them. If engineers are being measured against having fewer bugs in their work, they might be less likely to find them because they want to be seen as performing well. Ultimately, this isn’t going to serve your business.
Alternatively, if you’re measuring how often a system crashes, that’s an objective measurement.
Conducting pre-mortems and post-mortems
As part of our culture of continuous improvement at Novoda, pre-mortems and post-mortems are one of the most useful things we do.
Before we begin any project we start with a pre-mortem, which aims to consider all possibilities and risks, so that predictable risks can be mitigated in advance. Post-mortems cover everything from communication to processes to likely team changes.
Additionally, whenever anything goes wrong, we conduct a post-mortem where we ask:
- Why did this happen?
- How did it happen?
- How did we detect it?
- How early or late did we detect it?
- How can we be better at detecting it in future?
- How can we prevent it from happening again in future?
If you commit to this process in a blame-free environm
