Team Alignment with OKR

Team alignment refers to the joint orientation of all team members towards shared goals so that local decisions can be made without constant queries from managers. Concrete metrics, such as the number of defects broken through or customer feedback figures, make progress visible. Three to five such metrics are considered a useful orientation.

Key Takeaways

• Alignment means agreeing on common goals and their priority so that teams can make small decisions locally and without upward consultation.
• Three to five metrics per goal are a sensible order of magnitude, whereby health metrics must always balance the picture alongside goal-oriented metrics so that no one blindly optimizes towards a single key figure.
• Metrics must not become an end in themselves: If you only want to achieve one number, you lose sight of the actual goal, namely satisfied customers with low-defect products.
• Goals lose their impact in everyday life if no one actively upholds them; this can be done by anyone in the team, not just the manager, for example in informal discussions.

What does alignment mean in software development?

Alignment means agreeing on what is really important. In many companies, one corner moves to the left, the other to the right, especially at middle management level, where career thinking also plays a role. Alignment aligns forces towards common goals.

Urs Reupke makes a clear distinction between alignment and focus. Alignment occurs when everyone agrees on the challenge: that it is important, that it must be tackled and in what way. Focus follows when the team concentrates on a specific solution and follows it through.

The real leverage lies in the relationship between top and bottom. Once the big goals have been clarified, the small decisions can be made locally. A tester then doesn’t have to run to the project manager for every question: whether a bug is worth looking at more closely, whether there is still budget. The answer is determined by the objective.

Why late customer feedback is a quality problem

Customer satisfaction can often only be measured long after release, and that is too late. The product is built, delivered, then someone writes on Reddit or Facebook that it’s not the big hit. At this point, it doesn’t help to wish you had invested in quality assurance earlier.

The way out lies in subordinate goals and metrics that indicate a result earlier. If you want to increase customer satisfaction, you need signals during development, not afterwards. Otherwise, the stock market price is already in the basement when the feedback arrives.

A concrete example from test work: fewer defects arriving at the test group from development within a sprint or a month. This is a subordinate metric that controls earlier. It leads to a different attitude in testing.

As a software tester, how can I work with the developers so that they build it right the first time? Testing quality in, instead of testing bugs out afterwards.

• Urs Reupke

This is essentially the question that agile testers have been asking for years. What is new here is that it is backed up with metrics.

Which metrics are suitable for goal-driven work?

Almost anything in a book of product metrics, supplemented by business metrics, is useful. Urs mentions Pirate Metrics with stations such as Acquisition and Retention, plus classic quality metrics: Number of defects found, number of defects broken through, number of defects reported externally, broken down by criticality or priority. Turnover or subscribers gained are also included.

More important than the selection is the sequence in your head. You first determine which goal you want to achieve. Then you determine the metrics by which you can recognize that you have achieved it. And these metrics should be visible as early as possible during development so that they can guide your actions.

Three to five metrics are a good handful. Any more will blur the picture.

Target metrics need counterweights

Pure optimization towards a single goal is misleading. The image for this is a trip to Paris. The kilometers to the destination are one metric. Just as relevant is how much fuel is left in the tank and how alert the driver is. If you only look straight ahead, you will stop at some point along the way.

Urs calls this second type health metrics. They apply regardless of the specific goal and remain valid across goals. They strike a balance so that a team does not sacrifice everything for one goal.

The absurd extreme makes it clear: if the ultimate goal was to stop defects from entering production, the simplest solution would be to stop production. There must always be a counterbalance.

How not to lose sight of your goals in everyday life

The biggest enemy of a set goal is everyday life. Everyone knows this from the resolution to go to the gym from January 2. It lasts three weeks, then the dog gets sick, then the child, then you yourself, and at the end of March you wonder why you haven’t been there all month.

The countermeasure is leadership, and anyone can exercise leadership. A lot of it happens in the coffee kitchen. One sentence is often enough: We had agreed on this goal, I see you doing something else right now, do we still have the common goal? Hold the goal high and dare to address it when it slips out of sight.

Anyone who has studied habits knows the rule: don’t let a habit slip more than once. The second time it slips, it becomes a habit itself.

How to make the survey slim

Compiling the figures once a week is usually enough. If you do it more often, there is a lot of formalism, everyone stares at spreadsheets and nothing moves. An extended daily can be the framework.

In this appointment, you separate two things: the metrics that point to the goal and those that indicate whether you are otherwise on the right track. Enter data, compare with the previous week, move on. The effort must remain small, otherwise you are tripping yourself up.

If the figures don’t improve, pausing instead of taking action will help. Where did you take a wrong turn and where is the next exit to get back on track? In a team context, goals are usually well thought out enough that they are rarely thrown out. More often: the goal was right, you just need to focus on it again.

The burn-down chart shows the pattern on a small scale. The line stays flat for a long time, then everything falls on the last day. With a little experience, a team knows that it is usually enough in the end and can still work to ensure that the line runs downwards more evenly.

The metric must never take over from the goal

In the end, it’s the satisfied customer that counts, not the metric achieved. There is no point in being happy that a figure is below five. The goal is a good product that is as error-free as possible with features that users want.

As soon as a metric becomes an end in itself, it replaces the goal. That is not the point. When selecting metrics, you should make sure that each one is related to the benefits for the customer.

How a team starts on its own initiative

The first piece of advice is simple: just do it. Things rarely go wrong at team level when working in sprints or other iterations. After two weeks, you sit together again and see whether the path is right. In the worst case scenario, two or three hours have been invested that have achieved nothing.

Two things increase the hit rate. Firstly, someone who moderates the process so that different ideas become a common goal. Ideally, this should not be the manager themselves, as otherwise status issues will immediately arise, but a neutral facilitator, especially during the first few rounds. Secondly, don’t reinvent the wheel. There are enough books and overviews on which metrics others use. In the OKR environment, GitLab publishes its OKRs, which is a good illustration of what something like this looks like in documented form.

If it works, promote it. Nothing legitimizes like success. If it doesn’t work, others learn from what didn’t work. Both are Inspect and Adapt: pause, reorient yourself, on both a small and large scale.

Who belongs on the team that sets the goals?

Preferably the entire product level, realistically the narrower team context. If a program comprises 100 people, it’s not a Tuesday evening decision for Thursday. But for a team, it’s easy to get the group together.

No one is excluded because of their title or specialization. The team includes testers, developers, business intelligence and UX people, someone who keeps an eye on the stakeholders and the product owner, service owner or scrum master, if there is one. That quickly adds up to ten to fifteen people, which is still a manageable group. A smaller group can build a decision template, the larger group decides together.

Contradiction is part of the process and must be tolerated. A distinction helps here: Is the goal harmful, or does an individual just find another one better? In the second case, it is possible to convince or overrule. And even if someone thinks the goal is garbage, it is often good enough to commit to it for four weeks and try it out.

Known goals of the manager make local decisions easier

The manager doesn’t have to sit in the room when setting goals, but knowing their overarching goals helps enormously. If you know the annual goals or strategic agreements, you can take them into account when making your own decisions.

This becomes a simple guiding question for everyday life: What would our manager decide here, and how do I act in their interests? In this way, a conflict can be defused from the outset, simply through the knowledge that you have obtained beforehand.