Making Agile Work With Metagility (With David Bishop From Agile Worx)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Ben Aston: So let me guess, you were doing things  Waterfall, and that didn’t work, and then you tried Agile and well, that’s not really working either.

So now you’re mixing and matching. You’ve got a scoop of Agile and a scope of Waterfall and you’re trying to find some sprinkles to put on top. Well, keep listening to today’s podcast about metagility. And you might just learn a thing or two about how an Agile playbook can be used to combine the best of both worlds.

Thanks for tuning in. I’m Ben Aston, founder of the Digital Project Manager. Welcome to the DPM podcast. We are on a mission to help project managers succeed, to help people who manage projects delivered better. We’re here to help you take your project game to the next level. Check out thedigitalprojectmanager.com to learn about the training and resources we offer through membership. This podcast is brought to you by Clarizen, the Leader in Enterprise Project and Portfolio Management Software. Visit Clarizen.com to learn more.

So today, I’m joined by David Bishop and Dr. David Bishop is a technologist. He’s a consultant. He’s a research entrepreneur and instructor with more than 25 years of experience in Telco, transportation, government, and utilities. He’s the CEO and founder of Agile Worx, LLC. You can check that out Agile-worx.com. And they’re a firm that provides program and project management software tools, training and consulting services. And he’s the author of Metagility: Managing Agile Development for Competitive Advantage. So thank you so much for joining us today, David.

David Bishop: Thank you for having me.

Ben Aston: And I want to dive into this whole idea of building a framework from nothing. Can you tell us a bit about your background and how you decided that, hey, the world needs a new framework? What’s your course, your kind of experience that led you to that point?

David Bishop: Right. Well, I’ve been in the technology development business for about 25, five years, and mostly as a systems architect and systems engineer, developing solutions with new technologies. And the IT business, as well as in the IATA business and cellular and telecom and all that stuff. As you mentioned earlier, about 10 years ago, I started working with a company that was deep into Industrial IoT and one of the things that they were trying desperately to do was to adopt Agile methodologies.

Ben Aston: Right.

David Bishop: And the reason for that is because their customers were asking for it because they weren’t they were in a new industry. And they were in this new industry where, well, relatively new in new technology, I should say, it wasn’t a new industry, but it was a new technology. They were trying to integrate into this industry. And there were a lot of competitors out there who were developing this new smart grid technology with all the different RF communication.

And that was behind all this technology. And so. They tried several times to adopt Agile because it was critical for them to try and use Agile to get their products out to market as quickly as possible. They tried several times hard, lots of highly paid consultants, and just failed miserably. Time after time. And I was a part of this. I was helping this organization develop these products and also helping them try and adopt Agile in the process as well. And I thought, you know, there’s got to be a different way to do this.

Why is it that so many of these very smart consultants that we bring in have had so much trouble here? And what I realized was that, unfortunately, Agile has had all the great success and it certainly is a great idea. It has had some shortcomings and in many ways. And one of those is had issues with distributed teams, large teams, but also very complex development environments and complex or complicated products. Those can be huge challenges for people trying to adopt Agile methodology in its purest form.

Ben Aston: Definitely. So, I mean, tell us a bit about your experience involved in those projects. I’m curious as to the kind of on the ground. I can understand the kind of big picture of what the kind of challenges was with an Agile implementation, but kind of on the ground the day today. What did that look like? How was that problematic in kind of the day to day of being involved in the project? What is the kind of what were the warning signs to you? I guess knowing that something wasn’t quite right?

David Bishop: Well, there was tremendous resistance with some of the teams. And I’m not just saying on the off shucks kind of resistance, it was really hardcore resistance and complaints that the process just wasn’t working and couldn’t work. And the reason for this is because this was an embedded systems environment. In other words, because they were developing IoT or industrial IoT products, these products were not just software, these products were devices. And devices are typically composed of embedded systems where you have the hardware, firmware, and software developed by different tracks, different teams, sometimes different departments, sometimes different companies.

But at some point, all three of those components have to be tested and released as one cohesive product. And that’s what this company was doing. And that’s what makes this context so interesting today because that’s where all your innovation is happening today. Years ago, when the manifesto first came out 50, 20 years ago, it was all about software. But today, it’s not just about software.

It’s about devices, smart devices, smart meters, smart cars, your cell phone. Everything is an embedded systems device today, really. And so those types of companies developing those kinds of products have the hardest time with agility because of the complexity. And so from a day to day basis, we were working with the consultants we were working with. We’re trying to say, OK, you know, we’ve got your software teams doing two weeks, France, and they’re doing daily standards. But we can’t seem to get your hardware guys to do the same thing. They don’t think it’s necessary.

Ben Aston: Right.

David Bishop: And the firmware guys were having the same problem. They were like, well, you know, this doesn’t seem to work very well for us. It doesn’t make sense. And it was true because the software teams were working much faster. They were developing, they could develop and iterations. But it certainly worked too well with the hardware teams that didn’t work that way. Their products had like a 12 to the 18-month release cycle.

So you know, it just took a long time to assimilate a chipset into the hardware and to thoroughly tested. And then, of course, you know, most of most organizations who develop embedded systems, embedded systems, have a tendency to be in industries where there’s a lot more regulation, regulatory compliance, government oversight and things like that.

If you think about smart meters and power utilities or smart cars or an avionics system within an aircraft, you can imagine that because the stakes are so much higher with respect to potential lives lost or potential catastrophic failures. And what those failures could cost, you know, that they have to meet a much better system, typically have to meet a much higher bar of quality and performance and success. I should say, than a typical software application or an ecommerce Web site or something like that,.

Ben Aston: Which is right.

David Bishop: Where most of your Agile, which were the industries that assimilated Agile methodologies, the most. The quickest and the earliest.

Ben Aston: So, yeah, if you want to read more about the genesis of Metagility, you can check out the post on thedigitalprojectmanager.com. He chronicles how this evolved in the story of creating the book. So rather than diving deeper into that story, I want to dive into this actual framework and see if we can find some nuggets that we can apply to our projects. And I think this is highly relevant because I think for many of us we have tried elements of  Waterfall.

We do things sequentially because that’s what seems to make the most sense because of the stakeholders that we have, because of the way our engagements are structured. But then we also try some Agile stuff in terms of the themes we apply. We work collaboratively, we work iteratively. So there’s bits and pieces that we pull. There’s the philosophy that we kind of bought into with Ok, let’s iterate. Let’s deliver value often.

Let’s build, let’s test, let’s learn. But then actually we have to work sequentially. So I want to talk about metagility and how we can apply that to our projects. And the reality that we’ve been talking about here is the Agile methodologies are popular. They are widely accepted as the best way for managing software development. But what actually Agile methodology is mean is wide open to interpretation.

And as we’ve been talking about, represent a real challenge for most companies. So this hybrid approach, although it’s not often lauded as the best solution, is actually the de facto results for many people at that, trying to cobble together different frameworks and ways of working with the constraints of the organization that we’ve just been talking about. We’ve been talking about, hey, hardware that takes the build cycle is longer than software, and the middleware takes, again, is somewhere in the middle there.

So building things, we can release things at the same cadence. And that’s the kind of challenge we have as well. Sometimes with Web development where sure, UX and design can process things quickly. But development takes much longer. So I want to talk about really the problem that you see in a kind of let’s dig into the I guess, the performance, the limitations of Agile methods that you talk about in your book.

When you see the limitations. I mean, we’ve been talking about the cadence and the release cycles and how that works. But can you dig a bit deeper into these limitations that you see with the current Agile methods out there? I mean, let’s compare with at a high-level safety and that kind of a low-level tactical level Scrum. What do you see as the limitations of these?

David Bishop: Well, I would say when you’re talking about those frameworks like, say, for Scrum, for example, Kanban, there’s a host of others. Right. There’s DSDM and there’s LeSS there’s a DA or Disciplined Agile, which was recently purchased by PMI. It would be interesting to see how that goes.

Ben Aston: Yeah, I’m not buying a framework. That’s nice.

David Bishop: Yeah. So they tried to attack the problem in different ways from different directions. You know, there’s been a lot of when it comes to the reasoning for assimilating Agile methodologies. I think many people often get it a little bit wrong or somewhat askew. There’s been a lot of push these days or a lot of focus these days on adopting Agile because it makes your teams work better together or it makes you a better leader or produce it increases the efficiencies in some way. And that’s all. That’s all great and good.

But the real purpose behind Agile was it was about competition. It’s about being number one in your market. If you think about the Agile manifesto was a directive of lean manufacturing. It was a software application for lean manufacturing techniques that came out of the Toyota production system based on that paper that was written back in 1979 by those two Japanese researchers. And what did that do for Toyota? Well, it took Toyota from being a company that made a tin can cars to being one of premier or the premier automaker in the world, possibly.

And so the whole idea behind agility is to try and duplicate that kind of success, to become number one on your market. And many of these frameworks have, in my opinion, sort of forgotten that when you look at safe, that focuses it at the enterprise level, the 30000-foot level, because it’s focussing on Agilizing your every aspect of your company, whether it’s, HR Department or your legal department.

The idea is that you’re trying to Agile’s every aspect of your company and your operations and hopes that this will provide some incremental improvements over time. And it also focuses a little bit too much to some extent.

A sort of a process I find is probably not a word–“propensities”—but it’s sort of over analyses and basically warf, you remember years ago, before you had user stories and before you had living documentation produced by collaboration tools, you had these long SOP type documentation that we used to use to support mainframe systems and legacy systems 20, 20 years ago. And in some ways safe. Reminds me of that because it produces these long for these very expensive procedures and processes for handling different aspects of your business in an Agile way. There’s not necessarily anything wrong with that, but its sort of it’s the antithesis of what Agile is really all about in some ways.

Ben Aston: Right

David Bishop: And what men agility does is it, of course, Scrum focuses at the teen level. It’s a set of rituals that helps you manage your teams, which is great actually from these frameworks that can be used together. They don’t necessarily conflict with each other. You can use Scrum, you could use Kanban, you can use metagility and safe within the same organization. But what metagility is going to focus on, whereas safe may focus on the enterprise or Scrum’s want to focus on teams.

Kanban is going to focus on the process level. Work and progress. For example, agility is going to focus on the product development engine. It’s going to focus on your product. Product management. Your project management. Your development and testing teams. How those requirements are developed and interpreted by the teams, how the product is tested, and how you’re going to get it out to the market and how you collaborate with your customer so that that product meets their expectations and that you have the highest quality possible.

It’s all if you want to win the race, you have to. If you’re building a car to win a drag race, for example, you’re going to focus on the engine, the transmission, and the drive train. You’re not going to worry about power windows or air conditioning. And so in many ways, I think some of these other frameworks, they do that they focus too much on the periphery instead of exactly what’s needed and necessary to become number one in your market.

And that’s what metagility does, is that it? Based on the research we’ve gleaned out, there were a certain number of case studies that managed to acquire what I call a super Agile adaptation. They managed to leverage agility to become number one in the market, and so meant agility captures everything those companies did right. And attempts to productize it so that other organizations can duplicate the same results.

Ben Aston: So, I mean, you describe it as a comprehensive approach for managing a new and highly effective breed of identity. So is what is the metagility? The delivery framework is a methodology. I’ve seen it also described as a playbook. How would you describe it?

David Bishop: I would just like to describe it is as a framework. it’s it takes you through the process of, you know, the first step. Metagility, for example, is to determine what type of Agile adaptation that you want. Well, actually, I take a step back. The first that the book begins by teaching you how to think differently in terms of using research-based and scientific methodologies to make business decisions.

There’s a whole section in there about that. There’s also a section in there about how the Agile manifesto has changed based on findings of the research. So that’s some of the things that it’s, again, it starts off with. But when you get to the Agile transformation part of it. One of the first things that we talk about is well. How should you adopt what type of Agile adaptation and implementation should you use? Should it be a pure, Agile implementation? Should it be a hybrid approach? Or should you just stick for what, with a  Waterfall? In some cases, maybe you should.

But the interesting thing is that there’s a whole host of research out there, peer-reviewed business research that’s been performed by sea-level experts to answer that kind of question. And in many cases, most consultants don’t even know that exists, let alone use it. And there’s a researcher out there named Barlow who published a paper on how to make that decision.

And I included that in my book as a chart in there where it talks about the type of Agile implementation that you choose should be based on. It is a function of the complexity of the dependencies and interdependencies in your product and organization and also the size of your teams. And so that’s very important. And in many of these case studies, like with embedded systems where you have complex products and large distributed teams, where there is a tremendous amount of interdependencies and dependencies and a lot of interplay between these different components, that kind of complexity means that you’ve got to do something a little bit different. You can’t have a taking a pure, Agile approach across the organization, typically not going to work. You’ve got to do something different in a hybrid approach. If it’s done purposefully can produce fantastic results.

Now, oftentimes, hybrid approaches have a negative perception in the industry, because when we think of hybrid, we think of, oh, Agile or Scrum or fall or we in our minds, we think of a failed implementation. Right. But that’s that was that’s by accident. If that’s what happens when an Agile transformation goes wrong. But if you have a purposeful approach for a hybrid, Agile implementation and you know you’re doing it based on scientific reasoning and research and you know that the way that you’re going about it is also based on the scientific methodology of research. And, you know, you’re going in the right direction for your organization.

Ben Aston: So in terms of this framework, can you describe for anyone who hasn’t read the book how it actually works and what the components of this framework are?

David Bishop: Right. So in the book, I have a huge chart that outlines all those different pieces. And it’s pretty cool. But essentially, the first part of metagility is making that decision, you know. Right. What type of transformation approach should you undertake?

Ben Aston: And how to access payment?

David Bishop: Well, that’s BI using the I mentioned earlier the Barlow’s diagram, which I have in and the book, which is a paper that describes how you can make that decision as a wonderful piece of research. And it’s essentially a function of the size of your teams and also the complexity of your products, the level of interplay or interdependencies between your teams.

And that’s essentially what they’re speaking to, is the complexity of your products. Do you have to figure out, you know, how many interdependencies or dependencies do I have between different teams or different tracks of development to create my products or to create one product? And that level of complexity is is a big guide to telling you whether you should maybe take more of a hybrid approach as opposed to just a few more Agile approaches.

And so the hybrid approach. What is that? Well, met agility includes steps on how to assimilate Agile default. Basically, it outlines what that hybrid approach is. That’s part of what it does. So, for example, your software teams may have two-week sprints, they may have daily stand-ups, but you’re from where teams may have 30 days sprints.

They may have to stand those once a week. And you’re at your hardware teams who operate with a slower, longer cycle time 12 to 18 months typically may or may not have Scrums or Sprints per se. They may operate on more of a  Waterfall basis, but they use certain techniques like rapid prototyping, for example, to try and keep up with the other teams so they can provide them with whatever platforms or testing materials they need to keep moving so that there are no blockers. The whole point, of course, is to maintain the flow throughout the whole process.

That’s very important. And so many agilities outlines what that looks like. It outlines how the different team’s adopters adopt Agile or Waterfall concepts and the  Waterfall, the gates. The stage gating, for example, is adapted to this hybrid methodology by using it as a sort of check and balance. So in a hybrid approach, the stage gating can be a way to serve as a check and balance on all these different tracks that are moving at different speeds to help make sure they’re all in sync, to put it bluntly.

To summarise it and the methodology goes on to outline the different metrics, you should use the and also that the types of interactions that you should use in Agile. We hear a lot about, you know, people in interactions over tools and processes. Right. Or something like that. And that’s what no one ever tells you. What is interaction supposed to be? Well, and then agility.

We break that up into six well-defined categories based on our most successful case studies. We break it up into six categories of interactions and outline what those interactions are and how to implement them and how to manage them. And this is based on, again, case studies that manage to do this the best way. And so it becomes a very detailed playbook for how to manage this hybrid Agile implementation. And then another. Go ahead.

Ben Aston: Yeah. And so how do you determine that proper mix of those Agile multiple characteristics? Because I think by default, you know, people generally respond to change negatively. So as we’re trying to increase agility or metagility organizationally, how do you determine what that mix looks like? And what is the state aware, the status quo is acceptable, and whether evolution or revolution needs to happen within the process.

David Bishop: Right. I think it’s it goes back to using a scientific methodology and engaged scholarship research or engaged business research, as many of us call it. That’s how you’re going to get the best answer. You know, all too often when people talk about doing a little bit of research or they try and figure out how to solve these kinds of problems, they will use their intuition or they will try to make decisions based on best practices or based on interviewing people and trying to get consensus.

There’s nothing entirely wrong with that. And, you know, we make decisions that way and business all the time. But, when it comes to something as challenging and as difficult as an Agile transformation or DevOps transformation, digital transformation, which in many cases are all related, it takes a stronger medicine. It’s time to call on the doctor at that point because, you know, you can treat yourself at home for a while, but eventually, you’re going to get sick enough to where that’s not going to help you. You’re gonna be in the hospital or something.

And so that’s why you know, that’s why I saw this reason. I saw this pattern of failure early on when I started tackling this problem because many of the consultants or experts we were working with were trying to tackle this as they would any other business problem. Okay, this is what worked at my last company. So, gosh, it’s got to work here, but it’s not. How come? Well, you know, if you look at business research, especially business research within the CIS realm, Computer Information Systems, or it’s not that simple because the research tells us that CIS environments, computer science environments or information systems, environments, whatever you wanna call them, are highly contextual.

They differ widely from company to company. And what works in one place is not always going to work everywhere else. But you have to apply if you apply scientific methodologies to do your research like an interpretive case study, for example, then you can do what’s called generalization within certain parameters. And you can glean out what will translate from one organization to the next. There are certain things that won’t. But with by doing enough case studies and applying so the concepts of interpretive case study technique and ethnographies and that sort of thing, you can figure out what is going to be generalizable from company to company and organization to an organization that, you know, is going to work based on your research. It takes a while to figure that out, though.

Ben Aston: Yeah. So this isn’t a one size fits all framework. This is a customizable framework. But I guess the challenge with customized ability is that how do you know how do you evaluate whether or whether or not an implementation is true, metagility or not? How do you evaluate its success?

David Bishop: Oh, that’s a good question. That’s an excellent segue. So part of metagility also includes the theory of Agile Vorticity. And in addition to the hybrid Agile approach and all the findings around interactions and what those are all about and how you adopt Agile with different teams. The other component of managing entity includes the theory of Agile vorticity, which came out of the research.

And this was basically based on what we call a qualitative ground in Syria analysis. And this Agile vorticity concept. Answers the question of how Agile you are or how Agile your organization is. And that’s the big question in this industry and has been for a long time. Okay, we’re doing all this work to implement an Agile transformation. But how do we know it’s done us any good? How do we know where we stand? Right.

And how do we know if we want to get a little bit better? Then how do we do that and how do we know that that’s working? There’s been no way to really measure agility. And so that’s what Agile Vorticity does. And it’s a fairly complex concept that I go into in detail in the book. And it’s based on the research papers. It’s but it answers that question and it cracks that nut wide open. And that’s one thing that I’m one reason I’m so excited about it is because that’s been a gap in this industry for quite some time. So it metagility, you know, provides a way to measure that success.

Ben Aston: And so in terms of the organizations that you’ve worked with that have implemented your framework, what impact have you seen? Have you seen obviously, we started at the beginning talking about, hey, this is really about becoming the number one player in the industry and becoming more competitive. So what impact. Have you seen it? And I guess by your kind of vorticity quotient or I didn’t have that measured what the units are. But how does? What was the impact been told through some stories of that?

David Bishop: Sure. You know, I’d say that many of our case studies were on the embedded systems market because like I said, that’s in my opinion, that’s where the coolest market is right now, the hottest markets and also the most challenging and it is the most difficult case study. And so the companies that adopted meant agility concepts have managed to, in most cases, become market leaders, either number one in their market or pretty close to it.

And what that usually translates to is market share getting more devices on the ground than anybody else, getting more smart devices in people’s hands than their competitors. And that’s what the success looks like. It’s, especially when you’re in new markets, whether you’re a big company or a Start-Up, whether you’re a big company with a new product line and new technology or a Start-Up with something new.

The key to longevity is getting that early critical market share before your competitors do. And that means assimilating innovative technology and getting it out to the market before anyone else.

And Agile is the best way to do that. Specifically metagility, I think. And that’s where our most successful case studies have done is they’ve managed to reduce their cycle times as much as possible, yet maintain the same kind of quality that they wanted to maintain customer satisfaction and. Get these innovative products out to the market and grab that early critical market share before many of the competitors.

Ben Aston: Right, where you’ve seen metagility, not work or the implementation. Come, you know, hit some snacks wall. Why has that been? I know you talk about, the importance of the executive in this process, but what are some of the challenges you’ve seen in metagility implementations? How, how, and where does it get wrong if it goes wrong?

David Bishop: I think it’s two specific places. And you touched on it earlier and that’s gonna be true with any Agile framework is, you know, if you don’t have executive buy-in and support, then you’re not going to get very far. And that’s critical. You have to have executive Buy-in and support on any type of transformation, whether it’s digital transformation, Agile transmission, what have you. It starts from the top and they have to understand what it’s all about. What the goal is always you’re trying to achieve.

And of course, that’s up to me or you as the analyst to put forth a compelling business case so that they understand how it’s going to impact the bottom line and why they’re doing this, that it’s not just about making people happy or putting flowers on people’s hair. It’s about being competitive. It’s about how impacting their bottom line is going to improve their profits. It is going to improve their bonus at the end of the year. And that’s very critical to be able to build that compelling business case and get that executive buy-in.

The second reason that I’ve seen Agile transformations and it can be metagility, but this is a typical, I think in many Agile transformation efforts is poor requirements management. And I think this is an important one. You know, all too often when we take on an Agile transformation, which we’re focussing on the development teams and the testing team. So we’ve got to make sure these guys are or do. We’ve got to make sure the Scrum teams are all set up and organized.

We’ve got to get on two weeks brands that we’ve got to do. Our stand-ups are all that good stuff. But there’s very little focus on the requirements and the business analysts or what we often call in the Agile world product donors. There’s very little emphasis on helping those people change how they develop requirements. Because, you see, there’s when you undergo an Agile transformation, usually, you’re a business analyst.

It becomes the product owner typically. And you have to change the way you develop requirements in an Agile world versus a  Waterfall world. And many people don’t. And how illustrate that to you? So, for example, if I’m in a  Waterfall environment and I’m a business analyst and I’m trying to develop requirements, a lot of times people use the word gather requirements. And in the Agile world, you don’t gather requirements, you develop requirements.

That’s a big difference. What business analysts will often try to do is they’ll try to you. Good. A comment that I often hear from BAs is this. Well, I’m afraid I’m going to miss something. Well, wait a minute. In an Agile world, you never afraid you’re going to miss something because there’s always another iteration of work it in.

Ben Aston: All right.

David Bishop: But you see in the  Waterfall world, you’ve got that well-defined scope. You’ve got that iron triangle, that scope and cost. And you’re worried about scope creep and BI. Gosh, you’ve got to make sure that you gather all the requirements you think you’re going to need because you don’t want to have to change it later. And so BAs typically we’ll try and brainstorm requirements instead of working closely with the customer to define and build them. And what happens, in that case, is they build more requirements, more requirements, more requirements.

They define their success or they think they’re doing a good job based on the number of requirements they build. And it becomes impossible to prioritize all these requirements. And you start stuffing the releases. You start building features that are underutilized and your technical debt goes out of control. Your technical debt just goes through the roof. And that is how Agile transformations fail. And you can make any framework, including metagility, fail if you don’t change the way that you develop requirements.

And of course, I have a class on and I talk about that in the book that you try to I try to train VA’s on being real Agile product owners and say, you know, it’s not just about learning the Agile process. You’ve got to think differently about how you’re building requirements. You’ve got to work collaterally with the customer and use a top-down approach to decomposing requirements based on customer needs. And you have to avoid brainstorming.

Ben Aston: Definitely. Yeah, I’ve been there all too many times. Where are you? That requirements gathering process. If you treat as requirement gathering, it can just last for days or weeks as you dig into all these requirements. And there’s always more things that you can at the end it says. How long is a piece of string? But if I’m new to metagility and you know, this sounds like a sensible approach of marrying the realities of different cadence, of development or different cadences that different teams work with.

And seeing that scene that they can work together. But what’s one way that you would say an organization can apply metagility? That was the foot was that kind of the first step to applying metagility entity within an organization that’s going to benefit the biggest result?

David Bishop: I think that you’re going to have to I think the first thing you need to do is establish. New customer relationships, you know. And, you know, I think one of the tenets of the Agile manifesto talks about customer collaboration over contract negotiation. But what we found today based on the research is that contract negotiation and customer collaboration are really one and the same. It’s one the same process. And this negotiation process happens at all levels of the organization. It’s not just a bunch of lawyers and executives sitting in a room with the client and having them sign a piece of paper or sign a contract.

That negotiation is an ongoing process that happens between stakeholders throughout the company. Your product, product managers, product owners, project managers, your development teams, your Scrum teams, and a host of stakeholders within the client company. And you have to establish that relationship with your client that is going to be collaborative.

That decline is going to be the client is going to help you test, especially if you want to get an innovative product out to market quickly. Your client’s going to need to be a part of that process. And, you know, one of them, you know, do with metagility what we focus on. We talk to executives. We tell them it’s all about. It’s not about a plan. It’s about a vision. And our most successful case studies, they.

They had a vision for where they wanted to go in the marketplace and they made decisions with respect to which customers they were going to work with and which customers they weren’t going to work with. They had to make that strategic decision. They didn’t just sit back and say, well, we’ve got to take on every business that comes our way, every customer that comes our way. We’re not going to turn anyone away because we’re so focussed on trying to make as much money as possible. And that’s not how to win. Some customers had to be turned away by our most successful case studies because they were not willing to participate in this process.

They weren’t willing to be a collaborative client and participate in that high-level collaboration that’s so critical to long term success. And that’s very important. So finding the right clients and establishing that very strong collaborative relationship is probably the first step and figuring out what that vision is for where you want to go and select the clients that are going to take you there.

Ben Aston: Yeah, I think that wise words of advice. I think so often we can take the approach that, hey, we’ll just take whatever comes in the door. But ultimately, if we want to really deliver value to end-users to our clients, then we need the right engagement model that’s going to encourage that collaborative approach. And so that engagement model and establishing trust there so that we can say, hey, you know what, we don’t know exactly what we going to do, but we’re going to collaborate on this together so that we get the best result.

I think it’s ultimately going to lead to the client receiving the best value rather than debating over the black and white of the contract. Much better to have a simple engagement where the trust exists and trust enables that collaboration to occur. So thank you so much, David, for joining us today and talking to us a bit about metagility that’s been really helpful.

David Bishop: Thank you very much.

Ben Aston: And I’d love to know what you think. I wonder if you’ve read the book metagility to see if you have let us know what you think in the comments if you haven’t yet. We’ll put a link in the transcript so you can check that out. But, David, if people want to find out more about metagility and your book — obviously we’ll put a link to the book on Amazon. But where can they go to find more about you?

David Bishop: Well, certainly you can Google the word metagility and it lights up with all kinds of resources. But you can also go to Agileworx.com (Agile-worx.com) and look at our company and what we’re trying to do. We also have some courses available that we’re offering. And of course, those courses typically face to face and they have been postponed until the Fall.

Right now, starting in August through November, what we’re hoping to still have those on-site, but we may transition to some virtual courses. But you can find the latest up to date schedule metagility.technology, so you can go to that website. You can find out what the latest schedule is and sign up for courses. And also, you can reach out to me, David@agileworx.com (Agile-worx.com). I’m always interested to hear from people and I’m checking email all the time, so.

Ben Aston: Good stuff. Well, thanks very much, David. And if you want to learn more and get ahead in your work, come and join us. Join our tribe with DPM Membership head to thedigitalprojectmanager.com/membership and you’ll get access to our Slack team where we are having discussions about things just like this, access to our templates, workshops, AMA sessions, office hours, e-books and more. And if you’d like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com, but until next time. Thanks so much for listening.