A warm welcome to Rico Trevisan, today’s guest of the Mentor Hours section where we ask one burning question to learn from an expert.

Want to learn from hundreds of world-class experts? Check out Standuply Mentors.

Rico Trevisan is the Agile coach & trainer with over 10 years of experience having a passion for supporting product owners and HR teams. So, let’s hear him speak.

Today’s question: How to implement Agile in a large and bureaucratic organization?

Rico’s answer:

This is how I would approach this task.

Implementing Agile in an organization: Assumptions and challenge

So there are quite some assumptions here. I would start with these three:

• СEO involvement
• Big appetite
• Customer-facing

First, I would assume that you have CEO involvement. That will lead to having a big appetite, meaning they’re not just doing something to check some checkbox, or some feature list or to post that on their LinkedIn feed.

It’s something meaningful: maybe their backs are against the wall, there are some market pressures that dictate that.

The one leads to the other one here, and then the last one should be customer-facing, should be something external but just some internal, the cost-saving effort that they have.

The big challenge for a situation like this is that this bank will have to close the feedback loop as quickly as possible.

What do I assume has happened to such organizations is that they have grown and they have been able to serve the clients repetitively well.

As they repeat this process, they improve how they execute this process, and that leads to silos in a hierarchy or a hierarchy that is set up in a way that optimizes for cost efficiencies, for resource efficiency.

And that could be that the market has moved now and now that is no longer an advantage — it is something that hinders their progress.

So this closing in a feedback loop, would be the big challenge for them to say, “Okay, how do we get out of this old structure to get in a way that we want to listen to our clients better and better?”

In order to achieve this, to close this feedback loop, you have to go through existing silos/barriers/inefficiencies. To go through that process efficiently, you have to have the mandate.

One way to illustrate this: imagine you have a customer journey going from left to right. Overlay that on top of the company’s hierarchy.

The customer’s journey “goes through” different departments. These hierarchical structures have likely grown to optimize cost, resource allocation and customer satisfaction has taken a back seat to that.

That’s why I state that going “grassroots” will be difficult. It almost doesn’t matter how good the people with whom you’re collaborating. The pressure against are enormous.

The challenge would be that they are like a little seed in-ground, in a pot that is probably subconsciously unintentionally set up against their incentives.

They may have HR practices that don’t foster collaboration, bonus policies, etc.. there’s a vast array of established stuff that you will have to break through to achieve a shorter feedback loop.

That’s why I would shy away from trying to start a transformation at the grassroots level.

The other alternative is starting the transformation at director’s level. At level, there’s still friction, but it’s more doable. As a first step, I would try to move the conversation upwards, see if we can get buy-in from the highest levels.

Implementing Agile in an organization: Roadmap

So how would we go about this?

I’ll look at the Roadmap (see below) and break it down into three parts.

Kick-off Agile Change Team ⟶ Kick-off first Pilot Team ⟶ Scaling Agile Initiative.

If you look at the Agile Team, we want to gather enough cross-functional senior managers plus an Agile expert to put together a few things: to lead this experiment, to remove impediments – probably the single most important responsibility – and identify improvements.

Also, this group will be leading the direction of the Agile transformation.

From there, we’re going to Kick off this Pilot Team: this will be the proving grounds for this Agile experiment and their experience, their learning will guide the creation this Agile Paybook, let’s call it the new operating model.

Then from there on, we can start looking at Scaling the Agile Initiative. From then on we can start looking at Scaling the Agile Initiative. That new operating model will come from the Agile Playbook.

And we need to understand the culture and infrastructure necessary to foster agility.

Let’s dive deeper into the details of each step.

Kick-off Agile Change Team

At the start of the Agile initiative, the purpose should be clarified to ensure the impacted group is aligned. During this phase, we work with the core team on topics such as:

• Who is leading this program/initiative?
• Who are the members of the ACT?
• Why is the organization undertaking this initiative?
• What is the scope of this team?
• What does success look like?
• How could we measure it?
• Who are our stakeholders?

Kick-off an Agile Pilot Team

I will assume that the team is doing Scrum. Yes, there are many other frameworks, but Scrum probably makes the most sense.

We’re going to have four big steps.

✔️ Step #1

The first one is making sure we have our project charter or business case – whatever it is they call it – the thing that we’re going to do.

So we need to figure out the scope.

Define the metrics of the success of this project. What are the key assumptions to test? 

Let’s say we went through some workshops: figure out what is it our customers don’t have.

Define the metrics of the success of this project. What are the key assumptions to test? 

Let’s say we went through some workshops: figure out what is it our customers don’t have.

• What are the challenges they have?
• What are the questions?
• What are the hypotheses that we have as a team?
• What are the things that we want to tackle?
• What are those assumptions that we want to test?

And then we need to get this high-level business case; we’re going to do it like it is a very deep business case with a high-level scale: we should do this, we should do that.

And then look at the organization itself, look at the architecture: what are the applications that we’re going to touch?

Is it completely new?

✔️ Step #2

Team Setup and Training are quite straightforward: we want to make sure that we have a cross-functional set of skills, so we need to identify the skills, set up the team, make sure that we have all the right skills.

Kick off with training, make sure that they are aligned in the terminology.

Also just as important as kicking off is training for the people surrounding the team. The stakeholders need to be aware of what it’s going to change, how this new project is going to be different from the projects in the past.

✔️ Step #3

From there on, we can start having the Inception/Ideation: workshops with the stakeholders and the Scrum team to create this initial backlog.

There are many different types of workshops we can do: the user story wrapping, know design thinking — [use] those together openly and transparently, what are the things that we’re going to build?

And definitely, it should be aligned with operations, “Look, this is what we plan to release.”

We want to make sure that they repaved in the road here to succeed.

There are many different types of workshops we can do: user story mapping, design sprints, etc.. The goal is to do this openly and transparently.

And definitely, it should be aligned with operations. Ensure the team shares their plan to release and they collaborate to ensure the team can release.

✔️ Step #4

Then from there on, there are the Developments Sprints. We talk here about two weeks sprints, but this can be adjusted.

And the Sprint review should be public: this is a part of doing the work, showing the work, but also marketing this new way of working.

You need to gain some sort of traction culturally inside, “Look, there’s something different happening. Things can change; there’s change happening.”

We want to invite as many stakeholders as possible, be as public as possible, and maybe publish/push some information out towards the rest of the organization.

Scaling the AgileInitiative

As soon as that is well-running, we need to look at how to scale this initiative.

The Agile Team continues existing, we’re going to look at the Agile Steerco.

✔️ Agile Steerco

The Agile Steerco cares and safeguards this new part of the organization. Some call it a lab or an incubator. Whatever: it is somewhere “different” than the rest of the organization.

A good idea is to do a roadshow to people who sponsor and manage projects, talking about the benefits of Agile. Share the success stories of the pilot project and say, “If you want this, this is our selection criteria. If you would like these results, please apply.” This creates pull – “I want to run my project in Agile way” –  instead of a pull – “You HAVE to…”

The Steerco is made up of senior members across different departments. They evaluate the potential of Agile for the organization continuously, decide on which projects are pulled in.

And very importantly, they’re going to be removing the lab’s impediments and then also sharing the learnings throughout the organization.

So make sure it’s really smooth, and it’s being marketed towards the organization.

✔️ Agile Change Team

And then the Agile Change Team will be the owner of this improvement backlog.

As the teams go through those Sprints, they’re going to be escalating or highlighting impediments.

The Agile Change Team is pulling these impediments into potential improvements for the lab — either they execute themselves or use the Agile Steerco to resolve these things.

This is the main tool Agile Change Team will have — the improvement backlog. 

Then they’re going to have to be working with this team here to build this culture and also ensuring that it’s not only a culture but the infrastructure where all the tools are in their place of the environment, the technical environment is in place in order to get this feedback loop as short as possible. 

And all of those learnings go into this Playbook. This Playbook will be used to gather all the lessons, ideas, tools, techniques, case studies.

Everything goes into this playbook.

Its whole goal is to help new projects kicking off to get quicker from zero to moving. Timing-wise, here’s an overview of the different phases. 

It takes about two to six weeks to figure out know where is our ACT Team, what is our vision and putting that together intermittently.

Some of them I list here as “2 to 10 coaching days” — we’re doing workshops, kicking off, having meetings, pitching to different people to kick this off.

Kick-off Pilot Team

It probably takes about 12 to 24 weeks. It depends on each organization.

The work here for the ACT Team is to support the pilot project, so most of the effort should be on this side here.

They’re doing the work that we were talking about: the project charter, the team setup, the backlog, doing the sprints.

Supporting the Pilot, learning from this and already preparing, “Okay, how would we scale this?” 

We start working at the tail; after this has started off, start looking at how to scale this. 

✔️ Scaling part

This can be as long as you want, but there is probably a good amount of work here in the scaling preparation, an operating model, “Do we have specific training, onboarding steps that we’re going to take?”

Then we can start rolling out other teams: each team would take the focus of the ACT Team or the Coaching team. It takes 2 to 4 months.

The ACT Team takes two more teams in and certainly the same effort here to kick them off. 

Then you’re tracking how they’re going, you closing the cycle here, “How are we learning this?”

And as you’re learning this, you rolling out more and more teams, and hopefully, at this point, you start getting internal champions to become coaches themselves.

They have gone through this experience, they know how to do it, they can coach other people — internal people contribute directly to this operating model.

And the initiative is growing roots within the organization. It’s something I’d say mostly owned by the outside.

Here we’re going to track the progress and the maturity of these different teams, you know, sort of assessment.

They understand, “After I went through all of this, what else should I improve? how two other teams get to maturity?”

✔️ Questions to myself

Also, as a manager, I want to see all these different teams: where do I focus my effort.

• Which team has the lowest level of maturity?
• How can I help them grow?
• What are some of the things that a mature team should be doing?
• What kind of habits do they have?

For example, we have a task board; we pick up the highest priority item; we help each other reduce work in progress.

There is a whole maturity assessment you can create to have an open conversation with the teams so that they know what they could improve on.

Also, as a manager, as an organization, I know which team I should help and how I should help them. 

This is how I would look at the Kicking off a team.

Again, to recap, I’m taking a few assumptions –  top-level support and a good call to action – from there, we can start kicking off this transformation, by kicking off a Pilot Team, and then start scaling.

That’s it. I hope it helps.

Thanks, Rico, for your wisdom!

You can reach out to Rico Trevisan at Standuply Mentors to ask for his advice.