Agile Consistency vs Flexibility: Creating a Culture of Change – Webinar

Presentation Synopsis

“We need to get everyone on the same page”
“We need to be able to talk the same language”
“We need to do things the same way”

These are the arguments frequently heard to justify the need for Lean-Agile centers of excellence and methodologies. While consistency is necessary, are we conflating conformity with consistency?

The benefits of adopting Lean and Agile practices are based on creating an environment that facilitates learning and flexibility. Yet by enforcing one specific methodology or tool across teams, organizations hinder their ability to deliver customer value.

In this webinar, Steve Adolph, addresses the challenges organizations face when adopting Lean and Agile methodologies and presents a three-element model that enables organizations to create a consistent and flexible culture that motivates practitioners to embrace change for faster delivery of business value.

Watch the Webinar on Demand

Presentation Transcript

Top of Form Myriam: Good evening, good afternoon and good morning to all. We’re very glad that you’re going to be joining us today for our webinar “Consistency versus Flexibility: Creating a Culture of Change”. My name is Myriam Sanie and I’m with the marketing team at cPrime. We’re very happy to be partnering with Tasktop on this presentation that will address several issues and challenges that face organizations today as they strive to remain relevant in this ever-competitive marketplace. Before we get into some housekeeping details I’d like to introduce our speaker Steve Adolph, whom I’ve had the pleasure of meeting a couple of times face to face, so it’s great to see you again Steve! Steve is sometimes “Yet Another Agile Coach,” sometimes an entrepreneur and at other time a management consultant. He provides consulting through cPrime/Blue Agility, where he pursues his passion for helping organizations get the job done. Steve has been creating and managing software development projects long enough to remember Fortran and PDP-11s. His professional career has included many exciting and critical projects, including designing call processing software for digital telephone exchanges, leading-edge network management systems, railway systems and more. He also has a diverse experience and job roles ranging from developer to Chief Engineer to CTO and he has also co-authored the popular book: “Patterns for Effective Use Cases” and the recently published: “Agile Revisions for the International Institute of Business Analysts”. When he comes across a little bit of spare time, if that’s possible at all, he loves playing tag with his daughter, skiing and cycling. And don’t tell anyone, but it’s also said he is an opera lover as well!

Steve: Thank you Myriam, and everybody welcome. I really appreciate you joining us today. The title of this presentation seems to be a little bit of an oxymoron. Agile consistency vs Agile flexibility, because the very nature of agile is to be flexible. How are we getting into a situation where we have to seem to choose between consistency and flexibility? So, this is what this presentation is really all about. One of the main goals of doing an agile transformation is to create consistency within the team so the people can actually work together. A lot of transformations tend to fall short of their objectives and can have the unintended consequence of creating these cultures of conformance rather than a culture of change. And so, what we want to do is try to come up with an explanation as to why this can happen. We’ll compare mechanistic models of organization with organic models of organization and finally we’re going to present a 2+1 model for systematically creating consistency and a culture of change. This is where my colleague Philippe Kruchten is going to help us out a bit. Let’s just take a look at a typical agile transformation. Here’s something that I often see as a consultant working with an organization, so-called islands of agility. What you see here is we have three different teams that are using different tools. You can see one using Visual Studio, another one using Eclipse, and probably a management team using of course, Excel. And they talk different languages. For example, if you ask 3 people what is the definition of a feature, you’ll probably get 5 different answers. So, if these teams are completely independent, that may not matter, but if we’re needing these teams to work together, then we really are starting to have a problem. We need to have some kind of consistency because there’s a big problem with these islands of agility. First of all, the fact that they use different tools, that they speak a different language, it really creates a barrier to these teams being able to work together. They can’t reuse and share knowledge, and it’s challenging to manage. How do you measure teams working on a wide variety of different processes and having different meanings? How do you have a repeatable process and it’s difficult to improve that. How do you systematically improve what are effectively all kinds of different practices in an organization? Management wants to seek a solution to these problems and management’s about solving problems so our executive here, she says: Look, we need everyone to speak the same language if they’re going to work together. So, the first thing that happens in a lot of transformations is to create an Agile Center of Excellence, or sometimes called Lean Centers of Excellence, or Consistency Programs, but the intent is to get a group of respected individuals in the organization to drive the change. And you can see here our exec is briefing the team that’s been selected saying: Look, we’re doing an agile transformation and you’re going to lead the change. One of our goals is creating a consistent structure so that our teams are all on the same page and can work together. And in good form you can see that one of the members of this team is going: you’re right! and this is in addition to my day job and will likely adopt a methodology and also probably bring on a coaching team to help us with the methodology and of course the coach enthusiastically says: yes! I think the comprehensive agile methodology will help get all your teams on the same page. So, we do exhaustive training of the teams. They are trained in the methodology: We explain to them the rules, the practices, the work products that have to get created. And the result is here we see all of our three teams now are all using the same tools or using the same processes; they’re all speaking the same language so our exec is going “finally we have a consistent structure.” The question we want to start asking though, is can structure on its own create alignment? Are we using structure as a proxy for alignment? One of the great mantras in the agile world that was sort of coined by both Alistair Cockburn and Jim Highsmith is people trump process and look at the conversation that is happening here. We have our executive and she’s talking to one of the analysts, and she’s going: “How could you miss those dependencies? Our methodology has all kinds of coordination meetings. Aren’t you holding them? And our analyst goes: “Well, we are, and when we were in that we all of us heard the same thing and we all thought we were on the same page. It turns out I guess we weren’t and then the structure facilitate flexibility and our ability to adapt. Here we have one of our engineers coming up and saying, “some of these practices just aren’t going to work for us” and our exec saying, “well if we don’t have consistency we’re going to have chaos” and then she accuses the engineer saying, “you’re just saying that because you find that change is inconvenient.” Then what happens to our culture of change if we are over enthusiastic in our desire for consistency? Here we see a team that’s one to try something different and somebody comes from our Agile Center of Excellence and says: “That’s not how we do agile”, and completely shutting down the opportunity for change. So, what’s the result? Well, as you can see here, our team’s not looking very happy. You notice the charts here are kind of showing that the trend, for the demand for software for profit and for hope, is not trending very well it’s going down and here’s our executive going “but we’re agile I thought things were supposed to get better with a consistent structure.” Something that might be of interest to you here: The current issue of the Harvard Business Review for November or December. It has a very interesting article in it about corporate transformations. How they have a miserable success rate, over three-quarters of the change efforts flock. Now this is for the overall transformation of a corporation, not just focused on the software team. But it is some evidence that backs up anecdotally what I’m observing in a lot of organizations that a lot of the early enthusiasm for the agile transformations seemed to be resulting in flops, or they’re not meeting their objectives. Here we see our poor executive saying, “we did everything right how did it go so wrong”. I’d like to go to the first poll here and ask you: Does any of this seem familiar? Such as, this is my life right now, or sort of we’re in the midst of a transformation and we’re seeing some issues but overall it’s moving in the right direction, or no we’ve got a great transformation going, or you just don’t know. So, take a few moments…

Myriam: Steve, we see here that about half of our respondents are in the middle of the transformation and they’re still experiencing issues. About a quarter of them say that, yes this is what their life looks like right now, 10% say that they’re really in the middle of a successful transformation, which is a great thing to hear, then about ten percent say that they don’t know because they’re still exploring their options, maybe looking at what is going to be the best thing for their organization. How do you see those results? Are you surprised by these or is that what you expected?
Steve: That’s a bit of what I expected and that was sort of the motivation for creating this presentation in this webinar. I would say that the people who are doing well on the transformation, congratulations guys, because one of the things that we really want to put out there is that this is not easy. Doing the transformation is one of the hardest things that you are going to take on and one lovely friend of mine who I was working with at a major US health insurance company, she was able to dig up research that showed how hard change was. That research suggested that for people who have recovered from a life-threatening illness, only one in seven people were able to make the lifestyle changes necessary to have a guarantee of a longer life. That’s a frightening statistic because it suggests that we all love our lives and yet only 1 in 7 people are capable of making the lifestyle changes necessary after having a major health event. How hard could that be? How hard is it for a corporation or an organization to make those changes? For those of you in the “sort of” category here, part of the intent behind this presentation is to say “yes, it is hard keep pushing and maybe here’s a few things you want to take a look at”, and the “yes” I hope some of what we will be talking about here will explain and may give you some insight into some of the issues that you’re running into. But the numbers really tend to back up what it what I’m seeing anecdotally.
This is the thesis I’d like to put out: Seeking consistency by standardizing practices and tools in knowledge-based work processes-and I regard engineering software development as knowledge-based work processes, risks creating unhealthy processes. I look at our organizations as ecosystems and by creating standardized practices and tools, we’re creating an unhealthy ecosystem because we risk creating processes that cannot adapt. To understand this, let’s take a look at two models of consistency. If anything, the biblical story of the Tower of Babel taught us that we need consistency to work together. That’s just plain and simple. When we talk together we must be able to understand each other and have the same perspective. We’ve got to be able to communicate, we’ve got to be able to exchange resources, bottom line, we have to have consistency to work together. The question now becomes, what do we mean by consistency? In many cases, we have to ask is consistency, conformity? This is one of the questions that we really have to challenge ourselves with. When we say consistency, are we saying conformity? The definition of consistency really depends on how we see our organization, and if any of you have done a MBA program or interested in this, you may have seen this book by Gareth Morgan ‘Images of Organization’, where he presents multiple models of an organization. How organizations could be modeled as a machine, how it can be modeled as an organism, how it can be modeled as a neural network. Here we choose to take two examples, to explain consistency or define consistency. We’ll look at the organization as a machine and we’ll look at the organization as an organism. Now the machine model of organization comes from our good friend, Frederick Taylor. Many of us in the agile community love to use Frederick Taylor’s name as a curse word, as pejorative, but he wrote those principles of scientific management where the focus on the organization was as a machine and therefore efficient operation, being able to produce the most goods and services for the least cost. He described an organization, therefore, as the best way to set ourselves up was to have a bureaucratic organization with well-defined job descriptions, management by objective. Think of a factory model, mass manufacturing. We’re setting production quotas and we train people in very small jobs so the responsibility for planning lies with management. If we apply this now, this machine model of consistency, it gives us what we would call the software factory and some of you, here in my age demographic, may remember in the late 90s and early 2000 that was actually considered to be the ideal software development model, was to create the software factory with very well described defined job descriptions, well-defined artifacts all enforced by a single tool. That was even computer assisted, software engineering was playing a big role in that. But the question I have to ask you, is the software factory the solution? Mechanistic models work really well where there’s little need to adapt, and you have to look, in your organization is there very little need to adapt? Are the tasks straightforward? Is your environment stable, there’s no variation in your products? That just doesn’t sound like the traits of knowledge work. That doesn’t sound like the traits of any engineering or software development organization that I’m familiar with. Knowledge work requires we have flexibility. We see two cases here where one that our analyst was wanting to try to see if we could do something better, one of our lead engineers is saying some of these practices just aren’t working for my team and they’re getting shut down by our exec who’s saying, “if we don’t have consistency we’ll have chaos.” She’s clearly thinking in terms of the machine model here. There’s another way we can look at the organization, we can look at the organization as an organism. Here the model is popularized by Burns and Stalker in a book published back in 1961 called ‘The Management of Innovation,’ but what they were looking at is the emphasis on the ability of the organization to adapt, not so much on efficiency. Now to run a business, yes we’ve got to be efficient, but not at the cost of our ability to adapt. Burns talks organizations as open systems, management’s job is now to create balance between the organisms in the system and the outside environment, and most importantly there are different species of organization who need different types of environments. In other words, think of in your own organization, the company I’m sitting in right now they do hardware, they do firmware, they do software, they have applications. All of these could be looked at as different species, having different needs and they have to be able to work together but they have different needs in the way that they interact with the environment. This came up to what was sometimes called contingency management, that there was no one best way of organizing. The role of management now is not to run the bureaucracy and keep cost down, but how do we keep these teams aligned and working together? How do we get good fits? Now, if we look at the organization from a biological point of view, we see it as a diverse ecosystem of organisms that must be able to all live together and exchange resources. Now we’re saying, these teams are their own organisms, but how do we set up the info ecosystem here so that they can exchange resources and work together? That gives us our biological model of consistency, where we say consistency is the capability of the organization to create a healthy environment that facilitates the interaction between all the different organisms, the islands of agility, in the organizational ecosystem. Now using those two models of consistency, we can kind of understand why some of our transformations may go off the rail because if we say that our organization really is an ecosystem but we impose a machine model of consistency then that’s the equivalent of saying “pave over the swamp,” create what we call a monoculture. Some of you, especially those of you from Los Angeles, you can probably immediately recognize this cliché metaphor here the LA River and the reason I chose it is because the LA River came about as a U.S. core of engineering project to prevent flooding in the Los Angeles River. There was a natural river and it was flooding so the solution was pave it over. It’s really a lovely, visual metaphor to say does this look like a vibrant ecosystem to you? Does this look like a healthy ecosystem to you? What happens when we create these model cultures? Here’s an example, monocultures lack resilience. This is a Cavendish banana and this is the banana you go to the grocery store and buy and Cavendish bananas are clones. There’s a major problem right now, there is a blight that is wiping out the Cavendish banana crop and this blight has been basically able to take over because there’s no diversity in the banana crop, therefore, there’s no resilience to change. What we have here is a situation where we have a monoculture, all the bananas are a clone of each other we now have a blight. The blight has been able to quickly wipe out the crop. We have a lack of resilience. Take a look at your own organization, is it like a monoculture? Here we’ve got a shot of probably what’s a call center in an organization, people working on standard practices and procedures, they have a script that they follow. What happens when they get a call or get a task that’s off script? How well can this organization adapt? How well can it tolerate disruption? Here’s another problem in a monoculture, we get invasive species. These species, for example, the monoculture lacks resilience, they’re able to take over the empty spots in ecosystems. These are zebra mussels and they’re overtaking the Great Lakes. These are a real problem they are clogging the intakes for water treatment plants, industrial treatments. The effect is, there’s no natural predator for them and these empty spots have occurred in the ecosystem, they’re able to rapidly take over. I use that metaphor to describe the situation that I see in a lot of organizations, where we’re doing a natural transformation and we impose a single vendor tool, and what I noticed starts happening is we get all these rogue tools popping up. Now we install your high-end vendors, agile lifecycle management tool which is absolutely gorgeous, and people continue to use their Excel spreadsheets in the background. They actually are running their programs off their Excel sheets or they’re using a web-based tool because they’re finding the mandated tool inconvenient to use or doesn’t serve their needs. So you start getting these invasive species and so the chance of having that one tool over it within the organization is lost because all of these other tools are starting to spring up like an invasive species to fill the gaps in the ecosystem. As a result, the organization of monoculture creates this unhealthy organizational ecosystem. It lacks resilience, in other words it cannot adapt in the face of change and invasive species fill in the spaces within the ecosystem making it hard to communicate and share data. So, the argument I’m making to you is that realistically, rather than creating a monoculture, we need to embrace the diverse multimethodology universe. Let the teams select the methodology that they want to use. Alastair Coburn, who is one of the most noted agilist, is author of one of the signatories of the agile manifesto, in his doctoral dissertation asserts that every project deserves its own methodology. Well saying that sounds like a total recipe for chaos, and say who needs consistency right? Let everyone do what they want, but that’s not what we’re arguing for, we’re arguing for balance. A really good colleague of mine, Neil Harrison a few years ago, coined the term “liberating form” and he used it to describe enough structure to channel and create it had release and liberate, creative people can’t work in randomness but given enough just barely sufficient structure we can release that creativity to our benefit. That’s the approach we want to start taking with our methodologies tools, start thinking of them as not as tools of conformity but as tools as guardrails to create that liberating form, minimize the mandated practices to what is necessary to liberate that creativity. Jim Highsmith, one of the original signatories again to the agile manifesto, a barely sufficient process. So that sounds great. It sounds very pie-in-the-sky, how can we systematically do that? Well for that now I’d like to turn this over to my good colleague, Philippe Krutchen, and have him explain a model for creating a systematic approach to transforming our ecosystem. Philippe.

Philippe Krutchen: Thank you Steve for inviting me to join on the webinar. There’s a vast spectrum of software projects out there, even in a single organization. So how are we going to try to achieve what Steve was trying to message this morning: flexibility on one hand and conformity on the other. Where is the balance? The reason Steve invited me, well he hooked on a little fable that I wrote a few years ago called “The Frog and the Octopus”. We’ll go through the fable and I’ll read it and then we can get to the real business. So, a frog and an octopus met on a software project that was deep in the bush. The Frog said: All these projects are the same, over time we feel with our work the gaps that we find between the burgeoning product and the dreamed intent. “Oh, no!” objected the octopus; “They cannot be the same! They come in all forms and shapes and size and colors and we cannot use the same tools and techniques. “Like the cobbler in the shop one size does not fit all.” In software development and hardware that one size does not fit all. However, when we look at that vast spectrum of project there are two things we can identify that is common across all projects and what makes them viable. What is common is shown on this slide. All projects shared those four kind of entities. All projects have some form of intent, it may be a very rigorous software, it can be just a shopping list somewhere, it can be in your backlog. It takes different forms but you need to have an intent so you need to know where to drive the car to, and this in turn will evolve over time, and it evolves differently in different type of project, different type of organization. Then across you have the product, this is much more objective the software product we can look at it, it’s on ClearCase or whatever, we can assess it. It also evolves over time and hopefully it implements some or all of your intent. In turn and products are also the two elements where we can discuss about value. The intent has some expected value, and the product has some actual value this is what we sell this is what we distribute. Now the magic thing that makes the intent turn into a product is the work that we do. That in some ways, it can be in Microsoft Project it can be in post-it notes across my screen, it can be on a Kanban board. There is some representation of how the work is going to evolve over time, and in software engineering we’re still not that good at that. Then there is the magic ingredient, if we had a machine that would transform the internet into the product that would be magical, this would be the automated the software factory that Steve was in T2. Unfortunately, the work is done by people, so we have people, they evolve over time at a different level of quality or competency, and work and people this is where we have cost. The cost of software development, and we have to balance the value and the cost. So, all those elements, you’ll find them in your project; whether it’s a two-person, two-week project or they all have some form of internal product work and people. Now there’s another part of that model. Viability, that’s where the octopus said, “all the projects are different” and we’ve known for many years what makes projects very different. The number one thing that makes projects very different is size, in whatever unit of measure you want to count it, lines of code person months, function points, you name it. Size will make things very different. You will need much more processing tools if you have 50 people than if you have 5 people. Then there’s a few others that vary. Team distribution is usually a big impact, also criticality of the software. If the software that you develop may kill people you may have a much heavier process behind. In the age of the system, are you working on some brand new greenfield development or dragging this huge 16-million-line legacy, the type of governance that you have in your organization, the business model, how is money flowing, are you selling software on some platform, are you developing software internally? All these things need to be understood in your project and contrasted with the common path in order to decide what kind of process you need. Those two models are a good starting point, a good lens for you to decide how to achieve some form of conformity in some of the tooling techniques, just the jargon that you use to speak about your project in an organization, and the viability will drive how much of this tool and what kind of tools do we need. Then I will give to back to Steve. There is the third thing, there is the runtime approach. You can have a static description of your process using the frog and the octopus, but the new paradigm that Steve developed piggy backs on the frog and the octopus and tells the things about the social dynamics, the thing that happens on a daily, hourly basis, weekly basis in your team.
Steve: As Philippe led in here, one of the often-overlooked aspects of the transformation are the people themselves. In the software factory, people were treated as mere animators of the process. That was trying to really move towards a machine model of conformity. Well if you look at this picture, these people probably don’t look too conforming. Most studies will show that how people work together, i.e. the informal agreements and day-to-day plans people make, completely swamps out all other factors force that determines success. That’s where we introduced this plus one part of the model, the so called “Newt.” The newt evolved from a study where we are asking people, how do you manage the process of software development? The biggest problem people cited was, “but we’re just not on the same page” and then we’re looking at, well what are the processes; the social processes that people engage in to get them on the same page and who are the people and what are their roles? So, this model here called “reconciling perspectives in the newt” was developed to capture the social roles of how people work together to create alignment. The argument here is that the creation of alignment is very much a social process. It’s not something we can just create by structure alone, by putting people into a coordination meeting of some kind. So now we have two models of change. Now we can start explaining what the differences are, why some of these transformations may be going off the rails, and how we can address and intervene. So, the first model here, the machine model, effectively this is pave over the diversity of the ecosystem, install the methodology and then expect our context and social systems to adapt. This is strictly where we’re only interested in the frog, we’re just interested in the practices, therefore, and our drivers have changed, the center of excellence is the enforcer of that change. So, they see consistency as conformity, we expect our social systems and context to conform to create consistency. On the other hand, we have an organic model that embraces the diversity of our ecosystem. Our goal is our practices, our context, and social system change together, we don’t say that just our technical system or our practices are superior. We say in our social system, in our context, we need to change them all together, one enables the other. Here’s our last poll and I would just like to quickly ask what model of change have you experienced in your organization? Is it mechanistic? You adopt it as a specific methodology and you were all expected to adapt to it? Is it organic? While we adopted a specific methodology, we’re working hard to integrated holistically, we’re adapting the methodology. It works, different roles, different people or the one I call “chaos and magic” everyone does what they want and somehow it all magically comes together or you just haven’t really thought about it.

Myriam: We have our answers and we can see that it’s pretty split. So about 35% of you said that you’ve adopted a specific methodology and adapted, about 30% say that you are holistically adopting a specific methodology, and about 23% say that pretty much everyone does what they want, and 10% of you have not been through a transformation yet. So again, Steve are you surprised by these results?

Steve: I’m not surprised, it’s the chaos in magic one that actually did catch me, that there’s a lot of that, that seems almost high. The interesting part here is, and something we’re not capable of doing but I would ask people who are in the organization’s answer these two polls, is to correlate. For those who said, after we asked the first poll, “yes we’re having problems” could you correlate it? Are you doing a mechanistic approach or is it organic? Is there a correlation? This just gives you a pause to reflect. Are we having problems because it’s chaos and magic, or is it because we’re taking the mechanistic approach and it’s crushing our healthy aspects of our ecosystem? That would be a very interesting correlation to think about and I would ask people who participated in this poll and in this webinar, see if you can make that correlation for yourself within your organization. I’m going to move on here so now with our two plus one model and our look at mechanistic models versus organic models, let’s revisit our agile transformation. How might that be different now? I want to put a caution in here, it is really easy to delude ourselves that we’re building an agile organization because we’re saying we’re adopting an agile methodology. How could agile be bad? I want to argue that agile in itself, the difference what we’re talking about here, is between doing agile and being agile. I think many of you may have heard pejorative “oh they’re agile in name only” and so what I’m asking you here as we go through this is start using our frog, octopus, and newt model to think about what does it really mean to be agile, versus just doing it. So once again we open our story where management is concerned about the islands of agility these teams have to work together and of course the fact that they use different tools and they use different terminology is a significant problem for the ability of these tools or these people to work together and therefore we need some kind of consistency. A good approach still is, of course, to create the drivers of change, the agile center of excellence. But look at how we’re changing the mandate, we’re doing an agile transformation and you will lead the change. One goal is creating an ecosystem that enables our teams to work together. So rather than you are imposing a structure, your goal is to create that ecosystem. Unfortunately, this is still in addition to their day job. We adopt a methodology or maybe two methodologies, but the difference here in the conversation is look what it becomes. Rather than the methodology will give the structure to get everyone on the same page, I think that comprehensive agile methodology will help as a guiding framework. We’re starting to try and use that methodology, remember I made that reference to the liberating form? How do we use the methodology, now as that liberating form to unleash people’s creativity rather than suppress it? Of course, there’s needs for training, if we’re going to introduce a methodology. Of course, we have to train people. But look at the angle of the training also. So here we have our coach, let me tell you about the comprehensive agile framework but first let’s make sure we understand the economics that drive this do you understand the intention here? Because now what we’re asking people to do, yes the we have this framework, it’s going to be your liberating form, but we also want you to understand what it means to be agile not just to do agile and we want you to have the knowledge and the intent so that you are able to make better quality decisions as you adopt this. This starts helping us create a facilitating ecosystem around our teams but then the question of course is how do these chains exchange, how do these chains work together, they’re all using different tools. How do they exchange resources? How do we create that healthy ecosystem where they can exchange the resources? Well my suggestion is here don’t go and impose the one true tool on people. Yes, we will probably have to have a goober tool that helps us collect data from the teams but interconnect and integrate the tools I mean this is one of the reasons of course that Tasktop is an enthusiastic sponsor but this is a realistic consideration because otherwise you’re going to end up with this rogue species starting to come into the organization. So, where we can, let’s look at enabling diversity by integrating and interconnecting our tools rather than forcing everyone to adopt the same tool because people working in a team and are closest to the work probably have the best idea of what they really need to get their job done, so the tooling facilitates that exchange of resources rather than as a tool of enforcement. So now we can look at how these conversations might change when our chief engineer comes and says some of these practices aren’t working for my team. And our executive saying well is it because you’re finding it hard to change or what is it about your context that we have to adapt to and rather than our center of excellence for agile enforcing practices on teams that want to try something different and we’re much more facilitating of the awkward to nature to learn. One of the members of our CoA comes out and says: Hey you guys seem to be doing something different. We just wanted to see if we could try to reduce our story writing effort. Let’s see what we can learn then as long as you stay aligned with our principles, going back to that idea of the liberating form and run this as an experiment. What I mean here by experiment is an experiment in its truest terms: hey we think if we do this we will get this outcome so let’s do this for a couple of sprints and see if we get that outcome and learn from it. Also, we do need structure, we do need to set up our coordination meetings if we’re two teams to coordinate but again how would this conversation change, and we had our coordinating meetings we went in we missed something. People really do trump process. Who in your organization can really facilitate those meetings? Who in the organization could be the boundary spanners who go from team to team and really get people aligned? You cannot just rely on the structure. There are roles that people play naturally where they focus on helping getting people aligned. So here you see for example the conversation changes. Well why have we got Lydia to facilitate the meetings they’re going great, because clearly Lydia is one of these people who wants to get brick she’s got the personal strength and the tact to get to the bottom of things. She listens to a conversation and wait a minute that doesn’t sound right to me. She just doesn’t accept it so here Carlos is going earlier our analyst is going great idea she knows how to make everyone get on to the same page and no one would dare miss a meeting so by looking at all dimensions the frog in terms of practices and then the octopus in terms our context and the newt in terms of our social dynamics, we could get on to the same page or have a better result. So, to summarize our two approaches, in the Frog our methodology is used as a tool of conformance. In a more organic model where we were holistically optimizing both the Frog the octopus and the newt, the methodology is used as a tool for encouraging change. The COE in the mechanistic model, our center of excellence mandate is to roll out the methodology. In our organic model the COE’s mandate is to create a healthy ecosystem. In our mechanistic model people are just mere animators of the process and our organic model people are intrinsic part of the system. We look at the talents and capabilities of our people as we’re working with trying to build that healthy ecosystem. The mechanistic, we don’t encourage experimentation, that’s seen as non- conformance. In our organic, we’re encouraging experimentation. The mechanistic we have a mandated tool suite. In the , we’re trying to integrate diverse tooling. The downside of the organic model is, this is something everyone has to participate in. Process improvement is not solely the responsibility of a few appointed members to the center of excellence. This is important because this is a quote from Barry Bain who I’m calling meeting one of the grand patriarchs of software engineering, said “personal attributes and human relations activities provide by far the largest source of opportunity for improving software productivity.” In other words, it’s a long-winded way of saying “people trump process.” So just a couple of final words here I love this quote from John F Kennedy “conformity is a jailer of freedom and the enemy of growth.’ If we are interpreting consistency as conformity we are restricting the ability of our organization to learn and grow. That is how we get back to original title of agile consistency versus flexibility. If we are forcing conformity we’re jailing the freedom of our ability to adapt and grow, the flexibility that we need. Here’s a quote from Charles Darwin, “it’s not the strongest of the species that survive, nor the most intelligent the ones that are most responsive to change.” We adopt agile because we believe we need to create an organization that can adapt to change. But just because we’re adopting agile doesn’t mean that we’re not creating a mechanistic organization. Organizations that fossilize mechanistic processes, even agile processes, are destined to become fossils themselves. So, to summarize our biological definition of consistency. Consistency is the capability of the organization to create a healthy environment that facilitates the interaction between all the different organisms in the organizational ecosystem. This picture in the background, by the way, is also the LA River. In Los Angeles, there’s a major attempt to rehabilitate the LA rivers ecosystem. To summarize, consistency is not conformity, that is the lesson I would really like to get across. The enforcement of standard practices and tools creates a monoculture by paving over a vibrant ecosystem. We introduced the 2+1 model the frog ,the octopus, and the newt which represent the different perspectives of knowledge work. Also, a consistent and effective consistency program where we want to create an organization that the teams can work together, the consistent for the team to work together, means we optimize the Frog the octopus and the newt holistically. We’re arguing that it is better to interconnect and integrate our tools rather than forcing everyone to use a single tool to convey conformity. There’s a bibliography of the books and papers we’ve referenced in this presentation. I want to thank you all for joining me today, I really appreciate it. I want to say please feel free to reach out and contact me if you have any questions, I would love to hear from you. Your feedback, questions, comments on this presentation and I think that we have a few moments here for questions.

Myriam: so we have several questions that are emerging from the great presentation that you gave us. I think they kind of revolve around two things, so one of them is going to be change management and the people and the employees concerns and perspective. Then the other one is kind of like surrounding the boundaries of team flexibility. So, I think those are the two themes that are emerging. Before I ask you the specific questions that have come through, somebody brought up the fact that software development is really creative work and it’s more like an artist painting a picture, which I thought was a beautiful analogy. To start us off with our questions, so Cheryl asks, how can this approach take the time to address employee concerns and fears of adopting a new approach and what can we do to address those fears and concerns? I think that’s a question that is addressed almost universally when we talk about transformations and change in an organization.

Steve: I really thank you for that question because that is the root question and that’s my daily my daily job, is working with organizations. I would say that it very much is that the transformation cannot be seen as something that’s done to the employees, it is something that they are part of. A lot of transformations, and this was the example that I gave sort of at the beginning of this presentation, was where the presentation was an executive met or the transformation was an executive mandate and it was driven top-down. Most successful companies I’ve been with, it very much was both top-down and bottom-up. Management set the vision, we need to do this but engage the employees and encourage that engagement. For myself, I think that is one of the most successful patterns that I see. We really do need to look at these transformations as both bottom-up and top-down. Upper management really has to set the vision and the importance behind the transformation. Why are we doing this? What benefit does a company get? What benefit do the people get? What’s in it for them? Then give them the opportunity and the resources to participate in that transformation.
Myriam: Great! John kind of commented that flexibility is critical. Then there are kind of two questions that kind of go hand-in-hand, so I’m going to ask them both at the same time and if you want me to repeat just let me know. Michael said we want to give the teams flexibility in their process but where is the cutoff? Should we allow them to kind of have free rein? Like what would be a happy medium? Then kind of a question related to that is what are some parts, some examples of parts of organizations that maybe we can make more consistent as opposed to parts that can be more flexible.
Steve: This is one of the things you have to keep in mind here, this process of transformation is not one and done. We don’t sit down a number of rules and say ,this is the boundary for the team. It really is an ongoing experiment. In agile we’re very big on talking about the retrospective and unfortunately in most organizations, the retrospective czar either not done or they sort of deteriorate into a rote complaint session. So, for the question here where the balance is, it really is what’s our best first approximation. What do we believe is going to get give us our liberating form, that I’ve talked so much about here? Then let’s start executing that and inspecting and adapt. This is ongoing because that outside environment, the whole reason we’re doing this in the first place, is that our outside environment is changing and the whole point of this is have an organization that can adapt with that environment as it changes. This becomes the rule of management, remember, the in the organic model, management’s job is to understand that this is an open system and it has to be constantly seeking and re seeking the balance. So, that may not be the most satisfying answer but it’s saying if we’re trying to structure ourselves as an adaptable organic organization, it means we’re always experimenting and adapting. It means we’re doing that because we strongly believe that we have to be able to respond to change. That’s going to mean change in the way that we organize and work together.

Myriam: Alex was asking, what are some examples of parts of an organization that can be consistent, versus parts that could be flexible. So, kind of a hybrid model of what you’re suggesting.

Steve: That’s an interesting question, again it becomes very difficult to say. I say the level of consistency that you require, one of the criteria you would have, is how independent are the teams? It’s like if we went back to the first slide and we showed the three teams, they were they were following different practices, they were using different tools if those teams have absolutely no need to interact with each other, we really don’t need a lot of consistency other than, how do we make sure we’re tracking their hours and pay them. On the other hand, if those teams have to work tightly together, then that’s then that says we probably need a lot more guidance for them to be able to work together. The other, just one tangent I want to take on that too, is always look at why do teams have to work together? Don’t automatically assume your teams need to work together. Always be asking why do these teams have to work together? Then a lot of organizations, what we see is because they have legacy architectures, we find that teams end up having a lot of dependencies than other teams because of the architecture. Perhaps there’s some minor changes or changes we want to plan, that may help reduce the dependencies between the team, therefore, give you more flexibility. In other words, Mary Poppendieck loves the theme “don’t use agile as a band-aid for your bad architecture.” So, that’s a bit of a tangent but give that some consideration as well.
Myriam: Great thank you Steve! Irvine has kind of an interesting question, how can we juxtapose the concept of the least process needed, that you mentioned earlier in the presentation, in a regulated environment, such as ISO9001, etc.

Steve: That’s coming down to what is the minimum process needed and it’s you’re in an ISO 9001 organization. I used to design safety critical systems for railway signaling. There is a foundation, what you’re looking at is, alright what’s the minimum set of practices we need to reach that. This comes down to that’s the whole intent behind the frog, octopus, and newt model. Yes the frog is going to lay down that we are a regulated environment, there are certain mandated practices we have to follow. That becomes part of our context, what is the criticality of the system? It means it is looking at that as, alright, who are the people in our organization here who can help us maintain consistency and stay connected? Because every practice that you put in that mandates how people have to work together. Where you’re ignoring your context, where you’re ignoring the social side of your system, is one more practice that you have to enforce and it simply becomes a significant slowdown to your ability to adapt. One more thing, I’m assuming if you’re doing ISO 9000 or you’re working for a defense contractor, you’re working at a safety critical system. Your rate of adaptation is going to be different from, for example, a Spotify or a startup company or a mobile game developer. This is what the important thing about context is.
Myriam: Thanks Steve. I know we’re at the top of the hour; we have still have quite a few questions so we’ll go over a little bit. If you need to leave, don’t forget that the recording will be available to you. Steve, there are a couple of questions that are coming through that have to do with the change management with the people. Kevin asks: How do you get mechanistic people to start thinking organically and it’s hard and a lot of times it’s very hard for people to accept change and then on the same line Jairaj says he’s worked with some people who find change is extremely hard for them. So how can we help those people to adapt to that new reality and to change their viewpoints?

Steve: Welcome to my life! First of all, one is understanding what motivates them? What is motivating those people and really to understand them. I’ll be very straightforward, I’ve been in this industry long enough to remember pdp-11. I’ve worked in engineering organizations where, “here comes the change of the month. If I just keep my head down it will go away.” So especially a lot of people who’ve been through that, they may be taking that attitude towards the change. So first of all, it truly is understanding what’s motivating them. The second is starting to work with people in the organization, the thought leaders the respected individuals who really can inspire the others that. They’re saying, “look if Omar is doing this, this has to be a good thing to do so let’s give this a try.” The other is, find a team that you can work with that can give you a success. There’s nothing that motivates people faster than success. I’ll give you a quick example of this. I was at a large agricultural manufacturer a few years ago where one of their teams had had had a major crisis. They were not going to deliver. It was one of those projects where this was going to break a lot of people’s career and they did the equivalent of a Hail Mary. They asked us to come in to help them with some changes and we made a few changes. The project was able to deliver. I’m not going to say that was because we were totally brilliant. It was that we gave the people an opportunity. They saw a path to success so a lot of people worked hard and they were successful but then started to happen in that organization a lot of other teams are going I don’t know what those guys did but whatever they did we want to do it too. So, a lot of the people who are sort of laggers, they’re more like show me that this works. I’ve been through a lot of this before I’ve heard of this show me that this works, so a lot of it is moral suasion.
Myriam: I hope this helps our audience who are asking questions surrounding this. One more question and I think that’s going to be our last question. Can you comment on the extension of this concept beyond the software world into organizations that are creating devices with hardware mechanical electrical as well as the software component?

Steve: This is something that I’ve always I’ve always wondered. Why do we think that, for some reason, that hardware or firmware are so different? Of course, when I’m designing boards or circuits, of course it’s different. I have different constraints than when I am doing software. But looking at it from the point of view of organizational change, then it’s not this insanely different beast. And I think that’s a mental block we have. My personal view is that possibly, that mental block is a fault in the way that we communicate the agile manifesto, where it says working software over comprehensive documentation. A lot of people think that we actually have to have a working circuit or be able to bend metal in a very short period of time, and that’s not reasonable. What I look at is I’ve always liked to say is what is it that we can do that’s valuable, to quickly show that we’re creating value. I think it’s almost artificial, that we’ve got this feeling that from the point of view of being agile, that somehow hardware is radically different. how we be agile with firmware hardware and any other practice that we want to look at agility

Of course, the day-to-day practice will be different but the philosophy of being agile is certainly not going to change and ultimately what agility is about: can we keep up with the rate of change or can we make our decisions faster than the rate of change ultimately really is what agility is. Can we make decisions and adapt as fast or faster than the rate of change? But of course, some industries change slower than others.

Myriam: Yes absolutely. I think you’ve hit on a very important point there. We’re out of time and I would like to thank you so much today and for sharing some really great insights for real word to think about. I also want to thank Philippe for a wonderful cameo appearance that was very well regarded from some of the questions that I got and then to everyone in our audience who have joined us really a heartfelt thank you for taking the time to be with us today and really being so engaged and asking so many great questions. It was hard to keep up with all of the great questions that you were asking. We really hope you got some value out of the session. If you have any additional questions or are interested in additional conversations or need help, please feel free to reach out to Steve, Tasktop or cPrime using the emails we have listed, and finally we will be sending the slides and the recording out to you so watch for it in your inbox within 24 to 48 hours. We also hope that you’ll join us for any of our upcoming webinars in the next few weeks. We’d like to thank you again and enjoy the rest of your day. Thank you everyone.