In the previous article “Build a culture of learning by amplifying team wins” I talked about how categorising ‘wins’ can support an improvement program. In this article, we will extend on this and explore how you can identify and build your capability model enabling you to better talk about what good looks like. This model is the cornerstone of such an improvement program and can help accelerate your engineering quality culture by providing a simple framework for a team and a consistent set of areas when celebrating success.

To provide a practical example in this article, we will take inspiration from the ‘Quality Culture Transition Guide’ by Alan Page.

The Quality Culture Transition guide uses the following range;

Beginning ➡ Growing ➡ Competent ➡ Optimising

I’ve replaced the original wording of ‘Chaos’ with ‘Beginning’ as I’ve found this word, for me, to better describe the start of a journey. I’ll be using this replacement throughout the article.

It has eight attributes of a quality culture;

1. Testing Breadth
2. Quality and Test Ownership
3. Technical Debt and Maintenance
4. Code Quality and Tools
5. Customer Data Analysis (Analytics)
6. Development Approach
7. Learning & Improvement
8. Quality Culture and Leadership Support

Why you might want to tailor your model

One approach is to use the whole contents of the Quality Culture Transition guide. It provides a useful starting point and is ready to use with minimal effort.

Using Alan’s definitions for each section can work well, and I recommend you take inspiration from them, but there are reasons why you might want to create your own;

• They are more tailored to your context and work environment
• It can empower the team with a sense of direction they can influence
• It can have a greater sense of ownership if created by the team
• They allow for variances per team
• It creates a platform for teams to discuss what good looks to them

The important part is that the categories remain consistent across teams to enable and promote cross-team sharing.

Creating your Quality Culture Transition Guide

Ideally, this would be done on a team-by-team basis but needs careful consideration of the current working practices across your department.

If your department is small, or maybe just scaling, and you would prefer a single transition guide to be shared across teams then having representation from all teams and disciplines could be a sensible starting point.

If you already have specific expected working patterns and practices across the department remember to add these to the definitions you create. It’s very likely that when the team talk about good practices they will naturally list some of the ones you are currently doing.

The result will commonly be a mixture of current behaviours and aspirations for future improvements.

Creating the whole model versus concentrating on similar slices

Before you begin the workshop decide if you are going to create the whole set of definitions for the model with the team or break it down into smaller pieces.

Some teams like to work on defining the sections in one go, others prefer to tackle it piece by piece over an elapsed time.

Building the whole model first

😀 If the opportunity to complete it in one go exists, then that is often favourable as conversations in one category can help to inform others.
🤔 This requires longer dedicated time with a team and opportunities for that are harder to plan and manage. Such an opportunity might come from a newly formed team or a team going through a reboot.

Working on similar slices

Instead of doing all eight sections in one go this could be cut in half and have the team pick one from each area (Testing, Development, Approach) with the fourth being Quality culture and leadership support.

😀 This cuts the time in half and still covers all sections within the categories.
🤔 This is a good compromise but still is only half the picture.

Working on each category at a time

😀 This might be useful if the team already has an idea of which area they would like to improve first. It takes less time and allows them to start quicker.
😀 This can cut down on the context switching between each category.

🤔 It might miss the bigger picture and constraint opportunities to improve and experiment in other areas.
🤔 Completing each of the eight slices over a few weeks runs the risk of team fatigue.

1️⃣ Building a shared understanding

• Ask the team for their understanding of what both the categories mean, to them, as well as the ranges used. It's okay if these mean different things to different people but it is important that for this exercise the team agree on a common definition.
• Ensure that all voices of the team are heard and a common understanding is reached in terms of what the sections mean to the team, and for different members of the team.

🗒️ Facilitator notes: During the discussions around the categories, ideas for optimising might also come while the team is talking and they should be collected/highlighted to be used later in the workshop.

2️⃣ Completing the corners of Beginning & Optimising

Instead of working through the range from left to right in order we instead will focus on the two edges; Beginning and Optimising.

It’s often easier to think of boundaries than the separate steps that might be needed to get from the perceived start to the end.

Beginning

A suggested approach, and to enable the team to have some fun at the start, would be to use a short style anti-pattern workshop similar to Triz.

• Simply ask the team ‘What are the worse ways of working you could imagine concerning ‘Quality and Test Ownership’?
• Encourage the team to have some fun and don’t limit their imagination
• Gather together the suggestions and turn them into a meaningful definition for ‘Beginning’.

Optimising

• Now ask the team ‘What are the best ways of working we could imagine concerning ‘Quality and Test Ownership’?
• The team can use the recently completed ‘Beginning’ to help them look forward.
• Gather together the suggestions and turn them into a meaningful definition for ‘Optimising’.

3️⃣ Deciding where you are and defining what you do next

Using beginning and optimising to frame the boundaries the team decides where they think they are.

The scoring isn’t important but it has to be something that the whole team agree with.

🗒️ Facilitator notes: You might find it interesting to ask the team to silently decide where they think they are as the following discussions can often bring out hidden assumptions, especially if there is a range of views across the team.

🗒️ Facilitator notes: Guide the team away from potential arguments around where they are and remind them the important thing isn’t the model, it’s what they decide to improve next using the model as a guide.

Depending on where the team thinks they are they will then complete a definition.

Not all definitions will be completed at the end of the exercise.

• If the team thinks they are in ‘Beginning’ they decide on what the definition of ‘Growing’ looks like which helps them on the journey to ‘Optimising’.
• If the team thinks they are in ‘Growing’ they decide on what the definition of ‘Competent’ looks like which helps them on the journey to ‘Optimising’.
• If the team thinks they are in ‘Competent’ they decide on what this definition looks like.

At the end of this exercise, the team should have an idea of where they are and importantly what they might need to do next.

Note that ‘Optimising’ at this point is just a hypothesis. As the team learn from each experiment on the journey, they might change their view of what it means to be ‘Optimising’ in the future.

4️⃣ Repeat for each category

Depending on how you have decided to tackle building up the model iterate over the other categories.

5️⃣ The first experiment & sharing past success

The team has decided where it thinks it is and has a framework to revisit progress or regress at a future date.

At this point, the model should be completed depending on how you decided to slice it and ready to use. While not strictly necessary I would encourage you to ask the team to decide;

• One area on the model where they can share a practice or an experiment. This ties nicely into the previous article “Build a culture of learning by amplifying team wins”
• One area on the model that they would like to get better at.

Doing this encourages the sharing of practices that might immediately help other teams and starts to create a culture of sharing and improving.

By focusing on one area to start with the team come away with direct action to follow up on. This also helps limit the potentially overwhelming nature of seeing lots of areas of improvement within the Quality Culture Transition Guide. Much like within a retrospective where a team might choose one area from a range of suggestions. It’s a focus on action.

It's about the journey

The model you create with your team shouldn’t be seen as a race to the end. It's a journey that you will undertake together.

Be mindful that your ‘Optimising’ state might seem like an unrealistic target, instead simply focus on what your next step will be. That is much more achievable.

Take stock of where you have got to and celebrate your success. Constant marching forward can be tiring for you and your team, remember to rest and reflect.

Not starting your journey might seem like an obvious statement but ensure there is time during your daily work to continue moving forward.

Circumstances and context can change. Maybe the way you work isn’t as optimal as it once was. Has an external change meant that you have gone back to a previous state?

You can end up in a comfort zone, viewing your successes and not letting go of things that no longer serve you, not changing to fit the new circumstances. But once you realise that circumstances have changed, you can, too.

As the team learns and evolves encourage them to update their definitions to reflect the journey they have taken so that others can benefit from their experiences.

As teams improve they will have a better idea of what good looks like so you might find that at the Optimising stage, the team asks ‘What’s next?’. Support the team with this decision and consider;

• Is there more they would like to do?
• Do they want to pause and help others get to the same point?

Leadership support

Inspiration of what good looks like might take several forms. Perhaps you have a Team Charter (or Canvas), or perhaps your company has a Technology Radar (covering Techniques, Tools, Platforms, and Frameworks) that you can draw from. Maybe a direction has been set related to one, or all, of the categories by senior management, staff engineers, architects, agile coaches, etc.

Any Quality Culture Transition Guide should be a mixture of agreed company software practices and team aspirations for improvement.

Some of these aspirations might need leadership support (budget for training for example) so remember to seek their opinion and share your experiments.

In time, some of these aspirations once proven by a team might become agreed software department practices. For that to have a greater chance of success engage with those with an interest in what good might look like.

Nothings perfect

When starting this with a team please keep in mind that;

No model is perfect: Any model is a simplification; wrong, but hopefully useful in aiding discussions with a focus on action.

It is not a rule book or a blueprint: It is a living agreement on how you might, or want, to do better.

It is not static: It will evolve as you and your team learn and grow together.

The goal here isn’t about creating a Quality Culture Transition Guide it’s about bringing a team together around a common understanding of what good could look like for them. It’s about being inspirational but practical, providing guidance in a format that is easily shared and understood.

Ultimately the success of this isn’t the creation of your Quality Culture Transition Guide (although it is a good start) it is about what you do next, and I can’t wait to see what you do next 😁