Agile Mindset: Adopting an Agile Mindset

This is a talk I gave for Aotearoa New Zealand’s BusinessCentral at their 2020 Business Bootcamp.

With my host Mahi Tangaere, I examined the why of Agile and the mindset that’s required for successful transformations. New and experienced Agile practitioners alike will walk away better prepared to deliver twice the value—in half the time—with ten times the joy. In this talk, we explored:

  • What is Agile, really?
  • What kind of problem are you solving?
  • What is your theory of employee motivation and management?
  • What changes in an Agile transformation?

Mahi Tangaere: [00:00:00] Kia ora koutou and welcome to this Business Bootcamp. The third in our series with the fourth finishing this Thursday. This series session three is all about the Agile workforce. My name is Mahi Tangaere and it is my pleasure to welcome you to our session today on the challenge of an Agile workforce.

We’re very fortunate to have Chris Gagné, an Agile coach from Approach Perfect to talk to you about our Agile workforce and what that is or what that could be. It is now my pleasure to introduce you to Chris Gagné. Chris.

Chris Gagné: [00:00:38]

No alt text provided for this image

So just a little bit about me to set some context. Over the last five years, I’ve helped over fifty teams learn how to complete twice the work, in half the time, with ten times the joy. Prior to that, I have about ten and a half years of project, account, and product management experience. I am trained in and practice the leading Agile frameworks, such as Scrum, Kanban, and Lean. I received my first advanced Scrum certification in 2011. I’m also trained in practice and the dominant large-scale frameworks, including the Scaled Agile Framework and Large-Scale Scrum. I have coached Agile teams and organizations ranging in size from 39-person startups to a 39,000-person Fortune 100 company. I’ve had the joy of working alongside some of the brightest coaches in the industry during my tenure at SolutionsIQ, which is the largest Agile consultancy in the United States and now owned by Accenture, a half-million person consulting company.

With humility, I want to say that everything I know, I’ve learned from my mentors, the teams that I’ve worked with, and the giants who push the state of Agile forward, I am deeply indebted to them and I hope to share some of this with you now.

So, why this talk? Most transformations fail. 95% of transformations fail and failures generally have the same root cause.

Success is not even remotely guaranteed, but some failure modes are avoidable. It’s my hope to reduce your odds of failure by disillusioning you from the idea that an Agile transformation is either easy or even straightforward. Knowing this, I trust that you will approach the task with the humility, courage and determination that it requires and you will succeed brilliantly.

In today’s talk, we’re going to be exploring four questions:

  • What is Agile, really?
  • What kind of problem are you solving?
  • What is your theory of employee motivation and management?
  • And, what changes in an Agile transformation?
No alt text provided for this image

So, first, here’s the official definition of Agile: “Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.” And this is from the Agile Alliance. This is the governing body for Agile software development.

Therefore, Agile is a capability. It doesn’t have a defined end. It is not a process. Most importantly—and I hear this a lot—Agile is not a project management methodology. If you hear or see someone using this term to describe Agile, it’s a sure sign that they do not understand it. Agile is something that we become rather than we do.

It’s a little bit like a martial art. You don’t simply just throw punches and say, “I’m a martial arts expert.” It’s something that you study. It’s something that you “create the path with every step” and you “learn to play.” It is a capability that allows you to thrive in volatile, uncertain, complex, and ambiguous situations.

Unofficially, I’d argue that Agile goes beyond just being a capability. I think it’s actually the very science of studying how knowledge workers can best work together.

No alt text provided for this image

So, now I want to help you understand what kind of problem you’re solving. And as part of my campaign to disillusion you, I hope to disillusion you as to the nature of the problem you are solving.

I’d like to introduce you to the Cynefin framework, pronounced kuh-NEV-in. It’s a Welsh word. The literal translation is habitat or place, but it’s a lot more holistic than that. It’s the place of your multiple belongings: cultural, geographic, perhaps even spiritual.

No alt text provided for this image

Cynefin is a sense-making model. It helps you understand what sort of problem you’re facing and what the appropriate response and practice will be.

In the natural world, there are chaotic, complex, and ordered systems. Cynefin differentiates between complicated and simple ordered systems. And then the centre of this framework is Disorder, which comes as a consequence of not understanding which space you’re in. So let’s look at each of these domains in turn and how we use them.

No alt text provided for this image

So first in the Simple domain, cause-and-effect relationships exist. They’re predictable and they are repeatable. The relationship between cause and effect is “self-evident to any reasonable person.” And so, in the Simple domain, there’s this action mode, which is sense, categorise and respond. You sense the situation, categorise the situation to a known bucket and respond with a well-known solution. As a result, there is often a single best practice that we can follow. This is like the game “tic-tac-toe” [also known as “noughts and crosses”). Once you learn the basic strategy, you cannot lose. You can always force a draw.

No alt text provided for this image

In the Complicated domain, which is still in this ordered space, cause-and-effect relationships still exist. But they are not immediately self-evident… at least not to everyone. Therefore, they require a degree of expertise. So, the action mode, in this case, is: sense, and respond. You sense the problem, analyse the problem, and respond with a plan. This is different from Simple in which the second step is and not. This requires training, experience and expertise. In the Complicated domain. There are multiple ways of approaching the same problem. Therefore we apply good practice without trying to claim that it is best practice. You don’t want to come in arguing that your way is best practice, because you’ll just annoy people who have been equally successful with their own practices.

This domain is a bit like chess. You can plan ahead, but at some point, you will need to adapt your plan a little bit. And, for those of you who come with a project management background—Project Management Institute and whatnot—this is very much in the Complicated domain. You can come up with this expert plan and it’s really up to the team to follow the plan.

No alt text provided for this image

Now, I want to introduce you to where it really starts getting interesting and juicy. Now we’re in Complex and Complex is a system without a priori causality. The cause and effect are only understandable in hindsight with unpredictable emergent outcomes. Notably, you will not truly understand the complexity of systems until they begin to fail and complex systems always fail. Failure is the system talking to you, so we want to listen to the failure. We want to listen to that data. It’s not noise: it’s the system talking to you. And so the action mode in a Complex environment flips: we probe, sense and respond. In the Complicated space, we’re going to sense, analyze, and respond and in the Complex space, we probe, sense, and respond.

So we’re going to probe with safe to fail experiments. Experiment, evaluate. Experiment, evaluate. Repeat. Repeat. Unlike complicated situations, we’re not looking for a fail-safe design. Then we’re going to sense. We’re going to dive into the new and determine the next steps. And then finally, we’re going to respond by taking action by moving as much to the problem into the Complicated domain, wherever we can.

This is emergent practice because everything we face is going to be novel. There are no good answers. We’re creating the path with every step. We’re solving wicked problems. Coming at this with an attitude of play is really quite useful. This is like the game of poker: past experiences are useful, but you have to “ante up,” you have to actively probe the system to discover what your next move is going to be.

No alt text provided for this image

And then finally Chaotic systems. Chaotic systems, if entered intentionally can be used for innovation. Most of the time we fall into them accidentally. We need to get out of this domain quickly. No cause and effect relationships can be determined, even in hindsight. The action mode here is act, sense, respond. So even more so than complex situations, we need to act. Trust your instincts. Get out of the immediate danger zone. Then once you’re out of the immediate danger zone, you’re going to assess the situation and determine the next steps. And then finally, you’re going to take action to move your problem into another domain. We’re in a space of totally novel practice. The knowledge that you’ve gained over your lifetime is only partially useful. And this is a lot like the game roulette or craps. Most of the time you’re in a chaotic situation, you’re not going to win. So don’t freeze: get out or get hurt or worse.

No alt text provided for this image

So tying it all together, we’ve got disorder in the middle of this, which again, it’s the space of not knowing which domain you’re in. Unfortunately, most of us are in this space most of the time. Being in disorder is like approaching poker with a tic-tac-toe mindset. You underestimate the complexity of the situation that you’re in and you are bound to lose. Though, you might get lucky for a little while.

The point of this framework is to teach us that depending on the space that we’re in, we need to think and act differently. One size does not fit all. Unfortunately, we run the risk of assuming that the problem reflects our usual pattern of action. So for instance, if you’re a bureaucrat, you might assume that all problems are failures to process reflecting the Simple domain’s perspective. If you’re a deep expert, such as an accountant or project manager, you might think that the problems are due to failure to fully analyze. That’s the complicated domain. Military generals, emergency room doctors, seasoned Lean leaders: they’re operating in this Complex domain. They’re used to getting perspectives from lots of different backgrounds and getting a team together and saying, “team, let’s come up together and come up with the best solution.” As Dave Snowden, creator of this Cynefin framework, says fascists love a crisis because it gives them an opportunity to control and act as they see fit with total impunity.

What I would like you to come away with is that the problems you are solving are almost certainly complex, at best complicated, and at worst chaotic. It is extremely unlikely that you are solving simple problems. And, if you are, you face an existential threat from bigger players who can solve your problem with an efficiency of scale or disruptive technology, neither of which you can probably even imagine at the moment.

No alt text provided for this image

I, therefore, believe that the root cause of the failure or stunted success for most organizations is a failure to appreciate the complexity of the situation they face and tune their management style accordingly.

Here’s an example. Leaders have spent the earlier phase of their career as expert individual contributors. They’ve worked up the ranks by being experts in Complicated domain. Well, this works great for the Complicated piece and this suits the domain that they’ve been given. They’ve been broken off a piece of a Complex problem, which has been made Complicated. They’ve been confined to this, and so they’ve become experts of this Complicated domain. Now that they have been promoted into a leadership role, their problems are now Complex. They need to give up their expertise. They need to relinquish control and listen to their team when facing their broader, Complex problems. Failure to do so is Disorder and inevitably leads to Chaos.

No alt text provided for this image

I want to tie this into “What is your theory of employee behaviour?” A lot of leaders’ behaviours are dictated by how they see their workforce. Theory X and Theory Y are theories of human work, motivation, and management. They were created by Douglas McGregor while he was working at the MIT (Massachusetts Institute of Technology) Sloan School of Management in the 1950s and developed further in the 1960s.

Theory X and Y come from this mnemonic device: Theory X employees are crossing their arms in front of them, blocking off and avoiding work, while Theory Y employees raise their arms in a welcoming way.

No alt text provided for this image

I want to give you a sense of some of these Theory X employee attitudes. They’re motivated mainly by money and fears about job security. There’s very little creativity, except when it comes to getting around the rules. They dislike work, find it boring, and will try to avoid it. They would rather be directed than accept responsibility, which they avoid. Finally, they must be forced or coerced to make the right effort.

No alt text provided for this image

Let’s contrast this to Theory Y employee attitudes. Under the right conditions, they’re motivated by the desire to realize their own potential. They are highly creative creatures, but they’re rarely recognized as such or given the opportunity to be. They’ve recognized that they need to work and they’re going to do everything in their power to take an interest in it. They might even enjoy it. They will seek and accept responsibility under the right conditions. And lastly, they’re going to direct themselves to a target that they accept.

So let’s tie this together. How do we reconcile the Cynefin framework and Theory X and Theory Y employee attitudes? What we’re going to do is look at this through the lens of two exemplary leaders, Henry Ford of the Ford Motor Company and Konosuke Matsushita of Panasonic.

Henry Ford

Henry Ford

So here’s Henry Ford. If Theory X and the Simple and Complicated domain management had a t-shirt it would read, “Why is it that every time I asked for a pair of hands, they come with a brain attached?” Another name for this is Taylorism or scientific management. Taylorism is a production system that divides the manufacturing process into small steps that reduce the degree of skills required to perform each activity.

The aim of Taylorism is to increase productivity and to reduce training times to increase output levels. An example of this thinking might be managing someone in an egg production facility. They’re tasked with washing an egg every three seconds with a daily goal of 3,500 eggs. If they meet this goal, they get a 10% bonus.

The problem is simple enough that the work itself won’t be inherently satisfying, and so we need to rely on extrinsic motivation. Yet, even with the simple example, it may well be that someone figures out a way of consistently washing an egg in two seconds so they can guarantee their daily bonus. Would Henry Ford listen to their suggestions and let them train others in their new technique in exchange for a solid one-time bonus? Or, will they still hold on to their hubris and assume that they still have the right way and not listen to their employees’ ideas?

Even things that seem Simple or Complicated, there may be ways of improving. We still need to be willing to listen.

Konosuke Matsushita

Konosuke Matsushita

I’d like to contrast this with Konosuke Matsushita, the founder of Panasonic. He’s not fond of Taylorism, but he’s a great spokesperson for Theory Y and Complex domain management. This is a long quote, but I was quite moved by it and it sums up Agile leadership beautifully. So let’s give it a read”We will win and you will lose. You cannot do anything about it, because your failure is an internal disease. Your companies are based on Taylor’s principles. Worse, your heads are Taylorized, too.

You firmly believe that sound management means executives on one side and workers on the other, on one side men who think, and then the other men who can only work. For you, management is the art of smoothly transferring the executives’ ideas to the workers’ hands.

We have passed the Taylor stage. We are aware that business has become terribly complex. Survival is very uncertain in an environment filled with risk, the unexpected, and competition…

Therefore, a company must have the constant commitment of the minds of all of its employees to survive. For us, management is the entire workforce’s intellectual commitment at the service of the company.

We know that the intelligence of a few technocrats—even very bright ones—has become totally inadequate to face these challenges. Only the intellects of all of the employees can permit a company to live with the ups and downs and the requirements of the new environment.

Yes, we will win and you will lose. For you are not able to read your minds of the obsolete Taylorisms, that we’ve never had.”

—Konosuke Matsushita, founder of Panasonic, 1989

31 years ago.

Think of some of Theory Y characteristics, like these: “we are highly creative creatures, but we’re rarely recognized as such or given the opportunity to be”. “We will direct ourselves towards a target we accept.” Naturally, these employees will thrive at Panasonic.

Remember what we learned from the Cynefin framework. When we’re in a complex situation, we need everyone’s perspective to thrive. Now Konosuke was talking about complex and he said this in 1989. Technology has moved a lot in 31 years.

No alt text provided for this image

I looked up Panasonic’s corporate history and this VHS camcorder was probably the most complex product Panasonic made at the time of his quote. I’m willing to bet that any problem you’re attempting to solve now is orders of magnitude more complex.

There’s a paradox in this, which is that almost all knowledge workers are capable of having either Theory X or Theory Y motivations and this is a self-fulfilling prophecy. If you hold the belief that most workers behave with Theory X motivations—motivating them with money or fear, limiting their autonomy and forcing or coercing your teams to make the right effort—You will wind up with only Theory X behaviour. People with a Theory Y motivation will not tolerate your strategy for very long, and they will leave organizations that can attract and retain Theory Y talent.

People with Theory X motivations can’t stay in Theory Y organizations for very long. They’re going to become your talent pool. Now, this isn’t to say that all employees are capable of operating with Theory Y motivations.

Even primates innately exhibit Theory Y motivation. There was an experiment in which researchers were planning on rewarding monkeys with treats in exchange for solving puzzles. They set the puzzles in the monkey cages and went off to get the treats. When they came back, the monkeys had already solved the problems out of intellectual curiosity and pleasure, not for the treats.

Researchers have also found that you can train people out of Theory Y motivation. For instance, many children enjoy colouring and will doodle for hours if left to their own devices with some supplies. However, researchers found that if they attempted to motivate the children to colour with extrinsic rewards like candy or other treats, the children lost their intrinsic motivation to colour, and instead did so only in exchange for the extrinsic reward.

As leaders, manage and interview for Theory Y traits. Ask what motivates people: is it the money or is it the opportunity to solve interesting problems? Develop a Theory Y leadership mindset and expect Theory Y motivation from your teams and your teams will likely exhibit them.

Now let’s get really juicy. Let’s talk about what an Agile transformation is really about. An Agile transformation is a little bit like a caterpillar becoming a butterfly. A caterpillar cannot imagine what it is like to be a butterfly. Caterpillars cannot tell other caterpillars what it is like to be a butterfly. It is difficult even, for a butterfly to articulate what it’s like to be them to a caterpillar. Notably, a caterpillar can not go find another caterpillar selling wings, glue some on, and fly like a butterfly.

It is not like that at all. The whole being must commit to the transformation. Now from the caterpillar’s perspective, this might be your entire existing project management organization. This may be your entire middle management or even executive management structure. This transformation is going to feel like chaos, perhaps even death.

Your way of thinking is going to turn into this liminal goo. And it’s not going to look like either a caterpillar or a butterfly for a bit of the process. But if your caterpillar has a good protective cocoon and lets this process gradually unfold, it can indeed emerge as a butterfly. Your organization cannot half-commit to its Agile transformation. The entire organization—including functions outside of IT, such as finance, human resources, sales, marketing, certainly your entire executive suite—must also commit and change too. The leadership must change the most. I’ve never seen a butterfly flying around with a caterpillar’s head.

You’re going to need a protective cocoon. In this case, it’s the advice and guidance of Agile coaches and other leaders who have gone through and led these transformations before. They’re going to help you understand the next step and keep your courage up when that liminal goo gets up to your neck. But, do not come away thinking that you can delegate any of this to anyone else. After all, this is your transformation and not theirs.

So you’re probably a leader in your organization. If you signed up for this talk, did you also sign up to lead your Agile transformation? If so, what did you suppose that would look like? Here are the things that are going to change in your organization as part of your Agile transformation. There are five major things that are going to change terminology, tools, process, structure, and culture.

Terminology is at one end of the spectrum. Suppose you have Business Analysts in your organization. The superficial change would have them perform the same role in the same function, but now you’re going to call them Product Owners. The same goes for your Project Managers: maybe you just call them Scrum Masters now.

Or tools: maybe you switch your tools. You’ve been using Microsoft Project and Gantt charts and your Agile coach has said, ” it’s time to use Jira” You open up Atlassian Jira, but you’re still trying to figure out a way to get Gantt charts out of Jira. Your ways of using the tools are basically the same, just with new tools.

Or process. Maybe now you’re using some of the Scrum Artifacts like the Product Backlog, or your Definition of Done, or your Sprint Backlog, or your Product Increment? You’re using some of the Scrum Events like sprint planning or daily stand-ups and you’re using historical velocity and a pro forma backlog to forecast the future. But, you’re also managing a lot of dependencies between the back-end and your front-end teams. Your product owner doesn’t have a lot of authority and your human resources department haven’t really figured out how to make the Scrum Master a real role.

Now we get into the structure. Now, you’ve actually made your Product Owner, a real Product Owner: they have authority. Your Scrum Master is really a Scrum Master. Perhaps you’ve gone a step further and you’ve created cross-functional self-organizing feature teams. You don’t need a process to manage dependencies because you’ve worked that of your structure.

One defining characteristic of companies that make or break your transformation is that Scrum Masters and Agile coaches are a valued role in your organization. Every team has one and they have a meaningful career path.

Finally, culture: your leadership is starting to behave more like Konosuke Matsushita and less like Henry Ford. You recognize that your problem is intractably complex and you seek advice from the people with the most information: the individual contributors on the ground. Continuous improvement and servant leadership is built into your DNA and any opportunity to identify and eliminate waste is celebrated and taken.

Here’s an example of this: Toyota has 300,000 employees. Those 300,000 employees make a total of one million suggestions annually. What percentage of those suggestions do you suppose are implemented? 97%. What do you suppose that organization looks like? Again, that culture.

As you’ve probably figured out by now, there’s a real spectrum to the value of the transformation.

It doesn’t buy you much just to change the terminology that you use. As Peter Drucker once said, “culture eats strategy for breakfast.” You want to create a culture that develops, attracts, and retains Theory-Y minded talent. You’re going to set them up for success with a bold vision, get out of their way, and provide help when asked. Your team is going to do the seemingly impossible.

Yet, most companies barely improve their process. Few change their structure, and even fewer evolve their culture. Why?

No alt text provided for this image

Because it’s hard, slow, and requires leadership involvement. In most, but not all, Agile transformations, leaders are too busy or believe themselves to be too important to participate themselves. They thus delegate the transformation responsibility to their teams and sometimes coaches. As an Agile coach, I sometimes think that I’m a surrogate leader coming in and then helping develop people to their fullest potential. But I truly see this as the requirement of the leaders.

William Edwards Deming, famous Lean-friendly management and quality guru—he’s regarded as having more impact on Japanese manufacturing business than anyone not of Japanese heritage—once said to a CEO, “come yourself or send no one.” Dr. Deming used to say that 85%—and later 95%—of problems in any organization were systemic in nature and that management owns all systems. Therefore management is responsible for 85 to 95% of all problems.

Most transformations fail because they cannot or will not address the systemic structural and cultural problems. What happens is that teams wind up adapting the Agile frameworks—Scrum Kanban Lean—too soon. This is because they’re using tools and processes designed for a structure and culture they do not have. They are not patient enough to sit with that discomfort and see the transformation through, using those tools and processes to empirically develop that new structure and culture as intended.

This is what the tools and processes do: they help you develop your structure and culture. These naïve teams adapt the frameworks without understanding them. They adapt the tools and processes to the structure and culture that they have, and can’t and won’t change. Rather than sticking with those tools and processes, sitting with that discomfort, and using that to evolve the structure and culture. This inhibits their learning, and thus they never have a shot at their full potential.

Finally, the culture of the organization is limited by the psycho-social maturity of the C-suite and the board. One of the best coaches I’ve ever worked with studied marriage and family therapy. Can you believe that? Just so they could work with executives. If you don’t have a secure, trusting attachment style in your personal relationships, you’re not going to have one with your teams either. It takes a lot of work to get to the point where you can hire people who are smarter than you are and entrust them with your heart’s vision.

As Matsushita said the intelligence of very bright technocrats is inadequate to face the challenges of our increasingly complex problems. So you must release this. You must let go. You must develop your maturity to the point where you can say “teams, I selected you well, I’ve hired the brightest people that I can, you’re all smarter than I am. Here’s my vision. Go run with it. Tell me what you need and I will serve you.”

And so how do I get started? I’ve given you some warnings. I hope to have profoundly disillusioned you as to how easy this transformation is going to be. It’s simple. It actually is quite simple, but it’s not easy. There’s a Zen to it.

And so how do we get started? First, approach your transformation one step at a time. I say to my teams, “look, if you get together every two weeks for a Retrospective, you sincerely get together and you spend 90 minutes just asking yourself, ‘what’s going on? How do we get better?’ You might get 2-3% better every time you do that.” just as Albert Einstein said, there is a magic of compounding interest. There is a magic of compounding continuous improvement. If you get 2-3% better every time you retrospect, every two weeks: in a year, you’re going to be twice as good. It’s just this gradual unfolding process. Be patient: tend to your transformation like a garden, and it will blossom.

Leaders, please take the time to learn. Read books. Take classes. Watch videos. Execute low-risk experiments. I can’t tell you how many times I’ve come in and coached an organization and leaders have told me to spend days or weeks training their teams, but I can’t even get half a day with them to teach them some of the skills they need. And they really do need a full week or two of intensive learning to learn how this transformation is going to shift.

Hire reputable coaches with good references and listened to their advice, even if you don’t always take it. We’ve navigated this road. We’re Sherpas: we’ve climbed this mountain. We can help you carry some of the weight and we know where the pitfalls are and we can help you.

And lastly, and this is probably the most important piece of advice I can give you: when in doubt about what to do next, take it to your team. Your team is closest to the problem. They understand the problem better than you do. They have the most information they’re most likely to be able to help you solve it. What you bring to the situation is more authority—although you can give them the authority—and you have the 10,000-meter view. So their on-the-ground, in-the-forest view plus your 10,000-meter view, comes together to allow you to collaboratively solve the problem.

So with that. Thank you.

Mahi Tangaere: [00:36:39] That’s fantastic Chris. In a nutshell, I’m just a bit blown away by your presentation. I really enjoyed it. I think that we all have worked with the Xs and understand they can relate so much to what, but also sometimes feel that we are somewhere sometimes caught on the crossroads of some of that when we haven’t up-skilled ourselves or we’re bought into a mindset and really embraced it. And then you get times like this year, when that has served you very, very badly, so I can relate to so much of what you’ve said. I’ve really enjoyed that and I think you must’ve had some very interesting experiences where you have seen some businesses that are really with you, and then you’ve walked into some areas where you are like, “Oh my God, I’ve been set up to be roasted.”

Chris Gagné: [00:37:36] Hmm. [Laughs]

Mahi Tangaere: [00:37:37] [Laughs] This is like you say you’re the leader and you’ve just been set to fix a problem because they understand there is an issue. They’ve identified they don’t have the skills, but they don’t understand how important their leadership is in the process. I can see how you pay the money you say “fix it, but you’ve got to be along for the ride.”

Just a couple of questions. If I could start off. There’s a lot of language that goes with what you do and what you talk about and your Scrums and your Agility. And I see that there is value and what you say for pretty much anybody. Do you see it as the same? Do you see that here may be small-to-mediums, don’t access you where they really should? Do you see that you get a style of like New Zealand company?

Chris Gagné: [00:38:33] That’s a great question.

Mahi Tangaere: [00:38:34] Or a type.

Chris Gagné: [00:38:35] Yes. So, I have limited exposure to New Zealand companies at this point, but I can give you a naïve perspective and more importantly, I can give you a perspective from Silicon Valley.

So, we talk about “tall poppy syndrome,” which has its advantages at times. I think it can be an advantage in that we don’t necessarily need to praise individual achievement as much as we can praise team achievement. And there’s a real humility. I gave a workshop for an organization called Tatou down in Blenheim.

And he gave me a really beautiful story about the All Blacks. He told me that the players were actually responsible for cleaning their own locker room before they go home. And I think that’s so powerful no matter how high you get in the business domain or in the sports domain. The All Blacks as I understand are the second most successful team in history, second only to the female All Blacks. To be so profound and so successful, and yet at the end of the day, they still do the work of cleaning their own locker rooms to maintain that humility and maintain that discipline.

I think that this will serve New Zealand businesses very well. And so I think that although Agile is perhaps somewhat newer to New Zealand’s shores, I think our culture and our ability to learn from those who’ve come before us will allow us to avoid many of these mistakes. In Silicon Valley, there is profound hubris. I remember walking into a conference room or knocking on the door of a conference room and asking the folks in the conference room to evacuate the room so that our team could come in and have our meeting.

And they literally said to me, “there are more of us than there are of you.” This is why we’re unable to create psychological safety for our teams. Do not look to Silicon Valley as necessarily experts in Agility. I’ve seen logos for these companies in presentations here in Wellington, as examples of highly successful Agile companies. I just laugh to myself. I actually think we have a very profound opportunity and I think the way that we work together and or humility will serve us very well.

Mahi Tangaere: [00:41:17] Thank you. In your opinion, when you go in, do you have a view on why transformations tend to fail?

Chris Gagné: [00:41:27] Lack of leadership involvement. There’s an organization called VersionOne and they did a “State of Agile” survey. They’ve done this 14 times. So I’ll actually share this with you.

No alt text provided for this image

They asked people why they fail. There’s this general organizational resistance to change or not enough leadership participation. Inconsistent processes and practices across teams, which I think is about leadership failure. Organizational culture at odds with Agile values, inadequate management support and sponsorship, lack of skills or experience with Agile methods. I think that’s a failure of leadership to invest in sufficient training and education, same thing. Lack of business, customer, and Product Owner,availability. This is the business, the executive saying, “developers go off on their own.” The pervasiveness of traditional development methods. That’s simply not having the gumption to say “no, really, truly we’re changing.” Looking at the top nine or ten examples, again, it all points back to leadership abdicating their responsibilities. They say, “I want to lead.” Well, leadership involves leading. You said you want to lead the transformation. Here’s the opportunity. This is going to require your involvement, certainly more than anybody else’s.

Mahi Tangaere: [00:42:45] Have you ever been involved in a transformation where the benefits surprised everybody?

Chris Gagné: [00:42:52] Yes. I was working on a team down in Los Angeles and I was working on a project. We were doing a site migration and I use this as an example. I would ask various different teams: I would describe to them the type of work that was necessary, the scope of work that we were doing. And I would typically ask people, “Now, how long would you think this would take, start to finish? You’re not going to have any overtime. You’re not going to have any defects. You’re not cutting corners. How long do you think this would take?”

And the most typical response that I got was about four to six months. About six months, typically. The team that I worked with completed this scope of work—no downtime, no defects, no overtime—start to finish in three weeks, The best Scrum teams in the world are about eight times faster. Imagine being able to do in twelve weeks what would take your competition two years to accomplish: it’s a profound elevation. I think the example of a caterpillar and a butterfly, it’s actually a very apt metaphor. A caterpillar cannot imagine what it is like to fly and any goofing around with glue-on wings will always be a pale comparison to the real thing.

Mahi Tangaere: [00:44:20] Thank you. That’s a really good example. Thank you. Do you see then that there are some New Zealand—without wishing to raise any heckles in any business anywhere—in New Zealand at the moment we have lots of construction and infrastructure issues? Do you see kind of that there is a mentality among those businesses or something that… Because costs are large, costs blow out. You say that when you get the right people and they work on something together that perhaps we are sitting in the middle of a lot of businesses that actually need a lot of transformation to help them solve their internal problems to deliver better for everybody else.

Chris Gagné: [00:45:10] It’s funny that you say that because there are a lot of people working on large scale projects, including construction, or I know people building out large data centres, so things where they basically say, “this project is far too big to run using Agile or Lean mindsets. We’re different. We’re special.”

If you’re one of these people, I highly encourage you to look for a talk by a woman named Mary Poppendieck. The talk is called “The Tyranny of ‘The Plan.’” I want to give you an example because I hope this bursts your bubble a little bit.

This is a slide from her presentation talking about the Empire State Building. This is 1929. This is over 90 years ago and this is before we had computers. They built the empire state building exactly on time and 18% under budget. I think that’s absolutely extraordinary. The way that they did that was they actually had very much of a similar Agile plan.

No alt text provided for this image

I’ll actually show you the literal plan that they used. They were literally planning floors six through ten as they were building floors one through five. So here, you see “information required,” right? And this is where they’re beginning to do some of their details and delivery. So notice that some of the information required for these top floors, 84 and up, that’s happening down here in April or May when the work on the first few floors has been completely done.

The way that they did this, what they realized that they were three core constraints for the building: they recognize at first we needed the material movement of 500 trucks worth of concrete and whatnot in and out of busy, lower Manhattan every day. They also recognized that they had to get the foundation right. Obviously you can’t go back and fix the foundation later. And then as you might expect , the elevator shaft , from the bottom floor to the top floor needed to be planned out in a fair amount of detail from the beginning.

So what we learned was: that it turns out that even for construction projects, we were using Lean methodologies a very long time ago and it was highly successful and we seem to have forgotten how to do it.

Mahi Tangaere: [00:47:43] Yeah. That’s just a brilliant example. I think that actually, everybody in construction today should be given that game chat, frankly. Because I think it is they were Lean. They didn’t have a whole lot of people. You were building with what you had at the time and maybe and our mindset has also over complicated matters with a whole lot of people who don’t necessarily need to be part of decision-making. I think that that’s a really useful tool and I’ve written her name down.

I want to go back and read that. Investment Central. We recently did a survey earlier this year and we found that two-thirds of our members were looking at restructures and redundancies and you can see it. That’s the reality of life at the moment. You got any insights that you could provide for members that are looking at changing the structure of the organization to be more Agile in light of this? Or what they could do to try and retain people who are going to be high value, but they at the moment don’t know what to do about it?

Chris Gagné: [00:48:47] It’s an interesting paradigm and a bit of a paradox. Toyota and GM when they got together and they developed a car manufacturing plant together. There’s also a beautiful story about a plant called NUMMI. It was part of a radio show called This American Life. They found that when companies adopted these Lean practices, that they could develop a higher quality product with a smaller workforce. But, there’s a bit of a twist here, which I really want to dig into because I don’t want us to think of Lean and Agile just as an excuse to lower our workforce, reduce our workforce. Certainly in Silicon Valley—and I presume this is also the case in New Zealand as well—it’s very difficult to find top quality talent. The lengths that people go to to hire strong developers in Silicon Valley are extraordinary and they make large amounts of money.

I think it’s less a matter of figuring out how to reduce our workforce, but how to get more value out of the workforce that we have. So our Business Central members might be thinking, “I need to reduce the size of my workforce because we’re not productive enough in order to justify their salary.”

But I posit that if you are sincere in this transformation, you may in fact be able to increase the value that you deliver to your customers, such that everyone in your company is still indispensable.

Structurally, what I encourage you to do is stop thinking about your functional roles within the organization. There is something called Conway’s Law, which is “what the customer sees and the systems that your company will produce, reflect your internal organizational structure.” So if I have a back-end team and a front-end team, iOS team and an Android team, those were all going to be fractioned. And my customers are going to experience a disjointed product experience that reflects my internal organization. I also have to manage a lot of dependencies. I’m going to have to have all these fancy processes and overhead and project managers and business analysts and all these people running around trying to manage this overly complicated machine.

“People are like babies, not printers.” [from Bas Vodde] What I mean by that is a printer can only do one thing well. Your job is to keep that printer busy 100% of the time spitting out printed paper in order to get it to do that thing. Babies don’t know much the beginning, but they have this incredible capacity to learn. If you say, “well look, I’ve got my back-end team and my front-end team, and I can’t quite create two feature teams because I don’t have the immediate skillsets on those teams. Should these teams just stand alone right from the beginning?” That’s fine. But when I talk to teams, what I find is that I say, “well, how long would it take you to learn the skills necessary to function this way? Most of the team members that I’ve talked to say two, maybe four weeks tops.” That’s no time at all.

The role of a leader is to develop their people to their highest potential. One of the things that I found was really interesting at NUMMI: they had an employee team member handbook, and I’ll show this to you just because I think it’s such a gem. And I think it’s also kind of along that same line.

No alt text provided for this image

Here they are, this is a page out of the handbook that gave everyone. They said we want to have “healthy sustained growth by fostering high morale and motivation. You are a valuable resource. YoUr full involvement in the businesses is essential to our mutual success.” That sounds a lot like Matsushita, right? Look at their objectives. Their number one objective is to “help people develop to their full potential and they care about continuous employment for all team members through productivity improvements.” Notice that their last objective is to “build the highest quality car in the world.” Notice how backwards this is compared to the way that most businesses think.

But if you get all these other objectives right—if you have full participation, if you have continuous employment, if you have mutual trust, if you recognize worth and dignity—you’re going to develop that Theory Y mindset, and you will develop the highest quality product in the world.

Mahi Tangaere: [00:53:12] Brilliant. That’s brilliant. And I think that’s just a beautiful thing Chris (and we’re almost coming to the end) is that you can do all of these things. If a lot of it, you think about the people first. You actually take account of what you’ve got. They are your employees. What I get a sense from you as well, it’s the “culture eats strategy for breakfast” quote.

Um, we all think strategy, strategy, strategy. How are we going to solve these problems? What are we going to do? And I think it’s a very New Zealand thing. If you actually put all of that stuff aside and you take it back to basics: we are about people. It’s how we’ve gotten this far through COVID, but it’s fundamentally why people want to be here and why people love New Zealand.

I think we can do this. And I think sometimes we get a bit bogged down in our business and the doing. I think this year’s been a very good time for us to remember our people. And to actually treat them a lot, kinder. Like you said, we’ve all had to rock and roll with whatever goes on and it is very, very, very important.

Um, and whilst you also have provided a very good framework, that the Welsh [Cynefin], which I shan’t even bother to try, I just think that’s a really useful tool because I think we can all see at different times and lots of different aspects of our lives. We’re all doing that. And it serves us no particularly good purpose and certainly not in our business lives. Like I said earlier, I think some of us—for me as a 50-year-old—I’ve seen you have to be committed to your own transformation and what you want to be. And you also have to listen to the people that work for you.

Just because you did that ten years ago, and that was acceptable or even maybe six months ago today that’s not, or today actually we’ll just move. We can do it better. We can communicate in different ways and we can work it out a lot better. And I think New Zealand has a really good place for this. I think that we like to adapt and that we’ve really got very, very good at it. I’ve just really enjoyed it.

I’ve loved the theory along with your practical examples. The fact that the Empire State Building was 18% under budget, just blows my mind. There’s a challenge for every New Zealand project today. So just for me Chris, you’ve been quite inspirational. I’ve really enjoyed it. I hope way more New Zealand businesses connect with you when we actually get to see a bit more of you in real-time onshore and delivering, not just Silicon Valley. I’m sure they also need your skills and of course they will continue to. You are just such a fantastic asset to have here. And it’s been a pleasure to talk to you today. I’ve really enjoyed it.

Chris Gagné: [00:56:09] Thank you Mahi, Likewise.

Mahi Tangaere: [00:56:11] Thanks, Chris. For everyone else on the call, this is the end of our third. We have one more session this Thursday and we will have Innovation on Thursday with Randy Komisar and Andrew Phillips. So thank you so much again, Chris Gagné for joining us for today’s session.

Chris Gagné: [00:56:33] Thank you, Mahi.

Mahi Tangaere: [00:56:33] Have a fabulous day, everybody. Enjoy the rain.

Share this video