Doing Agile Right: Darrell Rigby

Photo of Sohrab Salimi
Sohrab Salimi

Reading time
34 Minutes

Darrell Rigby, Partner & Director of Bain & Company and Head of Global Innovation & Agile Practices, was the fifth speaker at Agile100 in May 2020 and showed the extensive expertise he has acquired in more than 40 years as a consultant in his presentation on: “Doing Agile Right – Transformation Without Chaos”.

Regular readers of this blog know that Agile Transformation is a topic that also occupies our trainers. The talk is about the book of the same name that Darrell recently published. In his session he takes up the most important points of a functioning agile transformation and explains at the end with his companion, trainer of the Scrum Academy and moderator of Agile100, Sohrab Salimi, which points have to be fulfilled for a functioning and sustainable transformation.

How can we thrive?

More on Darrell Rigby

“We need to run the organization efficiently, we also need to adapt. Finding that balance is the tricky part.”

Darrell Rigby

Darrell Rigby is a Boston-based partner and director of Global Innovation and Agile Practices at Bain & Company. He is also the former head of Bain’s global retail consulting practice. During his forty-two years of consulting, Darrell Rigby has led assignments in a variety of industries, including innovative growth strategies for more than a hundred of the world’s leading companies.

Doing Agile Right – Transformation Without Chaos (agile100, May 2020)

Doing Agile Right: Transformation ohne Chaos

Transcript of "Doing Agile Right" with Darrell Rigby and Sohrab Salimi

Following up with Darrell Rigby. Darrell is a senior partner Director at Bain and Company. Bain and Company was my first employer when I finished med school. So I have close ties to that organization still and I'm super super excited that Darrell is joining us today. He leads the agile innovation practice. I think he's going to say a few words about himself. Once I hand over Darrell the stage is all yours.

Thanks for being here Sohrab! It's such a pleasure to be with you. Thank you very much.
My name is Darrelll Rigby. I have been with Bain for 42 years. I lead Bain's global innovation and agile practices and I am a very strong believer in agile and its ability to transform companies. In fact I guess over the past year I've had conversations with senior executives at more than 100 companies and it's fascinating as I talked to them.
The most common question by far is how can we build a business that will thrive in a world of unpredictable and accelerating change And I guess I probably shouldn't be surprised by that question because if you think about what senior executives are coping with these days they really do have to operate in an environment of constant crises and black swan events.

Black Swan events

(00:01:36,94) —  It is true that right now the center of attention seems to be this terrible pandemic disease.
But once that lightens up a little bit there will be other diseases and in addition to that there will be digital disruptions and terrorist events and military conflict conflicts and trade wars and social unrest and environmental crises and natural disasters.
There's just no end to the way this is the way this environment is hitting businesses these days.
And what I always tell them and what I would like to share with you today is that in order to achieve sustainable success in these kinds of dynamic environments businesses have to balance two vital activities.

  • First of all they have to run the business. Let's call that operations they have to run the business reliably efficiently.
  • Second of all they have to change the business. Let's call that innovation. They have to adapt to changes in the environment. They have to be able to move rapidly and effectively to do the right things at the right time.

And I know that a lot of agile zealots believe that the purpose of agile is to destroy standard operating procedures to destroy bureaucracy. I don't happen to believe that running the business and changing the business require different skills but they are complementary skills.
They need each other in order to be able to succeed in order to be able to thrive .

(00:03:30,83) —  If you think about evolution as a model for business you don't want every time a new baby cheetah or any other living organism is born you don't want to change everything about that organism. You want to keep the things that are working. You want to run those more efficiently than ever. But there are new traits that you need to adopt, you need to adapt to the environment and that's where these things need to come together.

Static and chaotic organizations

The only problem is that these bureaucracies that are so good at running the business have led to unbalanced systems that what we're trying to look for in an agile enterprise is the golden mean between having a static organization and having a chaotic organization.

So agile is not really the antithesis of stasis. Agile is the golden mean between creating a static organization and a chaotic organization. You can be out of balance in either dimension. But the problem is that bureaucracies have sort of overextended their influence
It's a little like kudzu is destroying everything in its path and it's not that bureaucracy is inherently evil.

(00:05:00,66) —  It's not that agility is inherently saintly but bureaucracies with their hierarchies of command and division of labor and specialist functions have created an environment where managers plan a senior executives plan and workers execute.
Then managers rigorously supervised the workers conformance to those plans.

They focus on producing products versus solving customer needs most of the time they get focused on producing things as opposed to solving customer needs predictability gets to be more important than breakthroughs.
We would rather have predictable results even if those results are not as strong as they could be.

And we start to believe that meeting quarterly earnings expectations is the most important thing that a company can do. So we pass up bigger opportunities that may have less predictable but better results.
And the real goal is to get people operating as predictably as machines. If we could just get them to do what they're told to do as efficiently as possible then we would view things as a success.

(00:06:27,84) —  What we try to do with agile is to rebalance this out of balance system. How do we re-inflate this capability to change the business The ability to do innovation For our book we did a lot of research on first of all does agile work and we were fortunate for the first time ever I think to pull together 70 research projects Hundreds of thousands of agile teams over the last 25 years and to assemble this data two test once and for all does Agile have this ability to improve balance and results And the answers are overwhelmingly yes.

First of all, innovation improves business results broadly. You can see the large number of the overwhelming percentage of research reports that prove that innovation helps businesses Number two that agile innovation is even better than regular innovation.

Now not 100% of the studies show that but overwhelmingly the answer is yes and almost never is the answer No. Some are inconclusive but look at the size of these green bars that say yes!

(00:07:51,88) —  Statistically there is empirical data that agile is working and that the benefits persist. When agile is scaled across many teams that agile works way beyond it and that agile enterprises can improve results. This is all very encouraging! I think when 70 to 90% of objective third party research reports are saying agile works Agile is a way to restore balance and improve results.

Agility is misunderstood and misapplied

There's only one problem and that is way too many companies are doing agile wrong and our biggest fear is that doing agile wrong is threatening to relegate agile to the scrap heap of management.

(00:08:51,13) —  Bain has the largest and longest running research on management tools and techniques.
And we've seen these patterns before we've seen what happens to re-engineering and quality circles when they get misused. And we're seeing all sorts of MS uses of agile just as an example and I'm not going to go through all of these but one of the most common problems we see is just increasing work in process and multitasking.

So senior executives will set up what they call agile teams but they're not agile teams. There are groups of 20 people with part time allocations to the teams who are multitasking and not working in agile fashion. They're mistaking faster predict-command and control-processes for agile. There are too many executives that define agile as doing what I say faster than before.

We're seeing many examples of bureaucratic big bang transformations and copycat agile. What I mean by that is a big bang transformation where the senior executives go behind closed doors for anywhere between 6 to 9 months.
They emerge with a very bureaucratic transition approach with a big huge program management office. With a restructured organisation with people who have gone through two whole days of agile training.

(00:10:33,51) —  And now we have a completely different organizational structure. People in different positions that frankly often don't know what they're doing but they are copying the organizational structure of some other company that is highly regarded.

Maybe Spotify for example. And so if Spotify has squads and tribes and chapters and then that's what we should be doing.
We’ll just take what Spotify is doing in their development and their engineering department and we will slap that on our entire corporation. Even though that's not what Spotify does.

By the way, we're seeing agile being used as a euphemism for layoffs. Let's start by laying off 20-30% of the organization. We’ll get these new efficiencies and then we'll be more agile.

Unfortunately what we're seeing is too many times these restructurings are actually destroying business unit accountabilities and are hurting performance. So again I don't want to go through all of these but let me just address a couple of them quickly. Let me start with this idea of ‘let's increase work in process’ because you know what happens when executives grow frustrated with insufficient innovation output.

The answer is easy. We'll just add more innovation projects then we'll have more innovation and will be more successful. I'm going to refer to uh Little's law here. That has an equation that says let me tell you why that doesn't work.
And that is if we assume that you can process let's say 10 projects per week or something like that and that we've got 100 projects in the system today then that says that the average Innovation project will be in the system for 10 weeks.

If all we do is add more projects to the system It's easy to calculate what will happen and that is we won't get more out. It's just that the average project will stay in for 100 weeks rather than 10 weeks

(00:12:56,24) —  And when work is in process for that long all sorts of bad things happen including customer needs changing competitors responding. And so it is likely that at the end of that 100 weeks by the time we actually release something into the market it is almost certainly going to be obsolete by the time it gets out.

Furthermore there's a concept called flow efficiency or velocity speed cycle times getting things into the market. Flow efficiency is easy to calculate. What we're really looking at is how long does it take for something to get into the system and out of the system. If we see a customer need how long does it take us to respond to that need and we can look at that total time and divide it up into two components.
How much of that time is spent working on the project and how much of that time is waiting? Well sadly it turns out that flow efficiently is seldom better than 15-20% for most companies.

That means we're spending most of our time waiting and reducing wait time therefore has five times the impact of working harder and working faster. So what are wait times? What do we spend waiting on? Well sometimes it's operating processes like strategic planning calendars. That only happens once a year. So we can't stop something that's failing until the year ends.
We can't start something that's urgent until the calendar begins. Maybe we're waiting on decision approvals. Maybe we're waiting on software release schedules or regulatory constraints or getting people allocated to the team's. Dozens of other factors that keep teams waiting.

And if companies start by firing operating and support people to pay for agile teams without reinventing those business processes. It just means we have fewer people to do the same amount of work.

(00:15:16,85) —  So we're going to increase that wait time and that leads to much slower speeds, longer queues, longer waits, more work in process.

Multitasking makes us stupid

And to make matters worse, managers who see this happening are so desperate to improve utilization rates and reduce costs they fill the wait time by giving people additional projects.

That means multitasking And we all know that multitasking makes us stupid. It reduces our IQs by 10 points. It reduces our focus and it just is a terrible thing to do to an agile team exacerbating wait times further slowing development cycles. And in the end, unfortunately, the speed of innovation actually decreases.

One of the major points I would love for you to leave remembering is that annual cycles are just silly. I don't know how we got to them. If you wonder what is special about a year?
The answer is it's only special because that's how long it takes the Earth to revolve around the sun. Now What a crazy way to do business! What a crazy way to do.

Strategy or budgeting or planning to say: “well I'm going to determine it all by how long it takes the Earth to go around the sun”.
Thank heavens you don't live on Neptune where it would take you 165 earth years in order to get an annual bonus!
It's just a crazy notion to say: “Well I can't deal with this because we're only a third of the way going around the sun. Once we complete our orbit then I'll get back to doing it.”

If you want to pick a planet's annual cycle then take Mercury. Because it goes around the sun every quarter. Maybe that's a better approach to doing things but don't limit yourself to being slowed by annual cycles.

(00:17:27,64) —  The other problem we have is that bureaucracies try to manage innovation programs just like they would manage any routine operation. And that is: we start by analyzing problems, we generate ideas, we predict very specific requirements. We design, we develop, we verify and test, we integrate, we deploy it and then we maintain it.

All of this frankly works quite well. If you are able to predict very specific requirements one year, two years in advance than bureaucratic predict-command and control-processes can actually work.

One third of all predictions are wrong!

The problem is that's not true! In fact two thirds of predictions are wrong!
I've tested this myself. I think of myself as being fairly intelligent and fairly able to predict. I tracked my predictions for about 18 months and they were wrong and I'm not alone.

(00:18:30,84) —  In fact there is a lot of research including this one on the left by a Professor Amar Body who looked at the Inc.500, the fastest growing private companies in the US and said: “You're very successful today, let's go back to your original business plan.”

How much did you have to change your original business plan to reach success? - The answer is 66%!
2/3rd of companies say we had to significantly change our business plan in order to succeed.

I've talked to many venture capital funds as well about when you originally fund a new business. How many of them stick to the plan and how many of them adapt in your most successful ventures? Again the answer is about two thirds of the time we have to change those plans.

Just a few examples I've mentioned to you. I've been with Bain for 42 years
I'm obviously very old. I did not grow up playing with iPads. I grew up playing with things like slinky these physical toys.

The interesting thing about slink ease is it was not invented as a toy. It was invented by an engineer who was trying to create springs that would help to balance sensitive instruments in turbulent seas.

But while he was working on that spring it fell onto a stack of books on a desk, on a chair, on the floor. Stood upright and he said pretty cool, this might make a good tool and it made a very successful toy. Slack is the fastest growing unicorn of all time.

(00:20:11,44) —  Uh slack did not start off as being a tool for sharing social experiences. It was a video game company. It went bankrupt. It's just that in the bankruptcy they found this tool in the back room and said well maybe we could release this as a product in the market and they did. And it took off.

Dare to make a pivot

Disney's Frozen is interesting to study because if you look at the original script and the original diagrams of Elsa. Elsa was an evil queen. She was intended to be like Cruella Deville or like Maleficent, like Ursula. She was an evil queen and then a husband and wife songwriting team came in and said: “We think she's misunderstood. Listen to this song and please indulge us while you listen to this. We know it changes things.”

They played a song called “Let It Go” and as people listened to it they said oh my goodness this changes everything! They made Anna and Elsa instead of friends sisters. People who love each other. They made Elsa misunderstood but changed the whole movie and it has led to enormous success.

(00:21:28,94) —  Many of you may be familiar with Youtube not sure you know how it got started. Youtube was an online video dating site for about a week. Not a single person posted an online video Date. And so they said well that's not working let's just open it up to people.

My main point is if there is only one thing that you take away from this discussion today it should be this 67% or 2/3rd of your predictions of anyone's predictions about anything significant will be wrong!

Only 12% of all transformation programs are successful

Therefore plan to adapt from the beginning. Plan to adapt! It is the only way to succeed. Interestingly enough, I find it fascinating that in these transformation programmes about 12% of major change initiatives - only 12% succeed!

(00:22:33,24) —  That's true of corporate programs. Bain has studied this. It's also true, interestingly enough, of new year's resolutions. Only 12% succeed. I don't think that's a coincidence. I think there is a common problem which is that people don't know how to change.

It's not that the goal is bad. It's not that they're doing wrong things. It's that they don't know how to change. So what I'd like to talk about next is how do you do this the right way? And again I don't need to go through all of this, but we have identified 10 keys to doing agile right.

Number one you have to know what you're doing. You have to have informed mindsets and methods. You shouldn't be launching a program when you have no clue how it actually works. You need clear and compelling objectives for these initiatives. You need metrics for tracking them.

And I know that the agile community loves to talk about tracking outcomes rather than activities and that's true, but you really need to track your inputs.

(00:23:41,37) —  How many people do we have that are skilled, our activities are outputs are outcomes and whether we're achieving our purposes. You have to do that in order to build a successful system. You have to create agile teams that are really agile teams with all of these characteristics. You have to have prioritized sequence transparent backlogs. You have road maps, you have adaptive roadmaps.

There's a common misconception that I think is killing agile that says, agile doesn't believe in planning. Nonsense. Agile plans? Agile has adaptive roadmaps rather than fixed plans. We have explicit roles and responsibilities for discovering and designing and developing and delivering these innovations.

We work in small batches with rapid feedback. A lot of people think that the purpose of these short sprints is to get people to work fast. Dead wrong!
The real purpose of having sprints finish so quickly is that we want to make sure that we're constantly getting rapid feedback from customers and just as importantly that we're creating frequent wins.

(00:24:57,15) —  There's a lot of research on teams that shows the most important thing you can do to keep a team motivated is let them see how they're winning as frequently as possible.

So if you're getting feedback, if you're learning, if you're seeing constant progress you're going to be far more motivated. Far more successful. You can quickly remove impediments and you set an energizing pace not a killer pace, not a burnout pace. Not a slow pace that is so slow that you're not going to reach escape velocity.

But you set an energizing pace that you can sustain our ambition as bane and as I am working with clients is very simple: We want to help companies build a business that will thrive in a world of unpredictable and accelerating change!

We have seen in this recent Covid crisis that a lot of companies are discussing agile almost by accident. They're not calling it agile all the time. But in the last week I've had five conversations with senior executives that are saying: “I have never been more proud of my organization”. We're moving faster. We're not getting bogged down. We're doing courageous things.

The goal is systematic innovation

And our objective is to turn those sporadic innovations into systematic innovations. So that we can sustain agility as these crises wax and wane as opposed to ‘oh we're agile during a crisis’. And then when it passes we go back to being bureaucratic and we forget how to do that.

And when the next crisis hits then we learn it all over again.We want to build a system for doing this. We want to gain strength and market share while these changes call sluggish competitors from the market. And we want people to look back and take pride in how the business delivers superior results by adhering to and balancing its purpose in crisis.

And that means we want customers who are grateful for what we're doing for them employees who are resilient. They're inspired to learn and grow shareholders who value enduring success over short lived profits and communities who are proud to have the organization and the business in their communities.

(00:27:23,74) —  That's what we're trying to do. And in order to do that what we believe is that agile enterprises will do three things:

  • Number one they'll run the business reliably and efficiently
  • Number two they'll change the business to capitalize on unpredictable opportunities
  • And then number three they will harmonize these two activities without destroying both elements

So they're going to run the business and try to minimise variability. That's the thing about operations. That's the reason that Lean Six Sigma got so popular in operations because we want predictable reliable efficient results.

We want to eliminate variation but changing the business innovation actually requires variation. We're trying to fight stagnation, we're trying to accelerate adaptation, so we're going to increase variability and then very quickly limit our losses from ineffective variations and grow our gains from successful variations. So that all we really see in that uh and that graph below is the top part of it the things that work well that we can grow successfully.

Fake Agile

(00:28:39,34) —  How do we do that? The answer is: we do it in agile ways. We don't do it in bureaucratic ways.
If you think about how ironic it is for any executive. To think about ‘we are going to create an agile enterprise’ that's our goal.

Now let's do that in the most bureaucratic way. We could possibly imagine. Set up a huge program management office, all sorts of control systems. Restructure the entire organization at the very beginning. - How ironic is it to believe that that's going to work?! The chances are slim to none.

Test, Learn, Adapt

Successful organizations believe that you achieve an agile enterprise in agile ways, and that means through testing and learning and adapting.
So we begin with agile teams. We proved the benefits of agile innovation teams. We build confidence in agile values and principles and practices and then we identify future opportunities and potential barriers to do that.

And over time we see traditional innovation shifting to more agile innovation and innovation as a whole gaining more of our resources and focus as opposed to routine operations. Almost never.

Agile Scaling

By the way will an organization get to running 100% in agile teams at a place like Spotify which is all based on digital innovation and new product development. Yes 50% of their people may end up operating on agile teams on a day to day basis.

(00:30:25,74) —  At most companies somewhere between 10, maybe 20 or 25% of people at any given time will be working on agile teams. Even when you become an agile enterprise. Once we prove that agile teams work then we move to agile at scale.

We start expanding agile teams to lots of different business units and functions. We increase the scale of agile initiatives. When you look at a company like Saab aeronautics for example they will have 100 agile teams working to build a fighter jet. To build the most effective cost efficient fighter jet in the world. And they'll increase the collaboration between innovations and operations.

And then once we've mastered agile at scale, then we'll move to creating an agile enterprise and will balance this business system to run efficiently and adapt quickly.

We’ll embed these agile principles and values in every performance unit and the senior executive team. This team itself will be running as an agile team. And it will be viewing its primary product as we're supposed to build an agile system.

So let's do that in agile ways. Now this is different from the way a lot of people think about scaling agile or building an agile enterprise.

(00:31:52,57) —  I know this is a little complicated. I want to take just a couple of minutes to describe it. Because most people have a sense that the way you do agile, the way you create agile at scale is that you pull all of these agile teams together and you divide them up into tribes. And therefore, all of the agile initiatives are pulled outside of the business and they work together as agile initiatives.

We do not believe that and we do not see that as the way that the most agile organizations are actually working!

(00:32:30,44) —  So let me just describe this chart at the top. You have the agile leadership team. It consists of most or all of the executive committee and they are running as an agile leadership team. Those red dots represent perpetual agile teams that will stay together and as they solve one customer problem will move on to another customer problem.

So you'll notice we've got a red dot by the agile leadership team because they are behaving like an agile team. They are an agile team, but the agile teams are typically located as close as possible to the operations that are going to adopt and scale them.

(00:33:12,34) —  That means there will be agile teams in divisions in regions in business units in products there will be agile teams and technology and marketing.

Even in finance. They may have a team figuring out how to improve finance functions. What reports should we have? How do we make them most useful to our customers? And in innovation units, of course, perhaps many or all of the teams will be running in agile.

The gray dots are temporary teams. They may form for anywhere from 2-4 months to solve a specific problem. They're not going to be there forever.

I put some squares around teams of teams that are going to work together for a long period of time. There are about 100 teams on this map. Many times in a business unit. We may need eight teams, ten teams to solve a particular problem.

Most of the organization will continue to run in fairly traditional teams.

Then in the red squares there are allocated support people. Think of them very much like help desks in the legal department for example. That says when an agile team comes to you I want you people dedicated to solving their problems as quickly as possible.

They don't go to the end of the queue. You take care of that within a day, within an hour. And this is what it ends up looking like: like agile teams embedded in the operations of the organization. Running as cross functional teams!

(00:34:57,21) —  So even though a team is in marketing, it is ultimately responsible for marketing as their customer. But there will be people from technology, there will be people from operations, there will be people from finance, there will be people from HR making those teams work a very different picture than most agile zealots paint of the way agile teams should be working.

The golden mean of stasis and chaos

When that happens you will build an agile business system. Again the goal is to try to create a system that is at that golden mean between stasis and chaos and as you do that you will change the purpose and values of the company!

You'll change the strategy, you'll change the leadership and the culture. You'll change planning, budgeting, and reviewing. Process structures and accountabilities may eventually change as well.

(00:35:49,95) —  The talent engine, the business processes the technology and data. But always what we're trying to do is to avoid the extremes in leadership and culture. For example, we don't want authoritarian tailoring, but neither do we want benign neglect.

We're looking to create a culture of learning and unleashing talent. And so what we're looking for is this golden mean that achieves a proper balance. If however you wanted to ask me where would I start if I'm not going to change all of these at the same time? The answer is pretty easy because when you survey agile teams about what gets in the way of adopting and scaling agile, almost always the top three responses are about:

  • organizational culture
  • general resistance to change
  • inadequate management support and sponsorship

Oddly enough, it's not about whether the teams are capable of operating in agile fashion. Teams learn to do this very effectively.

Leadership as the main problem

The biggest problem tends to be leadership. Because what we have to do is to change the mindsets and the methods of leadership. So that they're spending less time micromanaging and more time leading!

(00:37:10,63) —  Micromanaging turns out to be a waste of time. We need to delegate to people in order to unleash their capabilities. And if they spend less time doing that, then they can spend more time doing the things that only senior executives are capable of doing. Prioritizing and sequencing work focusing on the corporate vision and the strategy and getting the right people to work on the right tasks!

We often find that when we study, when we actually analyze the calendars of senior executive teams that before they're doing agile and three years after they've been doing agile their calendars change remarkably. That is at the beginning they are probably only spending 10% of their time on strategy development and growth initiatives. They're spending maybe 30% of their time on talent and culture management. The bulk of their time, 60% of the time, is spent on operations management, on operational reviews, financial reviews, crises of the moment, administrative work.

(00:38:17,12) —  Look how dramatically that changes in as an agile leader. Four times more time spent on strategy development and growth, even more time on talent and coaching and very little time on operations management. That they learned that people can and should do better without a whole lot of micromanagement from senior executives.

When you do that the role of a senior executive changes and the capabilities of the organization change.
In fact what we find Is that the productivity of an average worker at the best agile companies increases by 40%. 40 percent!

(00:39:04,36) —  Now. Think about that for a moment. And you know the import of compound interest over 10 years the best companies can generate 30 times more output. 30 times more output.

You just focus your attention from less commanding and controlling, too. How can I unleash the potential of 1000 people in my organization? 10,000 people in my organization? 100,000 people in my organization? Thousands and thousands of people, where the role of a leader becomes ‘How do I tap that untapped potential?’ or ‘ How do I increase their engagement, their happiness, their productivity?’ For way too many years, there has been this notion that work has to be miserable. Here's the deal: sure you are going to be unhappy at work but I'm going to pay you for being efficient and then you can take that money and when you get off of work you can buy happiness.

That is absurd. Nobody should be forced to work in that kind of an environment.

(00:40:17,74) —  And what we find is that agile organizations are changing that way of working. People are happier, they're more engaged. It is not unusual for me to be in a training seminar where during a break I hear people getting together and saying I will never go back to the old way of working. In fact if they made us go back to the old way of working. I would leave and find another place where I could work in agile ways.

The following Interview between Darrell Rigby and Sohrab Salimi


We have some questions from the audience and I also have a few questions for you. But let's start with questions from the audience.

Now the first question: “To what extent do you need faith before you embark on one of these journeys?”

(00:41:17,11) —  Darrell:

Yeah well, I think you always need some level of faith, but the beauty of agile is, it doesn't require excessive unsubstantiated faith. Because we're going to test things, we're going to prove to the CFO, we're going to prove to the CEO that these things actually work before scaling them. I think one of the problems with people who believe in Big Bang transformations is that you have to instill extraordinary faith because we're going to change everything in the organization at once. “Oh my goodness it better be right or we're going to destroy this company”.

No, we're going to do this in an agile fashion, we’ll test, we'll learn, we'll prove, we'll adapt and it is less of a push strategy and more of a pull strategy.

It doesn't have to come from just the top down. The bottom-up will create a groundswell of support for this approach.

So it's very similar to a startup founder. They would also do that. A venture capital fund would not give them a billion dollars right away. They would give them a bit of money, see where they take this and then basically build up faith. They need initial faith but then they build up more faith over time based on the results that come in.


Right. There was another question now. At some point you mentioned there might be like 50% teams or people working in agile teams. And the rest, the most would be working in a different way or in the same way that they're working today.

Now the question that came from you was: “Do we have articles, are we going to have different mindsets?”
And already a conversation started on the chat that an agile mindset already means that you can shape or shift your own mindset. I want to get your perspective on this.

(00:43:10,5) —  Darrell:

It is a great question. In fact I think the most important question. The answer is we believe that you're going to need an agile mindset. And by that I mean common values and principles through the entire organization. And when I think about agile values and principles, I mean some things, like being customer obsessed, because every activity should have a customer.

This is one of the things I've spent a lot of time talking to people at Amazon. And the one thing about people at Amazon is that they will say: we are truly customer obsessed. It may not always be an end user. It may be an internal customer, but we all have customers and we are customer obsessed.

So there are things like this mindset. We all have a customer who is my customer. How do I keep them satisfied? Things like avoiding multitasking. Things like prioritizing and sequencing. Things like whenever possible trying to work in smaller teams. Even if it's just for a part of the time during the day. Treating people with respect, treating people with kindness.

It turns out people are happier and more productive and we're all happier and more productive when we just treat people with a different understanding of what their potential is as opposed to I'm the boss. You do what I say you're not capable of thinking.

So the real answer is: Everybody in the organization should have an agile mindset. Not everybody in the organization will be following agile methods every single day.
That is we're not all running in agile sprints or daily stand-ups or sprint retrospectives. We're not doing all of those practices every single day, but you may get pulled onto an agile team for some period of time and then go back to your traditional way of working.

But that's the difference. That I'm trying to highlight. It is: common mindsets, different practices for different activities. So on a metal level it is actually the same thing. And it's then the awareness to what extent we can predict what's coming. Because we've done it several times and if we can't predict then embrace the fact that we can't predict it. And then approach it in more frequent feedback cycles than we would usually do.


So there was another question and they were asking: You showed the slide about the best and the rest and that 40% difference in over 10 years, 30x difference. Now they were asking: Can one take one of the rest to become one of the best and can this be done with the same people? And if yes, whether you have examples for how they did this?

(00:46:08,48) —  Darrell:

So again, I think one of the most common misperceptions is, that if we're going to create an agile organization we're likely to need new people and we're likely to need a whole different organization structure.

What I find most fascinating about this guy during the Covid-19 pandemic is that it is disproving that notion with real natural experiments. It is disproving that notion because we have the same organizational structure, we have the exact same people. And yet, suddenly we're finding people that we just thought were everyday run of the mill. All they can do is run this machinery.

Suddenly figuring out how to change the machinery from making automobiles to making respirators to making masks and so on. You know that these people are turning into real life corporate MMA givers right in front of our very eyes. These people were always capable of doing this. So one of the things that, as tragic as this pandemic is, one of the things that I truly love about it is, that people are learning: My goodness, my folks can do this now.

How do we bottle it up? How do we keep them thinking this way? I'm shocked. I never knew that and they were capable of doing this.

So yes, I understand that. Over time you may need to do some additional training. You may need to bring in some kinds of people. But I think the greatest discovery we're making right now is that the innate capability of most people in most organizations is much higher than many of the senior executives ever imagined!


Yeah I love this corporate MacGyver. I'm going to steal this one there. It's very interesting because you mentioned the absurdity and irony and a lot of things and I think it's really absurd from senior managers or I mean even like you and I might might fall into the same trap that we look at someone and just define them by the job that we've been observing them doing but not seeing the whole person because that person the moment they leave the office of course they're going to do other stuff.

They have different hobbies and so on and so forth. So they can take those capabilities and their ability to learn into the work and actually do some new things. And the organization facilitates that learning process or catalyzes this.

We have another question: How many high level executives want to change their calendar? You showed how they're going to spend their time towards more strategy and away from operations and are they skilled enough in strategy versus operational management. Because as you know, a lot of organizations hire other companies like Bain for their strategy part.

So that could also be a sign of the lack of strategic know-how in their own leadership.

(00:49:09,87) —  Darrell:

Yes it's an important question from somebody who was obviously seeing some senior executives because on the one hand I often get phone calls. One of the most common calls I get is: I just read your article on the agile C-Suite in the Harvard business review.

Very intriguing. I am really frustrated with our meetings. We just spend so much time in meetings, after meeting after meeting and it's dull and it's not accomplishing anything. Can you help me fix our meetings?

It's a very common call.

And so the first thing you do is to look at their calendars and look at the meetings and they're absolutely right it's overwhelming. But if you say ‘well let's take away all of these operating reviews that you're doing’ their first inclination is ‘But that's how I spent the last 10 or 20 years of my career! If I'm not doing what I know and how-to-do and I'm good at that,
What in the world am I gonna do?
And I say well you're going to spend 40% of your time on the vision and on the strategy and they say how could I possibly spend that much time on strategy and on empowering teams.

And frankly they have a hard time even imagining how they could do that much of it. And so we have to make the transition rather gradual. And you will recall that I said that's over three years but we gradually start saying let's just take this thing off of your schedule.

You do not need to do this meeting. Let's add some stand-up meetings in the morning, where you are meeting with agile teams and they're saying here's what are barriers and could you help us to overcome this? And that's the easiest way to get started.

You get the senior executives listening to these agile teams. What's getting in their way and they start solving problems. So that they turn from people who are managing all the problems to people who are saying ooh that is tough.
What do you recommend that we do and how could we test it? Then their lives start getting fun and then it takes on a momentum all of its own.

(00:51:33,86) —  Sohrab:

Yeah I get the same thing when I work with leaders and tell them it's all about decentralizing decision making. They're like okay what am I gonna do? You're going to discover new things that you can do and it's going to be exciting also for you and everyone has to learn.

So I'm going to be selfish and I'm going to take the last question to be one of my questions now. You work with a lot of executives. I'm sure you also work with boards.
Now my experience has been that a lot of people say the CEO doesn't get it and so on and so forth. But my understanding is that a lot of CEOs, executives in general have to follow the perspective or the longevity. Longevity of perspective that it's set out and if they have a short term focus. Very few organizations I believe are going to make the necessary changes to become more agile.
So first of all, what is your perspective on the role of the board? And if you believe it is as important as I believe, how would you address the boards?


Well the first thing that has to change is the senior executive attitude towards boards. Because you're right I deal with a lot of management teams. Their first priority is to get the board off of their backs. They just don't want to have to deal with it.

So I think the first thing that they have to do is explain we're creating an agile enterprise. Let me tell you what that means. That means we're going to need more of your help in sustaining these agile efforts and we're going to focus more of our time on strategy and vision.

Long term objectives, not the short term things that you often get involved with. And so to tell you the truth. I've seen board members that get very excited about this, most of them that are agile doing agile in their own organizations. Can't wait to see executive teams getting excited about this but some of them do need a fair amount of education as well.


Yeah perfect Darrell. Thank you so much for participating in this conference! It was a pleasure having you and hearing your insights and I'm sure we will connect again soon!


Terrific. Thank you so much.

agile100 (October 2020)

=> Learn from Michele Zanini (Humanocracy), Willy Wijnands (Scrum edu) and many more at the agile100 event in october

Psychological Safety in Virtual Environments

=> Joseph Pelrine talked about psychological safety in virtual environments at agile100

Why do some organizations fail?

=> Learn how to build invincible companies with Alex Osterwalder