Start with Retrospectives
You have read The CD Test and it resonates with you. Continuous Delivery sounds great as a concept. Your team is doing some of these practices, but not all. Your list of questions with “no” answers sounds like a good to do list. You know that changing how the team works could improve the team’s momentum. That means shipping new features to your customers more often. And that means increasing business value of your product smoothly and steadily.
But there are many unknowns. You’re not sure how other team members feel about the state of the team, the current process, and how work is shipping to customers. You’ve heard the phrase Continuous Delivery in passing, but the team has not talked about how it could apply. Or if it should. You don’t know how your team moving to CD would affect other teams. You aren’t familiar with each team member’s goals or needs, and how any changes to how they work would affect them. Continuous Delivery means change. And you don’t know how willing your team is to embrace change.
How can you align your team around the need for change, build a culture of process adaptation, and improve your CD Test score? The short answer is another CD Test item - the Retrospective. Let’s talk about how to use retros to build this culture in your team.
Retrospectives
First, a quick intro to (or refresher about) retrospectives. A retro is a meeting where the team reflects on their team’s “story so far.” It is a time to talk about what is working and find ways to amplify that strength. Or it’s a time to talk about what is not working, rank the problems’ importance, and suggest fixes.
If your team does not have regular retrospectives, Nicola Rushton’s quick start guide is a great introduction. The book Agile Retrospectives is full of more advanced retro topics. It has good discussions on how to set the team’s expectations for the meetings, how to facilitate well, and how to process the outcomes. There are also mini-discussions of different retro types and their preparation activities.
As the team builds a set of good retro habits, there will be challenges. Not everyone will want to share their feelings. People avoid talking about hard problems. You may get surprised when a retro uncovers a problem you didn’t realize you had. And there are often initial retros when nobody wants to say anything out of fear or discomfort.
There is no shortage of tips for dealing with common retro problems. How do you help people become more comfortable with talking? How do you talk through the hardest discussions? Or how to combat more general problems? Work through these together and the team will build trust.
Once your team is experienced and comfortable with retrospectives, what’s next on your CD journey? It’s introducing a new mindset about how the team works.
Process as Product
A software team’s development process is as much a product of their work as what they build for their customers. The process is a set of features - design, planning, implementation, deployment - that the team uses to build business value. Like any product there can be bugs, new features, or performance problems. Development tools can change or break. Staffing changes when someone new starts or a veteran leaves. Test runtimes or validation cycles grow too long and features are not shipping on time. Business realities determine new software work for the team. And team realities can suggest process improvements and adaptations.
How would your team receive this idea of “process as product?” Does the team have a similar shared value of continuous improvement? Would they be able to review the CD Test questions together, discuss opportunities, and prioritize any process changes?
Or is this a new concept for the team, just beginning to consider spending effort on their process? Are team members willing to discuss things that are working, and those that aren’t? Are they willing to use those topics as leverage to make the team happier and more productive?
A retrospective focused on sharing this idea, building alignment across the team, and planning process changes will help any team no matter how familiar they are with the concept.
A Retrospective for Alignment
Most retro guides talk about having a prompted or focused retro. There are many agendas to choose from (again, see Agile Retrospectives for some options). A good choice for alignment building is the “Catapult”.
This retro scenario introduces the metaphor of using a catapult to fling yourself over a mountain to a destination. You draw the catapult, the mountain, and the destination all on your whiteboard.
(If you don’t like the idea of being flung over a mountain, there are different options. The Sailboat, The Balloon, and The Mountain Hiker are similar agendas that will work just as well.)
You discuss your current state. How is the team working today? How have you met team goals? How have you met product and business goals? Each key point gets a sticky note and goes near the catapult. Next, you discuss your desired, future state. What new product features are coming? And what business goals will they help achieve? Again, key points get stickies and goes to the board. The discussion here is important. You are building alignment about today and tomorrow.
Once there is alignment, the team lists the risks and challenges that could slow or prevent the journey. These stickies go on the mountain. Then list the helpers or boosters on stickies and put them “over” the mountain. At the end of the exercise, the team should have a shared understanding and a list of process changes (or next steps) for its CD journey.
Schedule this retro as part of the next release kickoff meeting or quarterly review. Find an experienced outside facilitator. Work with them on how best to introduce “process as product” and develop alignment around the concepts. A more aware team may be fine with Continuous Delivery as the desired state. A team which is earlier in their reflective journey may take better to CD ideas as part of the solutions to the agreed challenges. Lean on your facilitator for help navigating this space.
By the end of the retro you should have a good sense of your team’s concerns about the future, what they see as challenges, and their appetite for change. From here, you should be able to build a better team, process, and product.
Building a Retro Habit
Your team now has (even more) experience with retrospectives. And you have at least some team alignment about the process being a product that can get better with iteration. Harness this momentum and make your retros weekly. Keep the discussion and experimentation going.
Keep weekly retros on the team calendar. Introduce more concepts from Continuous Delivery as prompts for discussion. Or suggest them as potential solutions to the problems the team discusses. Process through the artifacts from your Catapult retro. Use different retro formats and new prompts to keep retros lively. Show the team that working together means talking about working even better than they are today.
Retrospectives are the foundation for any great team. They build trust. They surface issues when they are painful. And they allow a team to improve continuously as they deliver continuously.