If you’d like to know what we cover in this beginner-level explainer, you should start with the Introduction. Or, if you want to go back a page, you should read Cross-Functional Teams.
No development team is perfect. Even the highest-performing teams can improve on what they’re doing, or else they probably need tweaks from time to time as knowledge, attitudes, situations, and responsibilities evolve.
Continuous improvement is a fundamental principle of DevOps, promoting a culture of ongoing learning, feedback, and enhancement. The ideal of continuous improvement involves iteratively identifying areas for improvement, implementing changes, and measuring the impact to drive further refinements.
Look, I get it: this seems like super-basic stuff. And it is! These things feel obvious, they’re pretty easy to get right, and you can easily forget about Continuous Improvement when a team is functioning well. But I’ve seen more than one team fail to implement a simple end-of-sprint retrospective, and the results are not good.
The Circle of Life Continuous Improvement
If you look at the diagram above, you’ll probably notice that the Continuous Improvement process is a circle, a shape known in some social or professional groups for its lack of a beginning or an end.
I, however, would say that continuous improvement normally starts with a Review. Something happened, and now we sit down to talk about it. It’s incredibly important to deliberately sit and discuss how things went, and unfortunately it’s something that teams can sometimes fail to do. I get it: what is there to talk about if things are going well? The answer is: there are always things to improve.
The team introspects, discusses, and they Identify areas that could be improved. We’ll cover it more in a bit, but it’s very important for this review stage to happen without assigning blame to individuals for failures; everyone is held accountable for the actions of the team as a whole. Nobody can fail individually when there are the proper checks in place.
Once identified, the team then must Plan how to improve those things. Make a list of action items with a specific person assigned to each and a deadline. Depending on team policy, some of the items might be ticketed.
Once you have your plan, you have to Execute on the plan: actually do the things you say. It’s no good just to have an end-of-sprint list of things you could do better.
Why Continuous Improvement?
In some senses, “why” is a weird question to ask. Is it better to seek improvement or not? Should we rest on our proverbial laurels or not?
In another sense, though, it’s good to ask: if one of our goals is to eliminate waste, then is it worthwhile to spend the time to conduct a retrospective, especially if things went well?
I would say that every sprint ceremony, every meeting, and everything the team sets out to spend time on requires some sort of cost-benefit analysis. But I have never been on a team that was having healthy retrospectives and yet thought they weren’t a useful investment of time.
Keeping Your Retrospectives Healthy
To err is human; to forgive, divine.
– Alexander Pope
Hopefully, you’ve never been on a team where there was a lot of finger-pointing. It’s not a fun experience, and it leads to unnecessary personal stress. But even if you were to care nothing for your team’s well-being and morale (you hypothetical monster!), then you would still care that it leads to all sorts of toxic development practices.
The main way to keep your retros and your improvement process healthy is to promote a blameless culture where individuals are not blamed for shortcomings. If something went wrong, we focus on the processes that allowed that to happen and not the individuals involved. Everyone trusts that teammates made the best decision they could with the information they had.
So, for example, if you had a release that allowed a terrible bug into production, then your retro might focus on:
- Is our automated testing sufficient to catch this type of bug?
- Is our code review process sufficient?
- Did we catch the bug quickly once it was in production? Is our deployment strategy sufficient to limit the damage of a bad release?
- Did we remediate the issue quickly? Was our rollback automatic or manual? How long did it take to detect the problem and complete the rollback?
Note that not one of those questions above focuses on who made mistakes. The focus is on ensuring that there are processes designed to catch mistakes and avert problems.
Let’s talk for a moment about mistakes. As Pope noted above, mistakes are human nature. But mistakes are also predictable in the sense that doing innovative things and iterating quickly will always result in a certain amount of errors. I’m not going to quote Facebook’s famous motto, but they’re also not wrong on the necessary tradeoffs. If you want to make progress, mistakes happen.
Blameless culture encourages individuals to take risks, experiment, and learn from failures without fear of punishment or blame. It fosters a safe environment where people can openly share their ideas, learn from mistakes, and drive innovation. It does, obviously, require a certain amount of buy-in from the Higher-Ups, or else the team culture can easily be undermined by fear of individual punishment.
Keeping your retros blameless also builds trust among team members by focusing on problem-solving rather than blaming individuals. It promotes collaboration, transparency, and shared responsibility, enabling teams to work together towards common goals. A high-trust low-ego team environment, in my opinion, is an underrated characteristic of a high-performing team.
Blameless culture encourages a mindset of continuous improvement. When incidents occur, the focus is on understanding the root causes, implementing corrective actions, and enhancing processes to prevent similar issues from happening in the future.
Blameless culture creates an environment of psychological safety, where individuals feel comfortable admitting mistakes, asking for help, and sharing concerns. This psychological safety encourages open communication, honest feedback, and fosters a culture of trust and learning.
Let me finally address one common misconception: Blameless culture does not mean avoiding accountability. Instead, it emphasizes taking ownership and being accountable for the outcomes. It shifts the focus from assigning blame to identifying system-level issues and finding ways to prevent future incidents.
Challenges and Barriers to Continuous Improvement
To overcome these challenges, organizations should prioritize continuous improvement as a core value, invest in training and education, provide dedicated time for improvement activities, establish feedback mechanisms, and celebrate successes. Embracing a culture of psychological safety, where individuals feel comfortable sharing ideas and experimenting, also helps foster an environment conducive to continuous improvement.
Resistance to Change: People may resist changes that disrupt established routines or challenge existing processes. Overcoming resistance requires effective change management strategies, clear communication, and involving team members in the improvement process.
Lack of Time and Resources: Teams may struggle to allocate dedicated time and resources for continuous improvement activities amidst project deadlines and competing priorities. Organizations need to prioritize and allocate resources to support improvement initiatives and create a culture that values continuous learning.
Lack of Visibility and Metrics: Without clear metrics and feedback mechanisms, it becomes challenging to assess the impact of improvement efforts. Establishing meaningful metrics and performance indicators is crucial to measure progress and determine the effectiveness of improvement initiatives.
Complacency and Status Quo: In some cases, teams may become complacent with the status quo, hindering their motivation to actively pursue continuous improvement. Overcoming this challenge requires creating a culture that embraces change, rewards innovation, and fosters a growth mindset.
Organizational Silos and Communication: Silos and poor communication between teams can impede effective collaboration for continuous improvement. Breaking down these silos and fostering open communication channels is essential to encourage knowledge sharing and cross-functional collaboration.
Lack of Support from the Higher-Ups: Especially in organizations unused to this type of culture, management may not share the commitment to a blameless focus on improving processes. This can undermine all of the benefits above, because even if the team doesn’t blame individuals, there can be serious consequences to a person’s career being perceived as at-fault.
Creating a Culture of Continuous Improvement
Creating a culture of continuous improvement requires deliberate effort and commitment from the team and organization, and it will be an ongoing effort. It requires consistent reinforcement of the desired behaviors and a commitment to learning and growth. By embracing these steps and fostering a mindset of continuous improvement, teams can drive innovation, enhance productivity, and deliver high-quality results.
- Set the Vision: Clearly articulate the importance of continuous improvement and its benefits to the team and organization. Share the vision of a culture where everyone is encouraged to contribute ideas, learn, and evolve.
- Lead by Example: Leaders and managers play a crucial role in modeling the behaviors they want to see in the team. Embrace a growth mindset, demonstrate a willingness to learn, and actively seek feedback. Encourage experimentation and show appreciation for individuals who contribute ideas and suggestions for improvement.
- Create Psychological Safety: Establish an environment where team members feel safe to voice their opinions, share ideas, and provide constructive feedback without fear of reprisal or judgment. Foster a culture that encourages open and honest communication.
- Encourage Collaboration: Facilitate collaboration and cross-functional interactions. Break down silos and encourage knowledge sharing. Foster an environment where individuals from different disciplines can contribute their unique perspectives and experiences.
- Provide Resources and Training: Invest in the development of team members by providing resources, training, and opportunities for skill enhancement. Support continuous learning initiatives such as workshops, conferences, or online courses that align with the team’s goals and objectives.
- Establish Feedback Mechanisms: Implement regular feedback loops within the team and with stakeholders. Encourage individuals to seek and provide feedback on their work, processes, and ideas. Create a safe space for constructive feedback and encourage a culture of continuous learning.
- Empower and Trust: Give team members autonomy and ownership over their work. Trust them to make decisions and experiment with new ideas. Empower individuals to take the initiative for improvement and provide support when needed.
- Recognize and Celebrate Success: Acknowledge and celebrate the successes and achievements of individuals and teams who contribute to continuous improvement. Recognize and reward behaviors that align with the culture of continuous improvement, fostering motivation and engagement.
- Iterate and Learn: Treat continuous improvement as an iterative process. Encourage teams to reflect on their progress, learn from both successes and failures, and apply those learnings to refine their practices and processes further.
- Embed Continuous Improvement in Rituals: Incorporate continuous improvement discussions and activities into regular team rituals, such as sprint retrospectives or stand-up meetings. Make it a recurring agenda item to review and identify areas for improvement.
Healthy retrospectives are incredibly important to team performance. They allow a team to find better ways to do things without harming team dynamics. Done properly, they can help foster an environment of trust and psychological security.
Establishing this culture of continuous improvement can be the work of years. Like anything else in the DevOps mindset, the culture itself requires an incremental approach.
While this section focuses on formal retrospectives, I’ll discuss in the next section that the principles here apply to other types of feedback loops.
Build Artifacts with Andrew 
