As a Customer Success Manager here at Swarmia, I get to work with engineering organizations from some of the most impressive technology companies in the world. And over time, I’ve noticed that the highest-performing software teams have one simple thing in common: they get a little bit better every day.
Unfortunately, though, “getting better” and “continuous improvement” are phrases that often get thrown around without much detail or practical advice. And that’s why in this blog post, I want to share some of the concrete steps our customers are taking to make gradual yet high-impact improvements in their ways of working.
Prerequisites for continuous improvement
Before we jump over to the practical advice, let’s quickly look at the three preconditions that allow modern engineering teams to continuously improve their practices and consequently, performance.
1. Mindset shift
Historically, when an organization needed to pivot its delivery practices or implement a new methodology, they would look to agile transformations as the answer.
For large, legacy organizations, it wasn’t easy to suddenly change directions and implement new practices or ways of working. It required changes to every aspect of the company, from job titles and organizational structures to technology and system changes. Training, change management, plans, and funding were needed to make these shifts a reality.
Transformations of this scale have a whole industry, careers, and resources dedicated to them. They typically are quite large undertakings that require a huge upfront investment and multi-year project plans, not to mention ample patience and goodwill from the employees.
Now, if your organization was founded in the last decade or so, odds are you don’t have the same legacy systems, processes, and organizational structures that require a larger transformation in order to see improvements across speed, quality, and developer experience.
That’s why it’s time for more modern engineering organizations to stop looking at productivity improvement as a set goal to achieve. Rather, you should see improvement as a continuous element that can be embedded into your teams from the start. Not a destination, but a journey.
Because let’s face it, there’ll never be a shortage of things to improve on.
2. Empowered teams
Empowering your teams is a necessary step towards unlocking continuous improvement in your organization. According to Marty Cagan, author of “Empowered”, empowering your engineers does not mean just giving them the space to figure out the best way to code or build something. Rather, they should be empowered to figure out the best way to solve a problem that has been presented to them.
For a team to be empowered to solve real customer or user problems, there are several elements Cagan describes that need to be in place, specifically cross-functionality and shared accountability.
If a team isn’t cross-functional, it’s difficult for the team members to take responsibility for the final solution. When you’re only responsible for one piece of the final product, it’s easier to be okay with a sub-par outcome, as long as your part of it was done well. By structuring teams to include all roles and skillsets needed to deliver a product end-to-end, you provide them full control over the end product. This control unlocks the shared accountability within the team and means they are now responsible for the success or failure of what they have built.
3. Visibility
It’s nearly impossible to determine where your team should focus their improvement efforts without some kind of visibility into your current workflow. That’s why having the proper tools and processes in place that provide this visibility is a huge piece of the continuous improvement puzzle.
Often when I first meet with a customer about improving their team’s productivity, they don’t know where to begin. Having a tool like Swarmia in place that provides you visibility into bottlenecks in your system or areas where the flow is breaking down is a great first step toward finding where to start.
Working with many engineering organizations over the years has taught us that it’s difficult to improve what you aren’t measuring. Taking that sentiment one step further, it’s also hard to track improvement if you don’t have a baseline against which to compare your progress.
Now, we frequently lump tools and processes together because a tool can only provide so much value if you don’t have a process in place to to take action based on what you’re seeing in the tool. That’s why at Swarmia, we want to ensure that we’re building a product that’s more than just a dashboard for the leadership team, but rather something that helps to drive improved processes and in turn, improved productivity throughout the engineering organization.
Continuous improvement in action
Once you have the right mindset, empowered teams, and enough visibility, it’s time to start chipping away at concrete improvement initiatives. Here are the three practical approaches our customers, as well as the engineering team here at Swarmia, have found particularly impactful early on.
1. Retrospectives
Retrospectives provide a safe space to reflect on past work and discuss areas of improvement or learnings within the team. Setting up these conversations on a regular cadence is a great way to strengthen this skill within your team. If retrospectives are new to your team, try starting with them every four weeks and then adjust the cadence based on feedback from your team.
As the purpose of retrospectives is to facilitate continuous improvement in a team setting, using Swarmia in retrospectives can help you get there. We actually have a fantastic retrospective guide that we share with our customers to help them start integrating retrospectives into their regular practices.
One particular data point I’ve seen many engineering teams use in retrospective discussions is flow efficiency. Out of all of the days your team spent working on a particular feature, how many days was there progress made or activity done to move that feature forward? How many days was that feature blocked or left idle?
This information can help a team discuss ways to deliver value to customers faster. Could we have solved this issue as a team and removed the blocker faster? Did we have too much work in progress at that point that hindered us from delivering value from the new feature?
One of the biggest benefits that can come from retrospectives is the conversation that follows. Driving conversation around metrics is much more valuable than just making assumptions about what is shown. After all, there’s always a story behind the data.
Over time, you might also want to experiment with focusing on specific pain points that come up in the retrospective and agree on actionable steps to improve or resolve. For example, if the issue of CI pipeline slowness comes up in several retrospectives, it might make sense to focus an entire future retrospective on that topic.
2. Working agreements
Once your team has visibility into areas they can improve, the next step is to agree to take action. In Swarmia, we make this action easy by allowing your team to adopt Working Agreements or targets they’d like to set as a team. These Working Agreements are all based on the real data from your GitHub and Issue Tracker integrations, which allow you to definitively see if there’s been improvement.
An example Working Agreement we often see teams adopt at Swarmia is around reducing pull request review times to no more than X number of days. By adopting this agreement as a team, team members now have shared ownership and accountability to achieve that goal.
One other frequently adopted Working Agreement is around limiting work in progress (WIP) to a particular number of stories. This allows the team to focus on a few key pieces of work, and to collaborate on existing stories or epics before starting something new.
If you’re new to working agreements, try starting off with just a few key agreements for the team to focus on. Learning new ways to work takes time. Once you start to see consistent improvement, look to move onto the next opportunity. The key to mastering your working agreements is to make sure they are enforced within the team and reviewed periodically as a part of your teams regular discussions.
3. Code reviews
Another approach for collaborating and driving improvement in teams is through continuous feedback. A common way engineering teams provide and receive feedback is through their code reviews. Here’s a great blog post on improving code reviews in your team if you’re interested in some additional reading on this topic.
Code reviews should be seen as a partnership or teamwork. Your teammates are not reviewing your code to find all the things you did wrong, but rather help ensure that the work you did is the best it can be. Just like book authors have editors review their work before publishing, great code requires an extra set of eyes as well.
Developing high-quality code is obviously beneficial for the customer, but the less obvious benefit is how it helps the team with future development. Having multiple eyes on the code promotes knowledge sharing as well as improves quality, which helps to eliminate refactoring or production issues down the road.
Having this collaborative process in place allows for better discussions and improvements to be discovered and implemented. Because we all know the old saying, ‘two heads are better than one.’
Wrapping up
I hope you’ll benefit from the prerequisites and practical steps discussed here when you’re taking your first steps toward building a culture of continuous improvement within your engineering organization.
Tackling challenges can sound scary, but it doesn’t have to be. Remember to look at improvement as a journey rather than a destination and understand that now is the best time to start.
