Integrated Agile

Transcript

Brock Argue  Thank you Cherie. It’s good to be here. Thank you everyone for joining us for our session today on integrated Agile. We’re very excited to explore this topic with you and this concept that we have. Our focus today will be exploring the interplay between Waterfall and Agile, and how organizations can manage the resulting dynamics to their benefit. We’re going to introduce you to a tool called Polarity Management, which can be used to get the most out of any change effort. And lastly, we’ll introduce you to a new concept called Integrated Agile, which aims to help organizations leverage the upsides of both Waterfall and Agile. So why is this important? Well, as an industry, we have been transitioning organizations to Agile delivery methods, frameworks and processes for over twenty years now, and we’re not getting any better at it. Failure in Agile transformations is the norm. One of the reasons for this is that organizations operate in a mixed methods environment, where neither Agile nor Waterfall are the solution to the problems that organizations face today. It’s about time we all realize that and embrace the need for both approaches, Agile and Waterfall.

Erkan Kadir  Hey, thanks, Brock and so before we go too far, we’ll just take a little bit to introduce ourselves. So as Cherie mentioned I am Erkan Kadir and with me is Brock Argue, we’re both Certified Enterprise Coaches and Certified Team Coaches through the Scrum Alliance, as well as Relationship Systems Coaches. Our company is the Superheroes Academy. We’re based out of Calgary, Canada, and we’re available globally for leadership development, workshops, Agile coaching, and we offer most Scrum Alliance certifications through online programs. Okay, so let’s dive in. We’re gonna start off by talking about an issue that we believe exists in most organizations that do product development globally. Now, we call it the Agile Warzone and we first wrote about this topic in the article that was published in the 2018 Best Agile Articles publication. Now the Agile Warzone can be demonstrated by looking at how Agile and Waterfall tend to treat the Iron Triangle of project management. In this triangle, you have time, resources, and scope and when planning delivery, you can shoot for all three, and in fact, we usually do, but when things go off track, at least one of the points must be movable. And so on the Agile side, on the left here, we have people who believe that the best products are built by teams with relatively consistent membership and who allow scope to emerge over time through the learning that comes from running experiments. And then on the right here, on the Waterfall side, there exists a completely different perspective. This is where people believe that the best way to mitigate risk is by having experts carefully plan scope in advance, and then being elastic with deadlines and resources if things don’t go as planned. And so there’s a fundamental difference in approach here that can make it very difficult for people who prefer emergence on the Agile side to interact with people who expect certainty and predictability on the Waterfall side. And when there are people on either side of the coin, who believe that their way is the right way, and the other way is the wrong way, then we have the conditions for what we call the Agile Warzone. And this is where ‘either/or’ thinking can lead to misunderstandings, passive-aggressive behavior, and, potentially, all out war. Now, unfortunately, the Agile Warzone seems to exist in most organizations, or at least all the ones that Brock and I have worked in it. And one of the reasons that we believe the Agile Warzone is so prevalent is that the war is not actually winnable by either side. And so what that means is that many of us, certainly myself, you know, as an Agile Coach, for a long time we’ve been we’ve been selling Agile as a solution to problems, oftentimes, that can’t actually be solved. And so you might have read the title of our talk, you know, mix agile and waterfall and, and immediately discounted us as heretics who are promoting Wagile or Watergile. And, you know, our intention here. And, you know, certainly if I had-would have read the talk-the title a couple years ago, that’s what I would have thought, but our intention is merely to shift the conversation to reality that Agile mixed with Waterfall is happening in most of the companies that are out there today and so what we’re going to try to do, in this talk, is we’re going to try to equip you with some knowledge and some-some practical tools that will help you to manage this reality in case this happens to be a situation that you’re in.

Brock Argue  And so one of the ways that we can manage the Warzone is with a tool called Polarity Thinking and this was introduced by Barry Johnson in his book, Polarity Management, Identifying and Managing Unsolvable Problems. Polarity Thinking recognizes that all values come in pairs; that each value in the pair has both an upside and a downside and there are predictable dynamics that define the relationship between the two values. So we’re going to start off here by introducing you to a polarity – um – to Polarity Thinking. Usually one of the dilemmas that Agile companies have to manage: how to support the individual and the team. And I like to use the metaphor of a moving walkway to highlight the dynamics that exist within polarities. See, as an organization favors the individual, the upside that they will receive, for a time, is that of individual initiative, which you see here is characterized by individual creativity, and entrepreneurial spirit, fewer and shorter meetings, freedom and addressing personal needs. Given the polarity dynamics that are at work here and, like I mentioned it’s like a moving walkway, the organization will naturally start to move towards the downside of the individual pole, which is isolation. This is experienced by a lack of common direction, only being rewarded for homeruns; no synergistic effect, no team support, and selfish ‘me’ talk. Now once in the downside of the individual pole, the organization reacts to move back to the upside, this time by favoring the team pole. And this is a common shift that we see in organizations that are transitioning to Agile ways of working, moving from bring the individual pole to favoring the team pole. But in the upside of the team pole, the organization now enjoys the benefit of a cohesive unit, which includes having a common direction, recognition that each job or role is important, that synergistic effect, team support, and personal sacrifice in favor of team success. Remember, Polarity Thinking tells us that we’re still on this moving walkway. And so the organization will eventually start to experience the downside of the team pole, should they favorite long enough, which manifests itself as bland sameness, meetings having too many and for too long, least common denominator, team burden, and neglect of personal needs. In other words, too much conformity. These polarity dynamics, as we’ve just witnessed, are in evitable. So how do you know when you’re dealing with a problem to be solved? Or a polarity to manage? Well, answering ‘yes’ to these questions here tells us that you’re likely dealing with a polarity to manage. Is the difficulty ongoing? Are the alternatives interdependent? Are the upsides of both poles necessary, and will over-focus on one pole undermine the greater purpose? We believe that the challenges we try to solve when we move from Waterfall to Agile are not problems but polarities to manage. So let’s look at each one of these four criterion of problems or polarities in the context of Agile transformations.

Erkan Kadir  Okay, so we’ll start off by evaluating whether Agile and Waterfall is a polarity or a problem by looking at polarity test number one: is the difficulty ongoing? Well, the Agile Manifesto was published almost 20 years ago now and a whole industry has formed around Agile transformations and so I would expect that if this problem was solvable, then we would have many shining examples of companies who have eliminated their Agile Warzones through complete and total Agile transformations. But let me share with you a few items from the 2020 State of Agile report from version one, to demonstrate that this doesn’t seem to be the case. 95% of respondents said that their organizations practice Agile, so Every company in the world almost at least outwardly reports that they’re at least trying to do Agile. But at the same time, a whopping 82% of all those companies indicated that not all of their teams have adopted Agile practices. So logically, then I would take this to mean that we can expect a mixture of Agile and Waterfall in at least 82% of the organizations globally. Now, hold on a second, that also means 18% of the software companies out there are supposedly doing Agile well. So, surely those companies have found a way to completely eradicate Waterfall with a consistent and enterprise wide approach to Agility, right? Well, it looks like even the best among us haven’t yet figured it out. Because the survey then goes on to indicate that Agility in those companies is still only largely confined to Development, IT, and Operations; meaning that the rest of the company is still also using traditional approaches and we can expect to find a warzone in those companies too. And so for all of the Agile coaches like us, transformation approaches and scaling the frameworks that exist. If I was to ask the question, ‘Is the difficulty ongoing?’ I would have to say ‘yes.’ So let’s move on to polarity test number two, are the alternatives between Agile and Waterfall interdependent? Is there a relationship there where they affect one another? Well, if you look at it, we can’t really have Agile without Waterfall. Because we work in an Agile way iteratively and incrementally, we’re really just doing a series of mini waterfalls. “But wait!”, you say, “Aren’t mini waterfalls just a an-Agile anti pattern?” And, you know, maybe and, you know, we’ve read all those blogs and stuff, too. But, but let me use Scrum to demonstrate what I mean because Scrum dominates the industry with 58% of all Agile teams globally using using it. While the next closest method, Scrumban is only being used by 10%. And so in Scrum, each iteration, when we look at it, it’s really just a phased approach where a team first has a requirements gathering phase; that’s the Backlog Refinement. Then they have a plan and design phase; that’s the Sprint Planning Meeting. Then they have an execution phase; that’s the Sprint. And finally, they have a verification phase; which is the Sprint Review. And so the cycle repeats every few weeks but the interdependence actually works the other way around as well; where we can’t have Waterfall without Agile and so every Waterfall project that we’ve seen, has some sort of change management process built into it, so that they can continuously update their plans as more is learned. And while much is made of the high cost of these processes, this is the Waterfall way of leveraging the upsides of Agility. Because without Agility or the ability to learn and adapt to our environment, the purely Waterfall company simply ceases to exist. And so at this point, we want to point out a paradox that we’re going to come back to later on. Agile and Waterfall are mutually inclusive, and interdependent op-opposites. And what we mean by that is not only can we not have Agile without Waterfall but the more we favor one, the less we’re going to have of anoth-another – and again, we’ll come back to that because it might be a lot to think about at first – and so to answer our polarity test question number two here, ‘Are the alternatives interdependent?’ We would say ‘yes.’ Okay. Let’s look at our polarity test number three. Are the upsides of both poles – Agile,  Waterfall – necessary? Again, we believe the answer is yes, and one of the best ways to demonstrate that is simply by looking at the values from the Agile Manifesto, which will populate on the screen here. So on the left, we have values that generally, as Agilists, we want more of, and on the right we have values that generally, as Agilists, we want less of; which are generally more aligned with the values we would see in a traditional or a Waterfall organization. And so, the upsides of the Agile items on the left are obvious because if they weren’t necessary, we wouldn’t have 95% of the software companies globally trying to do Agile but the upsides, uh, of the Waterfall items on the right are also just as important. Because if you think about it, without processes and tools, we wouldn’t actually have Scrum or management systems. Without documentation, we’d simply incur the waste of relearning. Without contracts, we wouldn’t have customer relationships. And without planning, we wouldn’t have any Sprints. And so the Agile Manifesto even has this famous line written on the bottom that says, “While there is value to the items on the right, we value the items on the left more” and so this is one of the confirmations that we can use to show that both sides at least have some degree of necessity. Now, the often-recognized genius of the manifesto is that it acknowledges that all values come in p- *clears throat* – all values come in pairs. But as you’re going to see in the next few slides, favoring one side over the other, as we’re doing in the Agile Manifesto, actually presents a very big problem from the perspective of polarity management.

Brock Argue  Okay, so the last criteria in determining if an organization is dealing with a problem or a polarity is, if overfocus on one pole undermines the greater purpose? And the answer to this in the context of our discussion here today is a resounding, “Yes,” and we’re going to look at a couple of examples here just to kind of see how this works, and what this looks like with respect to Waterfall and Agile and the challenges that organizations face. So here, we’re going to chat about the first of four case studies that we’re going to share with you to highlight the dynamics of polarities. Each case study focuses on one of the four value pairs from the Agile Manifesto and so here in case study number one, we’re going to start off with the ‘Individuals and Interactions’ and ‘Processes and Tools’ polarity, in which this organization favored the individuals and interactions. So this client company profile here, it’s a startup company that had grown to be roughly about 500 employees. They have a product that’s focused on corporate giving and volunteering solutions, and kind of the DNA of this organization: social causes, diversity, and inclusion; very important to who this company is. Now, through the growth that the organization had achieved and the culture that they had, this led to slow decision making, and very expensive meetings. There was a need in this organization to include everyone in discussions and to make decisions by consensus. Leadership of the organization started to call this out as an inefficiency that needed to be addressed. HR put in place meeting guidelines and protocols to ensure that there were clear agendas for meetings and attendance lists that made sense. Every meeting had to have a documented outcome or set of action steps. They even went so far as to provide formal training and meeting facilitation to all employees. So what happened for this organization? Well, favoring the individuals and interactions for most of the company’s history led to slow decision making inexpensive meetings as the organization grew. Leadership and HR tried to counteract this by formalizing meetings through protocols, training, and documented outcomes. This led to reduced ownership in the organization since, “Well, I wasn’t involved in that decision and no one asked me.” As soon as the organization became aware of the reduced ownership and alignment, they quickly refocused on the Individuals and Interactions pole, effectively leaving the organization in the downside of the pole, they had favored the most. So we’ll move on to our second case study and, in this one, we’re going to be referencing the ‘Working Software’ and ‘Comprehensive Documentation’ polarity from the Agile Manifesto. So, this organization is a well established Fortune 500 company in the Canadian Energy Sector. They have a very traditional culture and organizational hierarchy and the work of the organization generally occurred in the context of projects; where they had a definitive start and end date and traditional Project Management throughout. Now, this organization understood the need to take a different approach to some of their work in order to keep up with the innovations of their competitors. The desire to move some segments of their business into taking more of a product-centric approach rather than a project approach, as they had been so far. So they brought in Agile coaches to work with an internal team to design, build, and test this product-centric approach of theirs. So what happened to this organization? Well, due to the traditional history and the inertia that that history created, this organization learned to favoring upfront-lean to favoring upfront learning in an effort to reduce uncertainty. They just created a need in the organization for comprehensive documentation before changes could be made to the system. The vast amount of documentation and approvals required caused a slowdown in the results that the team was able to achieve and, ironically, led to missing out on opportunities for learning. The organization just wasn’t ready to embrace the ‘Working Software’ side of the polarity no matter how hard the Agile coaches pushed them to do so. One reason for this is that as the team started to just build stuff, and learn through experimentation, leadership became very uneasy with decisions that were being made  and the lack of clear governance that they had become used to over the years. This led the organization to move back toward the ‘Comprehensive Documentation’ pole very quickly, causing them to receive the downside of that pole. These first two examples center around favoring one pole, and that by doing so, organizations receive the downside of that pole. It’s important to note that continuing to favor just one pole, and doing so to a large degree, will lead through seeing the downsides of both poles. So what you’ve observed through these first two case studies is what happens when you overfocus on one pole. This is referred to as the One Pole Myth. That myth states that if we focus solely on one pole, we are able to get the upside of that pole without any of the downsides of either poles. But the reality is that by favoring or overfocusing on one pole, we will only get the downside of that pole and as I just mentioned, if we hold on to one pole long enough, we’ll get the downsides of both poles. For example, and as we saw in case study number one, we might stick closely to individuals and interactions, because we fear reduced ownership and decisions. But we stick to that pole so tightly, that we create a culture of consensus decision making, which slows us down in getting anything done, and leads to blame and finger pointing; which is the downside of the ‘Processes and Tools’ pole. So, let’s do a quick recap based on the case studies that we’ve provided so far. Is the difficulty ongoing? So yes, our industry has yet to consistently implement successful Agile transformations in organizations. Are the alternatives interdependent? Yes, Agile frameworks include defined processes within them. Erkan, earlier, he showed us how Agile can’t exist without Waterfall and vice versa. Agile and Waterfall are mutually inclusive and interdependent opposites. Not only can we not have Agile and Waterfall, but the more we favor one, the less we’re going to have of the other are the upsides of both poles and necessary? Yes. Even as described in the Agile Manifesto, there is value in both sides of the polarities that organizations must manage in order to be successful. And lastly, will overfocus on one pole undermine the greater purpose? Yes, our experience and case studies that we have shared tell us that overfocus on one pole leads to the downside of that pole and, eventually, the downside of both poles.

Erkan Kadir  So we just spent the first bit of this presentation making a case for Agile and Waterfall being a polarity to manage not a problem to solve by implementing one side or the other. But because we’re not going to spend-or we’re not going to spend too much time putting Agile and Waterfall up on a polarity map directly, because we believe that it’s actually a meta-polarity that contains many other polarities and we find it more immediately useful, and practical, for organizations that want to explore Agility to manage these polarities individually based on the specific challenges that they’re facing. And so the four values or polarities that are listed in the Agile Manifesto, plus the dozen or so that are listed on this screen are just some of the polarities that are out there and in fact, once we become aware that polarities exist, we start to notice them absolutely everywhere. And, so, we also just want to, um, give a little warning at that point when we say that; that not all polarities are going to be worth the effort to manage consciously, because they’re expensive to do so. And so our suggestion, then, is to look at the business objectives behind each Agile transformation and, first, understand what are the unique polarities that are at play here, so that we can then select the most impactful leverage points to manage consciously. Okay, so here’s a situation that might sound familiar. You’re working in a company that uses a traditional Waterfall approach to build products and the time it takes to deliver new versions of the product keeps increasing and is now measured in years. Certainly, this has happened for many organizations that I have worked with. And so you start losing market share to your competitors and somebody eventually comes up with the idea to solve the problem by doing an Agile transformation and so your company brings in new leadership, they train everybody in Scrum, and then they fire anybody who threatens the new culture. And so there’s lots of excitement around the change an-but at some point, people start to realize that, you know, Agile is actually a lot harder to implement than they thought and, you know, it’s been it’s delivered some benefit but it hasn’t solved all of the problems that we thought it would and in fact, now the company has a whole new set of problems to deal with. And so your company gets fed up waiting for the results that were promised that don’t seem to be happening. And they start to view Agile as maybe just not practical and there’s some grumblings that the transformation was a mistake, or it wasn’t done well and so what do they do? They bring in new leadership again and this time, their job is to fix the problem but they’re going to do a large transformational change effort to fix the problem but they’re going to do it by going all the way back to the first place that they came from. And so this cycle that repeats endlessly, back and forth, like this, is unfortunately very common. Because when big organizational change efforts favor one pole, they end up only in the downside of that pole, due to the One Pole Myth, or at least they spend most of their time than the downside of that pole. And so then another change effort takes place in the opposite direction, favoring the other pole and the cycle just keeps on repeating endlessly and it’s a dynamic that Barry Johnson in his book, Polarity Management, calls the polarity two-step and it’s really unfortunate, because we spend most of our time in the downsides of the poles instead of the upsides. We alienate people unnecessarily – kind of harkening back to the Agile Warzone – and we generate lots of costly resistance. And so the point we want to make here is that by seeing either the upside of either pole, Agile or Waterfall, as a solution, or as more important than the other, is a setup for it to be called a mistake later on, which is exactly what the Agile Manifesto sets us up to and this is a problem because, as Agilists, our industry has been an u-an unbalanced crusade in favor of one pole over the other, in an unwinnable war, for the last 20 years and this is why we say that Agile versus Waterfall is not a problem to solve, but a polarity to manage. Instead, we drop the word versus, and we look at this polarity as Agile and Waterfall. And so here’s the good news, dynamics in polarities are actually highly predictable and when we’re aware of these dynamics, we can manage them in such a way as to spend most of our time in the upsides of the two poles instead of the downsides and that’s what we’re gonna be showing you today.

Brock Argue  Okay, okay, fine. So we can’t have the upside of just one pole, from a polarity because of the One Pole Myth. Well, then, I’ll set up my company and processes in such a way as to get the upside of both poles at the same time. Unfortunately, this too, is not possible. Since the two poles are opposites. It’s not possible to have them both at the same time. This is called the Merged Pole Myth. When we try to get both upsides at the same time, we actually end up getting both downsides instead. For example, given that our greater purpose is breathing, let’s look at the Merged Pole Myth in the context of the polarity, inhale and exhale. If we try to inhale while we’re exhaling, which is aiming for the upside of both poles, we get neither upside. Instead, we accumulate CO2 and use more oxygen than we’re breathing in giving us the downsides of both pools. We see companies doing this all the time. “We’re going to do Agile” they say, “but you have to tell us when it’s going to be done and what we’ll get on the other end.” “We’re going to do Agile” they say, and the team is empowered but managers and architects still have the final say. “We’re going to do Agile” they say, “and learn through experimentation…but you better not fail.” The Merged Pole Myth, or the worst of both worlds, is what we think of when we hear the terms Watergile or Scrumfall. The reality is that when organizations try to get the upside of both Agile and Waterfall at the same time, they end up with the downsides of both poles, missing out on the benefits of Agile, while eroding the clarity and rigor of Waterfall. Our case study on the Merged Pole Myth focuses on the ‘Customer Collaboration’ and ‘Contract Negotiation’ polarity from the Agile Manifesto. So here we have a small boutique consulting firm, it was founded about four years ago, who specializes in Agile coaching and training. Not being new to the industry, and in a quest to achieve some level of income certainty, his organization valued signed contracts with their clients but because they’re an Agile consulting firm, they wanted to walk the talk so they also valued customer collaboration. In doing so, this organization attempted to get the both get both poles at the same time, by having customers sign contracts that focused only on the collaborative relationship between the client and the consultant. So what happened? Well, as you can expect, by trying to get both poles at the same time, what they feared about each pole became true, and they received the downsides of both poles. This led to conversations with potential clients that remained contentious over contract terms and since they hadn’t discussed pricing upfront, the consulting firm didn’t feel like they were being paid fairly.

Erkan Kadir  Okay, so we talked about the One Pole Myth and the Two Pole Myth. So we’re damned if we do and we’re damned if we don’t. So how do we manage polarities well? Well, it starts with being willing to take on multiple perspectives and we’re going to demonstrate that with an example. So take a look at the picture on the left. Notice that without the faces, the goblet can’t exist, and vice versa. Now, maybe we’re the kind of people who value goblets over faces, so we make the goblet bigger,and then we make the faces smaller. But when we value the goblets too much, we lose both the goblets and the faces altogether. And so here we have another paradox, a set of mutually interdependent and inclusive opposites, creating a polarity to manage. Now, you might have seen the faces first or you might have seen the goblet in the middle first but notice that both the goblet and the two faces cannot be perceived at exactly the same time. And in fact, Robert Desimone, from MIT’s McGovern Institute for brain research was able to prove that the brain is capable of only holding one of these perspectives at any one time. So either one stands out and is clear or the other does. However, if we’ve seen them both at least once, we can easily switch between the two by making a conscious intention about which perspective we’re going to take on and so both perspectives are accurate, but only partially. And we like this picture because it can help make the distinction between accuracy and completeness. When we’re able to take on the perspective from only one pole in a polarity, it’s our incompleteness combined with our conviction, that we see the whole picture that is the source of a potential problem and you can see where we’re going with this with the Agile and Waterfall. So if I tell you that you’re wrong, because there’s no goblet, and you tell me that I’m wrong, because there’s no faces, then there’s going to be no end to our argument; one of us is going to need to switch perspectives in order for us to progress in our discussion, but who’s gonna go first? Somebody has to recognize that this is a polarity to manage and say, “Hey, you know, maybe this is not a situation in which we have either a goblet or two faces. Maybe this is a situation in which we should be looking for both the goblet and the faces, maybe we could both be accurate. And so paradoxically, then, opposition is turned into collaboration when the statement, ‘I don’t see what you’re seeing,’ or ‘I can’t see what you’re seeing’ becomes, ‘help me to see what you’re seeing.’ And so the point we want to, um, make here is that ‘either/or’ thinking can be supplanted with ‘both/and’ thinking to manage polarities well. Now, take a look at the picture on the right. Now, this was the individual and the team polarity that we looked at earlier. Notice the parallel between seeing the faces, and seeing the two diagonal quadrants on the polarity map in the right. Just like the first picture, we can only take on one perspective from a polarity map at any one time. And usually, we can only see the upside of our favorite pole. And the downside of the pole we’re trying to move away from or the one that we’re afraid of, while being completely blind to the downside of our favorite pole, or acknowledging that the por-pole we fear even has an upside and that’s what’s represented in these black squares here; what we can’t see. And so the example that we have on the screen, we can see the upside of valuing the individual and the downside of valuing a team but with a little bit of courage, and maybe a lot of courage, we do have the option of intak-intentionally taking on the opposite perspective from our polarity map, as you can see here, um, so that we can see the downside of our favorite pole and the upside of the opposite pole and we can always switch back and forth. But unfortunately, as we saw in the Agile Warzone example, there’s often a very serious and cothly-costly confrontation that takes place because a ‘both/and’ polarity is treated like an ‘either/or’ a problem to solve and people only bother to take on one perspective or the other. When we can take on a polarity perspective ourselves, we also increase the possibility that others will take the time to look at the other perspective because we’re confirming their truth and we’re not contradicting the reality. So…let’s jump out of the theory for a second and get down to a little bit more practical use of: how can we use some of the lessons from the last couple slides to manage polarity as well? And the first thing I just want to say here is that polarities are unavoidable and unsolvable and so the question is not if we’re going to manage them, but how well are we going to manage them? And so here’s five skills that you can use to manage these polarities well.  Number one is simply knowing that we have a polarity to manage, rather than a problem to solve and we can do that by answering the four questions that we walked through at the start of this presentation. Number two, knowing that there’s an upside and a downside to each pole. And you can do that simply by filling out a polarity map, write it down. Number three, maintaining a sensitivity to the downsides as they’re experienced and so here we have to ask ourselves, well, what quadrant of the polarity map are we in right now? Are we enjoying the upside and things are great of a certain pole? Or have we maybe held on to that pole for a little too long;  we-maybe we’ve overfocused it and now we’ve started to slip into the downside. And then number four, this is where the courage is needed, this is where we have a courage and a willingness to shift perspectives and to actually drive up and across into the other pole that maybe has been marginalized. And number five, is knowing how to talk to and mediate between people who take on opposite perspectives. So we’d like to use the analogy of walking a tightrope as one that can help us understand what it’s like to manage polarities well. Now our tightrope walker, in the picture here, you can imagine that he is acutely aware that there is an upside and a downside to each pole that he’s got – both left and right – and so what he’ll do is, he will fully shift his perspective and either lean left or lean right when he’s gone too far to one side or the other. When he’s just learning to walk the tightrope, as you can imagine, his shifts will be extreme, right, as we’re just trying to figure this out from one side to the other and that’s a lot like the polarity two-step that we talked about in organizations. Maybe if they’re just trying to figure out this Agile and Waterfall, they do a big transformation and then they go too far and then they-they try to correct it by going way too far back. But if you think about an expert, tightrope walker, somebody who’s a master at this craft, as they become more skilled, their shifts between perspective becomes smaller and smaller, and eventually they’ll be barely perceptible. Okay? And that’s the analogy we want you to hold as we talk through our fourth case study. This time, it’s a company that was able to manage a polarity well and so this company was able to do that by listening to the early warning signs, that they were slipping into the downside of each pole, and then switched perspectives early enough to spend the majority of their time in the upsides of those two poles. So for this case study, we’re going to be examining the last polarity that we haven’t spoken about yet from the Agile Manifesto, which is ‘Responding to Change’ and ‘Following the Plan’. So this company, was founded about 20 years ago, in the energy sector, and they have a pretty mature Agile implementation, where they’ve been doing Agile for over 15 years. And so our case study starts in the upside of responding to change. Because this organization has Scrum teams that were fully empowered to innovate and work directly with stakeholders and clients, leadership was very comfortable with ambiguity, and they had a high degree of trust in their teams, and, you know, even though they didn’t know what would finally emerge from that customer collaboration, they were seeing value being created, and so they believed that they were doing the right thing and they were content. And so what happened with this organization is, not only was everybody happy, but they were they were doing really well. They had innovative solutions and-and general market leadership in their space. But what happens, as you can imagine, as the moving walkway goes, while their general tact of allowing solutions to emerge was working well, they also noticed that at times, they would need to plan and meet commitments And so one example was the Agile user conference or – not the Agile just a user conference – where customers wanted to know what would be demoed before they were able to confirm attendance. And so when they resisted committing to demo any particular scope by the deadline of the user conference, they received an early warning sign that they had been favoring the responding to change pole at the expense of the following a plan pole, which for them was that sign-ups for their user conference were unacceptably low. And so now this company was smart and they understood that there was a polarity to manage here, and they were hyper aware that they were shifting from the downside of ‘Responding to Change’, and they weren’t as concerned with saying, “Oh, you know, if we-if we switch, we’re not going to be Agile anymore” and-or-or these types of things. And so they were able to switch their perspectives over to the ‘Following a Plan’ pole and they did this by working out the features that were sure to make a splash at their user conference, and then working backwards from the date that they needed to hit, and they ran that particular project, a lot like a traditional Waterfall one, and you know, things were a bit hectic at times, and there was some overtime – closer to the deadline – but they did complete the projects on time, and the conference was a big success. And so here they are enjoying the upsides of ‘Following a Plan’ pole and you can guess what happened after the conference. Leaders kept asking for their team for detailed plans and they kept holding their teams accountable to delivery dates, even though there wasn’t any specific milestones that needed to be hit. The leaders generally got a taste of the certainty that following a plan and managing to it provides and they really liked it. But again, this, uh, this company was aware enough to watch for early warning signs that they were slipping into the downsides of the current pole, which included reduced flexibility, and loss of self organization in their teams, and, of course, less innovation. And so they quickly realized that it was time to switch back to the Agile pole. And so if you look at the polarity map, or I guess the moving walkway that we’ve drawn on top of this case study, you can see that while even the well managed polarity case study spends some time in the downsides of each pole. They’re astute enough, and aware enough, to know when it’s time to switch perspectives so that they spend most of their time in the upsides of these two poles.

Brock Argue  Which leaves us with the challenge facing most organizations in the world today, getting the upsides of both Waterfall and Agile, and what we’re calling Integrated Agile. To get more value out of Agility, we need to be willing to move away from it once in a while. The genius of the Agile Manifesto is that its creators recognize that all values come in pairs and while the current manifesto recognizes that both are important, we’ve learned that you can’t have both at the same time. The manifesto attempts to solve this dilemma by favoring one set of values over the other. This is ‘over/more’ thinking but remember, the One Pole Myth? ‘Over/more’ thinking is simply ‘either/or’ thinking in disguise and ‘either/or’ thinking can only lead us to the downsides of the values on the left. The Agile values are a crusade from the downside of a more traditional approach into the upside of Agility, which is exactly what the software industry needed in 2001. But those values are only half of a dynamic that needs to be managed because all values come in pairs. The other half is the inverse of the Agile Manifesto, where we value processes, documentation, contracts, and plans over the items on the left. By learning to manage both poles, organizations can maximize time spent in the upsides of both poles. That’s why we’re suggesting the Agile Manifesto could use a small upgrade by replacing the word ‘over’ which promotes ‘either/or’ thinking. With the word ‘and’ we’re promoting ‘both/and’ thinking. We recognize these values as polarities to manage, not problems to solve. We call this the Integrated Agile Manifesto because it reintegrates values that have been marginalized for some time. You can find out more information about the Integrated Agile Manifesto at integratedagilemanifesto.org. “But wait, that’s blasphemy,” you say, “you can’t change the Agile Manifesto. It’s a perfect unalterable and sacred document.” Well, actually, Agile uprising recently did a podcast series with 14 of the 17 signatories of the original Manifesto. And when they’re asked, “What advice do you have for the next generation of Agilists?” the one message that they had in common was to not take the Agile Manifesto as gospel but instead continue to build upon it. We hope that the Integrated Agile Manifesto honors their work and builds upon it in a way that will help companies manage the practical realities of a mixed methods approach. And so as we wrap up there, we’ve got a few resources, where you can find out some more information here obviously integratedagilemanifesto.org. We just also like to thank Beena Sharma from the Vertical Development Academy who introduced us to Polarity Thinking.