Talk about Agile at scale in 30 minutes

As part of my current mission, I provide support around the implementation of Agility at scale. This concept remaining quite vague for people outside the process, I was asked to present the current organization to a group likely to join us in the near future. For this, I had 30 minutes to structure, including questions and answers.

I share with you in this article how I approached the subject!

Happy reading 🙂

Context of the request

As part of my current mission, I was asked to give a presentation around the organization of Agility at the current scale to a group of people likely to join us.

Here is the information at my disposal as well as my associated reflections:

• The group is about 20 people
  • an activity or an exchange could be possible with this number of people rather than making a top-down presentation

• This presentation is the 4th and last of a series of presentations that will take place during this session
  • the format should be interactive enough to keep the group's energy remaining
  • live scribing seems to me to be a good way to convey ideas while maintaining the attention of the participants

• The duration granted to me is therefore 30 minutes and the suggested format is 10 minutes of presentation + 20 minutes of discussion
  • either I try to fit into this framework
  • either I change the situation while respecting the global timebox of 30 minutes

• The level of knowledge of Agility of the participants is not not very clear
  • Even if this is repetition for some, it seems inevitable to me not to talk a little about Agility to align everyone on the intentions and especially the associated vocabulary

• The goal is to make the presentation as concrete possible in order to be able to embark people
  • It's hard for me to imagine talking “concretely” about the current organization in the space of 10 minutes. It all depends on what we put behind this term you will tell me
  • I therefore need to find a common thread that is clear enough to explain to people what has brought us to the organization as it is today, with its qualities and its faults.

Finally, let's see how I decided to structure my message.

Structuring of the message

Taking into account the various elements mentioned above, I finally decided to build my message as follows:

Part 1: Agile 

My intention in this part is to introduce Agility from an angle in order to explain the intentions that we seek to achieve. In order not to remain too vague, I will take the first Agile principle and dissect it to extract the main messages. I will use it later to introduce the second part.

This first part will be the subject of a slide because there was a little too much text for my taste in the first principle to rewrite! 😛

Part 2: Scrum

In this second part, my intention is to explain the mode of operation of a team that seeks to achieve the objectives specified just before. We will discuss here the vocabulary related to the Scrum roles and we will introduce the events that punctuate the life of the different teams.

I decided to start scribing from this part to make the speech more lively and to generate exchanges as I go along.

Part 3: Agility at Scale

In this last part, my intention will be to explain the choice of the current organization which in one block can be a little difficult to digest. I would therefore start from the potential alignment and synchronization issues that arise from several Agile teams operating independently of each other. This will allow me to introduce the term "Tribe" at the same time.

This part will also be scribbled in order to give a general image of the Agile organization currently implemented and which will allow me to project the official organization slide afterwards which should map with my speech! 🙂

I will close with some photos of the PI Planning in which we participated a few weeks ago to give a concrete touch before leaving!

Let's see what the speech may have looked like! 😉

Description of speech

Part 1: Agile

To talk about Agile organization, it seems important to me to quickly recall what is meant by Agile or Agility. For this, I took the liberty of taking the first principle underlying the Agile Manifesto, which is called:

Satisfy the customer by quickly and regularly delivering features with high added value.

Let’s break the principle down into several parts:

To satisfy the client

We are primarily talking here about satisfaction of the need customer (and not from the specification). We also accept that a need is not always clear and especially that it evolves over time. It is therefore necessary to develop an organization that will have the ability to adapt to the unexpected and to these continual changes.

Deliver quickly and regularly

We are talking here about a scale of the order of a few weeks rather than a few months. Indeed, we will try to iterate on the solution in order to see if we are going in the right direction. Otherwise, it will be easier for us to fit and especially the impact oferror will be less. We therefore leave ourselves the opportunity tolearn continuously.

Indeed, it is this first delivery that will allow us to see if our initial assumptions were the right ones and if we are going in the right direction.

Features with great added value

By using the term “great added value”, we imply that others have less. Indeed, if everything is urgent and important, it no longer makes much sense. We then seek to prioritize continuously and to order all the constituent elements of the need: each cannot be at the same level as another.

The mode of operation that we are looking for then relies on a greater autonomy teams (particularly in terms of decision-making), greater responsibility and especially moreinteractions.

Part 2: Scrum

After talking about the intentions of Agility, let's see how it works today within a team.

Each team now has 3 distinct roles to meet the 3 objectives mentioned above:

• Product Owner : in charge of sharing a clear vision and the continuous prioritization of the constituent elements of the need
• Scrum Master : in charge of the efficient and regular delivery of valuable items
• Production Team : in charge of the solution to best meet the expressed need and therefore customer satisfaction

This is what is now called a "Squad".

The life of this Squad revolves around 4 major events, which will be repeated in successive time boxes:

• An event of Schedule : during which the team as a whole will agree on what it feels able to achieve during the given period of time
• A Daily : during which the team will decide together on what it intends to achieve during the day - it's a schedule on the scale of the day if you want
• A Review : where we will analyze with the stakeholders what the Squad has managed to produce to define what would be most relevant to do next
• A Retrospective : allowing the Squad to improve its mode of operation

Now, suppose multiple Squads are operating independently while contributing to the same functional area. One could have a rhythm of 2 weeks, the other of 3 weeks etc…

It could then be that functional alignment and synchronization problems appear.

This is where we are going to talk about Agile at scale.

Part 3: Agility at Scale

To answer the problems of alignment and synchronization, we will simply:

• Alignment : have a functional coherence and an overall arbitration
• Synchronization : make the Squads leave and arrive at the same time

The decision was to opt for 2 week time boxes.

We then scale the roles:

• THE Product Manager : a bit like a coordinator of the Product Owners, his mission is to guarantee the functional coherence of the whole.
• THE Release Train Engineer : a bit like a Scrum Masters coordinator, his mission is to guarantee the organizational coherence and the efficiency of the whole.
• There Design Authority : at each additional level, it is necessary to add a layer of global structural coherence. This is the role that this committee will take on to guarantee the technical consistency of the whole.

To this triptych, we add a Squad called the System Team, acting in support of the other Squads, to guarantee the ability to deliver the whole. It addresses topics related to infrastructure, continuous delivery and continuous deployment in particular.

To talk about all of the Squads together with these new scale roles, we talk about Tribe.

Now, let's look at the events mentioned above and scale them:

• The Schedule becomes the IP (Program Increment) Schedule : a Planning event for all members of the Tribe
• The Daily becomes a Weekly to adapt to the time scale of the Tribe and will take 2 distinct forms:
  • A Scrum of Scrum bringing together all the Scrum Masters
  • A PO Sync bringing together all the Product Owners
•  The Review becomes a review of theIncrement produced by the Tribe after 6 iterations of 2 weeks
•  The Squad Retrospective becomes a Retrospective at the level of the Tribe

Here is the organization to which you will be able to contribute if you come to join us! 🙂

Conclusion

The presentation seems to have been well appreciated and is well within the timing of 30 minutes including questions. For my part, I had a lot of fun telling the story in this way and scribbling it live even if it was the first time I did it. My style is nevertheless very simplistic, I still have a long way to progress ahead of me!

I am more and more convinced of the power of the visual in presentations and I encourage you to go there even if it can appear a little disruptive in the organizations in which you are: believe me, it is a non-issue! 🙂

In any case, I hope that this article can inspire you to tackle the subject of Agility at scale, which is so common today!

Your feedback and suggestions are welcome 🙂