#AgileAfrica Keynote: Alignment at Scale

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

I was very excited at the fact that Henrik Kniberg was presenting at Agile Africa this year. And his opening keynote did not disappoint. First, he made it clear what he meant by Scale. He didn’t mean a couple of teams, or even many teams working on different teams working on separate things – he meant numerous team with various inter-dependencies. And then he told us some ways we could avoid becoming “unagile” when working with lots of teams.

 

He said that the first thing to realise is that for such a complicated ecosystem to work, you want everyone to be operating from a space of high autonomy and high alignment. When you achieve that, then everyone understands the problem and also has the mandate to figure out how to solve it. 

Kniberg then introduced the concept of a “soup” of ingredients required for an environment in which many teams could thrive and continue to operate in an agile fashion. The ingredients of his soup included:

1. Shared Purpose
2. Transparency
3. Feedback Loops
4. Clear Priorities
5. Organisational Learning

1. Shared Purpose

Kniberg emphasised that in order for everyone to have a shared purpose, over-communication was essential. Every team member needs to be in a position where they are able to answer the questions:

• What are you working on?
• Why are you working on it – what is its impact?
• How will you measure when it is done?

He described the following top-down model as an example:

1. The company agrees on their beliefs. This belief relates to how they are to remain a viable operation. It could be around how the company believes they make money; who their customers are; or what is likely to happen in the future.
2. Beliefs then break down into North Star Goals. This is a goal that the organisation wants to achieve in order to realise a belief. It needs to have metrics.
3. Goals are then broken down into “Bets“. It is called a bet because it is a hypothesis: if we do this, then we think (bet) that this will be the impact on our goal.
4. And, finally, teams have goals which contribute to proving or disproving bets (Kniberg called these tribe goals).

2. Transparency

Being clear about what everyone is working on and why helps to provide context that enables autonomous teams to make intentional rather than accidental decisions. One of the tools Kniberg shared with us was the DIBB Framework.

DIBB Framework

DIBB stands for Data, Insights, Belief and Bets. Basically you have a single space listing all the prioritised Bets and it is very clear what data was used to generate insights that led to the Bets, and then the Belief that particular Bet relates too. Bets can be tracked on a single Kanban taskboard with the columns: Now (what we’re working on now); Next (the Bets we will work on next); and Later (not priority for now). Kniberg emphasised that all of this information should be in a simple format that was easy to share with all (one of the companies he worked for used a simple spreadsheet).

3. Feedback Loops

We all know feedback loops are important. Feedback loops help us adjust our course. Scrum and other Agile frameworks already have built-in feedback loops for single teams. It is necessary to increase the feedback loops to cover multiple teams when scaling. Examples of multi-team feedback loops could be a Scrum of Scrums, multi-team retrospectives, Friday demos, Whole Product Review or Alignment Events, and Management Reviews.

Whole Product Review

A whole product review is when all the teams working on a particular product (whether building features or working as a support team) get together to plan for their next timebox. It includes the following components:

• A demo by each team of what they have done since the last Product Review (to create context)
• Break-outs per team to plan ahead for the next timebox.
• Creation of Team Boards that include
  • The goals for the next timebox ordered by impact
  • Stretch goals for the next timebox – these may not be achieved
  • Risks in the next timebox
  • The deliverables that will be delivered at the end of the next timebox
• A management review of the team boards on the same day before the next timebox starts

Triple Feedback Loop

This actually came out of a conversation I was listening to during one of the Fish Bowl sessions at the conference (and not from Kniberg), but an idea for these multi-level feedback loops could be:

1. Normal team reviews (Loop 1)
2. Monthly product reviews (Loop 2 – with all the teams)
3. Quarterly Sponsor review (Loop 3 whole day with team and management)

4. Ordered Clear Priorities

Ordered priorities help teams make the right decisions when trade-offs are required. Priorities should feed down into teams from the Company Beliefs and North Star Goals. Clear priorities help teams answer the questions “If we can only do one, which one would we do and why?”.

5. Organisational Learning

In order to improve, we need to learn. We cannot learn if we don’t have time to stop and process feedback that we receive. Or have time to practice skills we are growing. Kniberg suggested a couple of ways to create slack time in teams:

• A pull team schedule where teams pull work as they have capacity to do it
• Scheduled slack time e.g. retrospectives, gaps in sprints, etc.
• A culture of promoting learning over busyness

Some ideas for cross-team learning:

• Holding “Lunch and Learn” events where teams get together in an informal session to discuss a particular topic
• Cross-team retrospectives
• Embedding team members i.e. having a team member from the team that is sharing temporarily sit with the team that is learning

 The last part of the keynote dealt with the “chef”. The chef is the person who ensures all the ingredients are available for the soup and continuously tweaks them to ensure the soup is as tasty as possible. In traditional organisations, we used to call this person or persons “leaders”. Leaders are not there to tell the team how to solve the problem. They are there to ensure that the team environment contains the ingredients for autonomy and alignments.

Leader chefs:

• Create a shared sense of accountability
• Enable teams to align their decisions to company goals and with other teams
• Ensure that decisions can be made through transparency and clear ordering of priorities
• Create slack

My main take-outs were:

• Intentional rather than accidental decisions
• Scaling needs autonomous teams that are aligned
• Some cool ideas for creating top-down goal alignment and transparency
• Some cool ideas for creating peer-alignment and transparency
• The role of leaders in an Agile set-up

What were yours?

 

With thanks to sketchingscrummaster.com