Doing Agile Right: Darrell Rigby

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.

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 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.

• LinkedIN
• Agile Innovation
• Bain Alerts Twitter

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

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

Sohrab:
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.

Darrell:
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.

(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.

(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

Sohrab:

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

Sohrab:

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

Sohrab:

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

Sohrab:

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

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

Darrell:

Sohrab:

Darrell:

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