Arguing Agile

AA202 - Dual Track Development (aka. Dual Track Agile): Helpful or Harmful?

• Brian Orlando • Season 1 • Episode 202

Share episode

We're taking a critical look at the Double Diamond model, aka. Dual Track Development, aka. Dual Track Agile.

This widely-adopted model might be leading leadership and/or teams astray, so we're taking some time to explore its limitations in real-world applications. 

From the misconception of linear progression to the crucial importance of keeping customers involved throughout the process, Brian tries to convince Om that the model needs significant rethinking!

Other things we discuss are:

  • Why the "messy middle" is where the real magic happens
  • How to properly involve your whole team in both discovery and delivery
  • The importance of continuous customer involvement
  • Why organizational support is crucial for success

#ProductManagement #AgileMethodology #ProductDevelopment #Leadership #ProductStrategy

product management, agile methodology, product development, leadership, team development, double diamond, product discovery, product delivery, agile coaching, product strategy

= = = = = = = = = = = =

Watch on YouTube

Subscribe on YouTube

Apple

Spotify

= = = = = = = = = = = =

Toronto Is My Beat (Music Sample)

By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)

CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

I want to talk to you about this that I just put on the screen, the double diamond for the problem space and the solution space or the discovery space and the delivery space and I want to talk to you about this because. I think this is terrible and I don't think people should use it. I think this is going to be an interesting podcast because a lot of people have heard about this and a lot of people are either struggling to get to grips with how to use it or not using it. So, let's, let's do this. So, I want to be fair at the start of this podcast and I want to give a fair run through of this double diamond this What what else is it called? It's a model. It's a construct dual dual track dual track. Yeah. dual track development double diamond development Double diamond agile. I hate it even more. It's dual track agile, which is another phrase. I hate it even more now. let's start by talking about what it is. Conceptually. And then I guess. Metaphorically? Emotionally? Physically? Spiritually? It's been a long time since we've done that. Yeah, it has been a while. Yeah. Alright, so I put the double diamond, the simple double diamond, I put it back on the screen. So before we dive into this, do we want to talk about the history of it? Like, how did this come about? Or do we just start and then get to it? So we did do a bit of digging, I want to throw out the concept first. Okay. I want to talk about the concept. So the double diamond. Model, whatever it's called is named because, well, there are two diamonds on the screen, right? And a lot of people have taken the two diamonds, joined them together resting on their apex, right? And so join them together, and then they've said, here are the four Ds that make up the model, right? The four Ds. Yikes. I know. Discover, define, develop, deliver. And the first two D's, the discover and define, they said lie in the problem space. Trying to figure out what the problem is and defining it and agreeing on it. And in the last two, they said, okay, these are in the next diamond. So this is where we develop a solution and we deliver it. The other thing they've done is they've liberally sprinkled on this whole thing, almost like a pepper mill. This idea of how It's basically iterative. So you can go from any place to any place else. But when you look at the diamonds, the pictorial representation doesn't make that clear. It almost like, it just says you start somewhere. And there's offering like this one here that you have on the screen, right? It says start here on the very left side. And at the end it says deliver the right thing. So presumably one is now meant to go from left to right. Well, let's look at another diagram. So I've got several diagrams, one which we think are good interpretations. So we started with this one that's on the screen now. This is the very simple for, for I don't know how I'm going to do this for people listening. So for people listening, what I'll probably do is I'll probably link some of the links. I'll probably save the links we're looking at. I'll put them in the show notes. The first one that we're looking at it's called the double diamond at the top of the graph. On the left is a red problem diamond. On the right is a blue solution diamond. This is probably the easiest one we'll look at to understand. The second one we're going to look at is the sketch of a sort of a yellowish orange kind of color which has the discover, define, develop, deliver steps. And now I want to present another one, which is the I D E O design process slide, right? which has the problem space on the left. The solution space on the right. But the nice thing, I like this one a little bit better because at the bottom, it gives you like these wave forms of well, the further left you are, the higher the waves are the further at sea you are, the choppier and larger. You know, the waves are, and the further you get to the right, the lower and less dangerous, basically. The water's our calmer. Exactly, exactly, this is that diagram that looks like Snoopy lying on its back. So I, yeah, I mean, it's supposed to show that, but when you look at it, I don't know if I agree that the amplitude, the height of the waves, Represent the size of it. So in the divergent space is that is the tallest area on this image, right? Implying that it's harder to do this. Okay, or there's more pain However, you want to look at it, right? That's what it's saying. And it's also trying to embody this idea of the . The divergent and convergent model. Right. Well then why don't we look at the slide deck? Because the slide deck, this one is the cleanest view, in my opinion, of what it is. All right. So this comes from a slide deck that you brought in preparation of this podcast. This is also a much higher fidelity example than what we were looking at before because it puts on here the idea of research and coming to insight and then coming up with like specific problems that you want to solve as opposed to like solving every problem in the world and then going through prototyping and some testing and like basically the idea that you will go back and forth several times. Yes, the iterative concept. Yes. Yeah. I like this one more than the other two that we just looked at. I agree, I do as well. It actually shows the concept clearly. This one is the double diamond design model modified from the design council in the UK and the service design in Vancouver, university of Alberta. So this one basically walks the viewer through how you have a nebulous problem or problem set On the very left side and you go through gathering insight, doing research, first of all, to find out more about the issue or issues, gathering insights, identifying the needs and discerning the needs from the wants, wishes and desires. And then as you need to go back through that iteratively, right? And all the while you're doing that. Perhaps subconsciously, but you are actually developing empathy for the user. Because you're getting to know their needs better and better, right? More intimately. That's what this first diamond on the very left side, this kind of orange diamond, shows you. While you're doing that, in the first half of the diamond, when you're looking at the user's needs and doing your research, you're in what they call a divergent phase. And all that's meant to say is you're including everything. Basically, you're not ruling out anything and not making decisions yet. So reserve. Reserve decisions until the last what's the phrase last responsible moment? Yeah, something like that so the first half of the diamond says that until the most hilarious moment. Yeah, most hilarious until the budget runs out, right? the second half of the diamond is talking about now having discussions within Your teams and with the customer because you're still on the left side. You're on the discover side So I'm hoping that the customer is very much in the picture gathering insights and Narrowing down not the solution. We want to be very clear about this. This time it is not about solution Yeah, this time it is still about defining the problem. So narrowing down. What is the problem really right because before we said We'll just have divergent thinking, bring everything in and then narrow things down. So now you're into the convergent thinking. So then, then what they do is at the end of that first diamond, through this iterative process, you arrive at a more defined problem set. Yeah. Right, specific, maybe, hopefully it's one problem. You should do this so that you have Narrowed it down to a problem you can actually action, whether it's one or two or several, depends on the context. The lower number, the better, because you don't have noise at that point, you just have clarity, that's the idea. So moving to the second diamond, right, which is touching the first one, because they're both resting on their apex. It touches that. So at the intersection of the two, you have specific problems that have already been identified, or problem, hopefully through this iterative process. Now that you understand the problem, and everyone is in unison agreeing with it, you have consensus, what you're trying to do next is, you're trying to now look at solutions, but Similar thinking like you're not weighing in on a solution that someone suggests, you're going back to that whole convergent thinking. Look at each and every possibility. And the example that springs to mind here is when the problem says we have a river or body of water that we want to get across. We're not simply being told or anchored by a solution We're not told build a bridge because then the team's going to do exactly that, right? What we're told is the problem is you need to get across the river So now more questions could be asked. What do we need to get across? Is it people trucks, right? Whatever it is. And so there's no solutioning in that first diamond in the second diamond you do Ideation of possible solutions. Maybe we build a raft or a pontoon or something Or maybe we just have a hot air balloon that gets us across there so you learn more by by more exploration while the hot air balloon idea is still valid, but Maybe it's discounted because we're moving trucks across, right? So, through prototyping and doing this, you come down to, okay, well the problem is really just get us across the river, but us is really just a bunch of cars and people, so pontoons could work. We don't have to build a bridge or dig a tunnel. Not, not my business. In my business, I'm, I'm, I'm hooking a balloon to my truck and I'm having a balloon truck. Like, listen. There you go. Om, I need you to build me a pontoon balloon truck. There you go. And I need it by tomorrow. Yeah, By yesterday. And it should, and it should travel in an underground tunnel. That's right. Yeah, yeah, yeah. That's right. And for tree fiddy, that's exactly three 50 by Thursday. Under, under budget. Yeah. By Thursday. so this is a space where there's a lot of ideation in the convergent, sorry, divergent side of things, and we rule out things like balloons won't work because we have trucks to move over. Now we get into the convergent thinking and come up with possibly one, but often more than one solution. And you could prototype them to figure it out if that's valid. Try out each one and experiment perhaps. I feel like we should be on this slide because you keep going through the different types of thinking that are happening. Although this slide shows a very clean representation of the model, in reality, this slide here with the sharp looking diamonds, in reality, life is not like that. And the diamonds in real life do not actually touch each other. I like this one because this one's a lot closer. So, to me, again, I'm not in my gripes yet. We're just looking at what it is, what it's supposed to mean. We're just talking about concepts. First half of this podcast is going to be concepts. The second half of this podcast is going to be Brian and all his gripes in arguing agile as per normal. So I like this one though, because on the left, you're looking for the problems. It's tiny, right? And when divergent thinking starts, you start expanding out a million different ways that you could go. Then you get to that center, the messy, messy, gooey nougat center. Yeah. Right. The middle of the diamond where the diamond bows out and is the whitest takes up potentially the most time and it's the messiest. Like that's why I like it this way. It's not double diamond to me. It's one diamond to me. Yeah, well it is in this model. Yeah. It looks like one diamond. Right, right, right, right, right. And that messy middle it's, it's the emergent. Thinking right there. So you're not, you move it away from divergent and now you're trying to get out from this mess, right? This is where a lot of people, a lot of teams get stuck because you know, when you involve multiple people with different backgrounds, different expertise and so on you, you're in this grown zone. People are, some people will just be very adamant about the solution. I've been on teams where literally everybody on the team has a different idea of what the solution could be. Or which problem to attack if we're trying to decide, look, we only attack one problem because we need to deal with the pain point for the customer. We can only do one because we've only have enough time or money or deadline or whatever. So we have to pick one and everybody has a different take. I've been on those teams. so typically what happens in those environments is you have somebody like a lead or an architect who would anchor the conversation, say this is how we do it. And then other team members, no matter how valid their opinions are that they don't speak up often because, well The mighty architect has spoken, so if I say something, I'm probably going to be shut down anyway, so why bother? Everybody's ideas should be welcome in that grown zone, right? Let people talk. In fact, if you're one of those people who tends to speak a lot during these discussions, you need to maybe not speak so much and listen intently to others. Invite them into the conversation. And reduce the fear that they have for raising their hand and speaking up, right? And you can do that in many ways. I mean the other facilitation is paramount here. Reduce the cost of speaking up That's what that's really what we're talking about here, right? Reduce the cost and then yeah, there's no harm, right? Everyone's Everyone's feedback is welcome. That's that should be the the environment we foster here The blue and the yellow dots are really just representing ideas. And also, as we converge out from there, from the emergent to the next column there are three potential solutions that are circled here. So you may not end up with one. Maybe it's not as clean as that. Maybe there's more than one. And now the team has to decide. Well, one way you could do that is to pursue each one to a prototype. Just try it out and see how it looks. Your customer here too. They don't go away once they've been in that first half of the diamond, right? They are there throughout maybe they're not there As much in the emergent phase, although I don't see any harm in that because they can add invaluable input, but they're definitely there in the convergent side of it. As you're getting to the next column from emergent, we have multiple solutions. Ask the customer. We could do X. We could do Y. We could do Z. But you know, there's a cost for each of those. And am I actually homing in on the bullseye for the customer? And if they're in the room, they can tell you they could say, Hey, We have to have that bullseye, right? That's what we have to have. Or if you're on the outer ring of that, that's fine. That's good enough. And that's, that's great feedback for the team because you can now focus, right? And you can move out of this diamond with a potential solution that you're going to tackle. There's another view of kind of what we were looking at the whole time. Then the next diagram shows you know, a little more there's a little more a little more of a Hey, here's some things that happen in these again, I, I had to stop myself to say phases because that's the way when I'm looking at it, that's what it looks like not to jump as a head, but you know, Oh, the, in the conversion stage, you have some consolidation of thinking and some refinement of some ideas and kind of honing of the ideas kind of cutting them down a size or maybe pulling the value out of larger, segments of ideas. You know, Oh, this thing will take us three months. Well, out of that three months, I mean, what is the actual value in the three months? Well, the actual value is this one thing that would actually take us three weeks. Okay, well, we probably should push that up to the start first. that kind of refinement comes out of the conversion phase. I take that thread a little further, right? So yeah, okay. We should prioritize the thing that takes three weeks. But then from that, what might emerge is, Well, we don't quite know enough, right? So we go back to the beginning of the diamond. So, while you say this looks like phases, and I agree it does, it's a two dimensional diagram, right? But think about it like this. If you could pick this diagram up, and you can fold a piece of paper horizontally, Like a tube almost. Yeah. That's what you're looking at because you go back and forth all the time here to the point where sometimes it's not even obvious where you're at. Right. I think there's another diagram that shows that. So real life is not so cut and dry. It's not so obvious. If you go to the next one, it will show you how teams actually navigate through this and they may not even know they're doing this, right? there's a lot of sticky situations in that middle emergent category, that grown zone middle category. Yeah, absolutely. This is where some team members shut down because they're afraid to talk. Some people will just rule over everybody and steamroll because they are anchoring right? Controlling behaviors. So again, it comes back to the facilitation making sure that You recognize this and live through it. So here, I want to interject one other thing, right? When you show this to people, they go, we don't want to have these kinds of conflicts. Can we just eliminate the width of that grown zone? That's wrong thinking. You can't in real life eliminate this, because you're talking about humans. I think it's lazy thinking. That's what I would say. It's lazy. It is lazy. Like, arguing agile 198. Crucial conversations, you're saying? Absolutely. Rather than help everyone learn better ways of communicating, you're doing people a disservice there by not kind of pressing them and saying, listen, I've noticed this thing I'm trying to help you again, like listen to the crucial conversations podcast, and you will understand that. When you're not engaging in this category and you and you're you either try to control the conversation Or you're frustrated and you're trying to move things along. There are better ways to handle that. Some of the bad things that are listed in, in this, in the category, in the middle here you can get over that with better communication skills. And we are, we like to go back to better facilitation skills. If you happen to be the person that's facilitating these meetings and kind of moving things along. Yeah, that's absolutely well said. Absolutely. That's correct. So don't try to minimize this zone. Try to live through it Right, and if you do this with a team that is more or less intact over some time, they will recognize this themselves And they will welcome the opportunity to do this. Teams will get better at doing this. But you need somebody who is a facilitator. And you need to have team working agreements that work for your team, right? In order to do this well. That's a shame because I think the, somewhere along that border, borderline, so, sorry. As soon as I said borderline, I had it in my head. Gonna lose my mind. Somewhere between that emergent and convergent dotted line the learning happened. The breakthroughs happen. Yeah. Like it's a shame that the breakthroughs may not happen because your communication between team members may be unrefined. Right. Or not. You may not have the best facilitation. It. That's a shame. That is a real shame. I would like to wrap up all of our grids and stuff and move us I kind of wanna get to this one 'cause I think this is the best chart that we're gonna show today. And, and again, I will, I will link this one. the best chart that we'll show today, I don't know how I'm gonna do it, but I'll link this one in the show notes somehow. Because it shows all of these zones, the intro and the divergent emergent convergent, and it shows all phases of the diamond, and there's a bunch of squiggly lines that go between all the phases. Because that's how life actually works. Yeah, absolutely. This, this is real life. This is exactly how things happen. And this is what I was saying earlier. You won't even know which phase you're in or which facet, where you're at on this thing, right? Because people aren't overtly thinking about that am I in this emergent, am I diverging, right? You just go through it. You know, the nice thing about a diagram like this, although it's not this is not statistically relevant in any way, shape, or form, but if you just glance at it, if you just took all the lines that run through every sector and just stretch them all out and measure the length, the emergent, the middle of the graph, because again, because it covers, it covers the most surface area, it will have the longest line. Absolutely. So, that's also interesting to me is, the widest part of the diamond, the most chaotic part of the diamond, that's where. The things happen. That's where the magic is happening. That's where chaos lives. And all of these on these diagrams, there's an attempt to kind of simplify things, right? But all of these columns aren't necessarily equal width, right? So that's what you were saying. This is where the most chaos happens, right? But what we should be mindful of is Two things. One is, this chaos is essential. So don't look to minimize it or to avoid it. That's one. And then the other is, as you go through this, your team is actually getting stronger. They are actually feeling, every time you go through this chaotic phase, more and more people will feel empowered to speak up because someone else has, right? And so your team's getting better at it. So over time, this can only benefit you, your teams, and your organization. At this point in the podcast, I want to take a step back because, we walk through the dual track agile dual track development, whatever you want to call it. We talked about the history of it. We talked about a bunch of different diagrams. So now I want to get back to what I was saying at the very beginning of the podcast, which is thanks. I hate it. let me very quickly outline all my gripes. I'm gonna take one minute. Hang on. Let me, I have some professional opinions on this double diamond slash dual track. Agile. And I will take exactly 60 seconds to outline all of my objections of why I don't think this is a great model and I don't think people should use it. If you're gonna hook your cart to something, this is not the thing to hook it to. Okay. That's so 60 seconds. I'm an outline. All my gripes, throw them out on the table and then we'll spend the rest of the podcast kind of going over them one by one. All right, sounds good. All right, so I'm gonna start timer now. So I put the double diamond back up on the screen to bound my ranting and raving. Okay. So number one, this double diamond, like It is too easy to get this wrong. Like if I go into more complicated versions of this double diamond, especially the one where you say, Oh, here's the side where we're solving the right problem. And then the other side is we're solving the problem the right way. And you break those two things into halves, each one of them. It seems to imply that. Well, the left side is the smaller team because you don't need a big team to do, to find the right problems. I'm a smart VP. I'll tell you what to work on. So it, I could see this devolving. Waterfall style development. number two is one that we know come back to on the podcast many, many times, which is, it requires a. change to your individual team or all your teams or a change in your org design in order to actually be able to use something like this. And number three, it requires a push and continual support from the top of your organization because typical things org wide things that are pushed forward, like budgeting and strategy what customers are we going to sell to in what order, that kind of thing. That kind of stuff is usually pushed onto teams. It's not things that are discovered and are grassroots developed from the, from the ground up. So those are my three main categories. And I have sub, sub items under each one of these that we can explore, certainly in conversation, but let's go through number one, which is my, my pain point. Number one, where I don't like this, I don't like the double diamond. pain point number one, which I think is probably . My most salient point, my most well thought out point is it is too easy to get this diagram wrong. Again, when you show this wait, I'm going to go to a different version of this. I'm going to show this other one that I found online here. And I hate it. Because if you look at it, it, it's broken up and chunked up in a way where it implies that you can just put all this stuff on the Gantt chart. Like the problem space happens and then we go through the brief and we go through the potential topics and we have a research phase and then we present our findings at a stage gate review and then we move on to the insights. And the themes and the opportunity areas. And then we have a big handoff in the middle between the diamonds. And then we move into the development phase on the right. And the development team is all agile. And the team on the left is not agile in any way, shape or form. This is how most people when they view these double diamonds, this is the way that they will, in their mind, they'll just formulate The way of looking at it, as I just described it, and that is tragic. So I would rather not use this, this diagram to bound what we think of as like business agility. I just, this is not a good example. Yeah, I think that's a fair point. So there are a lot of different variants of this model out there. And every variant I've looked at leaves It's one fundamental thing out, which is the model is depicted in two dimensional space, right? It's not meant to be like that I think the closest one that I've seen is the spaghetti model as I call it the one that we shared earlier Where it looks like is basically Brownian motion starts going everywhere. Yeah, it's not meant to be a linear progression through the model and this blue image that you're showing Suggest that. It suggests that you have a brief, you have a cluster of topics, you do your research. So, these are essentially waterfall, and there is no indication on this image of it being an iterative model, right? No. And that's what's missing. So, you have to be careful where you consume your information from. But, if you take the simplest thing you can find on this, which is that very first one we showed. Take, tear out that piece of paper and roll it up as a tube. That's what it is. You're going in 3d space. It's not a 2d space, right? You can move from one. Area to the other without even knowing it. Here is clear boundaries like this model. That's the one that I use with my teams to show them That life is not linear. Like it says here you're moving all over the place And there's no recipe to follow with this model. It's not like well, how do we implement this? You don't install this There is no way you can say go through steps one to five They don't give you that, so it's a conceptual model, but the implementation is largely depending on your context, right? You have to implement it based on the maturity of your team, what you have as skill sets, the knowledge level of people, etc. what we're looking at now is like this spaghetti model. It looks like random spaghetti has been thrown at a wall, right? Yeah. The turns and curves here indicate you've either come to a learning because the team investigated something and found out something, right? Or you've interacted with a customer and changed directions based on your interaction with the customer. So like, you either learn something new. From your your deep dive or you learn something new from the customer so like you learn something new you change direction and the Again, my problem with the diamond look with the traditional. I put the blue diagram back up on the screen right now. The going back is kind of implied in the like between the final brief and the selected ideas and the selected ideas and the final solution that like that build test iterate you see there under the deliver phase that implies like, well, the development team is doing the agile development. And then everybody else is waterfall, but you know, the funny thing about that is it like, that is a, that's very close to reality in a lot of organizations well, the development, the it folks, they're trying to do this agile thing they're trying to do this scrum thing, this agile thing, and everybody else is like traditional budgeting. You know, they want to know when it's going to be done. They require a Gantt chart. They require a timeline. They require a bunch of more traditional style project management type of deliverables. And on the right, on the far right, the closer we get to the customer and the solution being delivered, the more that we're on this Plan Do Study Act type of loop this PDSA Deming loop. Yeah, on this particular model there's no notion of iteration in that first diamond whatsoever. No. Which is very disappointing because that's not how it should be. Again, the core of my problem with this double dot. Even this simple one, let me put it back on the screen. If we go back to the simple one, this one looks like, oh, well, I have a team that works in the problem space and a team that works in the solution space. I want to call attention to this Jeff Patton article that I will link in the show notes about dual track development where Jeff Patton points out that, it's dual track meaning D U A L dual, not dual track. Yeah. Like fighting and jousting. Like fighting, fighting with, with pistols at dawn, like not the dual track. Right. Yeah. And he goes back to Desiree Sy's article who first coined the term dual track. Yeah. Dual track agile, right? Where she was talking about design and how the elements of product design can fit into agile. Cause, normally design would be you'd be given like a month or two. To go out and spec out all the, all the screen wireframes and all that. And he handed it all over to the development team, but in agile, everyone's kind of doing everything together. So how can design fit into the coding phase? You know, like phases. Yeah. Right. Yeah. Yeah. This is 2007 is when this article, again, I'll link this in the show notes so people can go read it, but this is where the double diamond came from. Jeff Patton read this letter, or I'm sorry, he read this blog. I don't know what it was. I guess a paper. Did we have a white paper? We have paper. I think it was a white paper. I think we did Well, we definitely had blogs in 2000 something. Yeah, maybe that's where he read, I think it was a white paper. And he says he was teaching class with Marty CAgan. And he basically made an attempt to retrace Desiree Sy's framework of how design is implemented into the development cycle. And he basically came up with a double diamond. So that's fine. I'm not taking anything away from Jeff Patton. But again, it's easy to draw out a diamond Like this one on the screen. But when you get into the more complicated, multi phasic sort of diamond, you aren't you don't have a bunch of lines that go back a little bit and whatever you're starting to lose the purpose. I just don't think this has a Fidel. I think you're, you're leading people down the wrong path. And it's too easy to get wrong. When I look at something like this it says, well, it looks like I can do all the discovery up front and then I can do all the definition and get all the requirements next and I can do all the development next and I can do all the delivery and my customers will be 100 percent happy after it's all over. And you know what that sounds like to me? Fragile. It sounds like waterfall development. yeah. Nobody even remembers what waterfall development is, but that's what it sounds like. Yeah, so this has the notion of getting all the requirements up front, etc. And this is actually doing the community as a whole a little bit of a disservice because if you come across this on the internet, and think this is what's encapsulated under that double diamond model, you'd be leading down the wrong path. So we've seen several of these as we were just about to start the podcast. We looked at a few images. Frankly, none of them actually Encapsulate the fact that this is continuous ongoing and not linear The other thing about these diagrams like what gets lost in the translation is this is one team Like the designer the developers the product manager everybody. This is one team With multiple skill sets, but when you blend them all together, they have one skill set together as a blended group. it's so easy to get wrong. when you show this double diamond two executives, unless you can give them a path. They're not going to understand that like, Oh, well the team has to figure out the best way to do this. the team might go from phase A to C to D to B to back and forth, right? They might go like, it's nonlinear. You don't follow from path A to B to C to D. That's not the way it works. You can go from any step to any other step. Very true. And you said at the beginning, right, why some of these things are prone to failure. They're hard to implement. It's not just because there's no clarity around the model itself, because there are so many variants, but also The model does not include steps. So it doesn't say do these things in this sequence, right? It doesn't say that teams have got to figure that out for themselves you could be spending an untold amount of time somewhere in there But in the meantime Your management saying, where are you with this? When's it going to be done? So there's that overt pressure, right? To, get out of that messy middle and shortcut the conversations. All that leads to, yes, you'll have something, but the quality won't be there. And you may miss the mark all together with satisfying the customer's need. Well the one last thing that I want to do, and we'll get onto the next category, but the one last thing I want to. Say about this is the drive to start down the road of, we should be doing this type of development rather than our current phase gates sort of waterfall type of all the requirements and all the design and all the tests or whatever you do. Is there's no immediate clear ROI in why should I move to this double diamond type of thing like the, the immediate clear like, okay, well I'm going to move to all the problem set definition up front and then all of the honing down and the selecting problem set up front and then all of the development on the problem I've chosen and then all the delivery of the problem I've chosen in that order. And then onto the next problem that's behind it because remember, We chose all the problems up front so we now have a ranked list of problems So we can just run down the list of problems and develop with more and more teams and we'll be delivering the highest value things Right like the illusion of progress there's no like even that that sounds pretty structured when I say it out loud but even that you know, like when you start delivering the first problem set as solutions We will discover other things. So there'll be feedback and then the customer's upset. So you're going to jump on something else. The clear immediate, like most of the finance people that run most organizations, I'm making broad sweeping statements on the podcast today are looking for what is the ROI on us changing our business model to start servicing these things over these things or whatever. And it's just not clear. In this setup, you need more details is what I'm saying. You need more product management. You need more details. I think we've beat this one category up enough. I'd like to move on to the next one, which is... In order to present this properly it requires a culture change. It requires a culture change and, or. In organizational design change. Okay. I have to have a truly cross functional team with all the right people on the team to handle this line of business, like this product, this group of customers, whatever you want to call it. Doesn't really matter how you slice it. I'm going to say product, but product is just an umbrella term for a group of customers using a certain set of features, whatever it is. Most. Organizations you will start bending and potentially breaking your organization when you're like, I need a, like the hiring manager for engineering should hire the people for engineering. And then they sit on my team. So they, technically they work for me as my partners, but they report to the engineering manager and then the product manager. The product leadership, because that's what we call people that hire product managers now, we call them product leadership, weird they hire the product manager who sits on my team, and then maybe you have testers, maybe you have other people, right? Like, all this cross functional skill is on my team, they're all hired by other people, but they're all loaned slash staffed to my team. I hope they don't have departmental goals that kind of take them off of my team and distract them, right? Even just that getting a cross section of all these different skill sets on your team even that might be a fight in your organization and then getting your organization to commit to Hey, we need advanced facilitation skills. We need to advance these people's communication skills. We need to, like the 198 Crucial Conversations, we need to go deep on the ability for these folks to mesh with each other I wanna go back to your excellent PowerPoint slide in the emergence zone here. So, in here, the emergent. Column in here, the broadest surface of the diamond where you have the emergent conversations happening. I want my team to excel in the emergent category. And which is where I would say probably most teams suffer the most is when they get in the emergent category again we're talking about my gripe here, in case people got lost. My gripe here is it requires a cultural change or an organizational design change. Most teams will push back against having that person with excellent facilitation skills to bring people through that emergent phase and make something out of it. Where we're converging on the best ideas. You want to stump a product manager tell me what your system for prioritizing one idea over another idea is. You have a dozen ideas. You can only test one at a time. Tell me which idea you're going to start with. That's the act of moving from emergent to convergent. Yeah. Yeah, most organizations are weak at this, first of all, right? that, in my experience anyway. I will tell you for our listeners, that is a huge advantage. Most people are weak at this so you can pull ahead of the pack. That's exactly right try this and listen, there's no Fail or pass at this try it and you'll stumble like everybody does Pick yourself up and move on but make it work for you. that's the goal here. On this diagram where it says in bold at the bottom, life is not linear. Just remember that. So when someone says, well, we've been in these discussions, can we move on? We'll move on for the right reason. Not because the model says you should move on. Right. You got other reasons why you don't like it too, right? I do have another reason, but I want to stay here for one more second to say I wouldn't have such a hang up with this if it weren't for the issue with when it comes to org design, it's just like organizations are just not open to saying like, Oh, well, all the engineers are over here in this silo and all the designers are over here in this silo and All the testers are over here in the silo, like organizations just, they tend to gravitate to that for some strange reason. And I really don't know why. I think the reason, at least as I understand it, is historical. We came from that whole environment of command and control. This is how the teams were built to report to somebody. Yeah. Today, we're at a point where Not only is the organizational structure not amenable to using this kind of a model, right? There are other things like for example, how are people rewarded that's never going to fit in this model If you're going to reward people on fast delivery only As opposed to effectiveness and quality and making customers happy. Yeah, I mean, leadership's gonna, or at this stage, there'll be management. They'd be focusing on the wrong things, right? And rewarding you for being the fastest person. Because leadership will say, well, shouldn't you just move on? Because you're agile, fast fail, so move on. It's like, well, you missed the goal here. Right? Yeah. And customer centricity is the other thing. Like oftentimes, regardless of the model, this is another example of yet another model where the customer is nowhere to be seen past the very left side where you've met them, got their requirements and then moved on. Right. That's wrong. This model doesn't say that you should do. You should not do that. Obviously, you should have the customer in all the while with you. And if that's what I was saying, if you take this two dimensional piece of paper, roll it up the customers there with you, right? So in that messy middle, if they're listening in, there's no harm. They can actually add clarifying statements to your discussions, right? If you didn't have them, you're now going based off of assumptions. Well, I want to move on to my last category so we can wrap up this podcast slowly. This double diamond it requires a a continual pushing from the top Which includes budget and strategy. Okay, and I think about two things financing your portfolio, which is all the projects or products or whatever you have your company and going in front of the the big snake pit of finance and the VPs or leadership or whatever you have the sea level whatever Asking for more money like once a year and you may you know You make it through that your once a year thing, you know You don't have to do anything for 364 more days of the year. It sounds ridiculous. Like a better way to do it would be like micro budgeting, breaking it down to a smaller segment. Same thing for strategy. This is just my personal. Experience the best companies I've ever been at do strategy in terms of what big bets are we making and then what is the progress toward those bets. We answer those two questions and we're talking with leadership every week. I mean, probably every other week, right? but definitely more than , once a quarter once a quarter is like, you're not even in the backseat. Once a quarter, you're like in another car and you're just rolling up on the highway and like looking in the other car to see what's happening once every other week is you're at least in the backseat and you say like, Hey, have we, are you sure that we maybe we gotta stop and go to the bathroom and get some Mountain Dew or something Like that. That's like once every other week. Once a week is you're in the passenger seat. And you can really check in on strategy and the experience that are happening like once a week. So there's different levels and also the different level of org maturity can also determine how often you should meet. But if we go back to the podcast that we did, the 201 that we did on the power influence matrix. these, high power, low interest stakeholders. That's what we're talking about now. It's like, if they're high power, they're a low interest, which means they're not going to check in with you all the time. They might occasionally come to your sprint review. They'll definitely be in the quarterly sync with you. But if you are not paying attention to their needs. They're really going to rake you over the coals in the quarterly to be like, what are you doing in the roadmap? None of this reflects what my customers are telling me. How did you even get to here? And if you have those difficult conversations, you will know that like, you've got a big problem in strategy, and that's going to roll back up to whatever portfolio planning you have at your company But in companies I've been at that are multiple products and they're trying to sell those multiple products across all of their customers, that's what I think of as a portfolio. Those people, like all your product managers for all the products, need to be together. In those strategy meetings to talk about how are we going to cross sell? How are we going to make the cross product value a big thing? This, like it needs a continual push from the top. And again, like this double diamond is, it seems like. We do all the requirements up front and we do all the validation up front. And then in the middle where the two diamonds meet, we do a big handoff where the discovery team's done and the delivery team takes hold of it. And then they have to do nothing else. But then what the other team did in the diamond, it's deceptive to me that the two diamonds are one team. In one process and the stuff in the second diamond might wheel back to the stuff in the first diamond like over and over and over again to get to where we're delivering something of value. Yeah, I think that's a good way to look at it that it's really just one diamond for the sake of clarity. Sure. They draw two diamonds. I'm okay with that too, right? Listen, none of this stuff is understood very well, right? That's part of the problem. So when leadership, when you talk about making micro budgets, for example, or, or not having this annual one budget. We don't really know what we want, but we'll tell you whatever you've got is not it when you have it. Yeah. That's a huge shift for most companies. They can't make that shift quickly, so what can you actually do in practice? Oh, I mean, I will give you something that's been successful for me. You set up a strategy check in. You can call it whatever you want. Call it a status meeting if that's your culture. Sure. These are the bets that we're currently engaged in. These are the evidence I have. First of all, if you're a product manager on the development team, you should definitely bring your team with you, because if you're going to get raked out of the coals, it shouldn't just be you by yourself. It should be you and your whole team. You're all contributing together, okay? You should go in front of whoever this strategy board is. Your strategy board definitely should be Whoever you report to, whether it's a VP, C level executive, I don't know the size of your organization, some rep from finance, Because the finance numbers should be tied directly to the strategy execution. They should be inseparable. We're putting a certain amount of dollars behind these bets, right? maybe the finance person knows what dollars we're putting behind in the cycle, but only the product manager knows what bets we're engaged in. So you can break the money down. Yeah, on the best that you're engaged in and the executives will be there to just double check the product sense of the product manager , and to look at the statistics within with a kind of like a neutral. Viewpoint to say like, these are the stats that you're presenting me and I don't think they look right. Maybe you want to look at this X, Y, Z, or whatever. Maybe they give you some of the details, but again, we're assuming a lot in this conversation. We're assuming that, you're in a generative style organization, not a pathological style organization. We're not, blame games are not the order of the day here. We're all trying to advance. The customers value, We're all trying to do the best that we can with the tools that we have. so that, I completely agree. Anybody that might be listening to this has said like, well, Brian, that doesn't work in my organization because everyone's trying to stab each other in the back. Yeah, right. Yeah. I'm with you. Good luck. Keep that resume updated. Yes. Good luck. But also like you have to find a way to get management. Invested in the, these are the bets we're trying to make. This is the evidence that we've seen from the bets. And this is the next thing we're trying. And just, and get their opinion, right? Because again, high power, low interest. Arguing Agile 201. Get them involved. And if you really are trying to get them involved, trying to include their opinions, I mean, they'll be trying to help you with everything that they can contribute. Otherwise, like they're, the typical, like Gary from sales they're just trying to be like, I'm just trying to get paid for my bonus or whatever yeah, but there's a way you can engage these people to say like, listen, We need to try these things against the market with like new features or whatever, that's one thing, but also like trying different ways to sell products against the market. We don't talk about that enough of like, maybe customers want to buy things in this kind of package. Let's test that, go out to your contacts, let me know what they say. You know, there's a lot, there's a lot in this category, but again, like this is why I don't like this double diamond thing. Like, I just don't like it. it's not detailed enough. it's too simplistic. It makes it seem like, well, we can just do this in the development team. We can just do this double diamond thing in the development team. And we're like, we don't need a bunch of support. No, like actually, no, you need a. You need a ton of support from your leadership to make this thing happen properly Otherwise when these two diamonds connect in the middle And you think that's a handoff and that's that becomes okay in your organization You've already failed with this the whole purpose of this exercise. Yeah that this model has weaknesses, right? So we pointed out a few of those but I do want to say if you're in a culture where If this is completely new to you and you're not sure how to implement this, then do one thing. Try something small, right? So we talked about budgets, let's say, for example, you're not going to change the way your organization does budgeting. If you're a product manager and you're basically, handling a product or a line of products, try changing the outlook from budgeting a project to budgeting for your product. Funding features, for example, right? Then your mindset will be different because it's no longer, well, we have this budget. It's a big number typically because it's an annual one. And all you're doing is basically you're withering away at it with a run rate of the team. That's not the idea. The idea is. From that, you have these features you're trying to deliver by a certain time for a certain audience, right? How much money will go towards building each feature? Is there enough of an ROI for that? Or sometimes there's not an ROI on a given feature, but you're doing it because you're basically the leader in your competitive space with that feature and you want to expose that to your customers. So they don't jump ship or whatever the reasons might be. But think about it from that perspective in Everyday life like when you speak with people think about it that way even though your budgets are already preordained whatever else And as you're doing that people will learn the way you're thinking the way you're talking right and and that I said It's a slow thing. It's not gonna happen overnight But you the change will start with you right if you want to start We explored the diamond, we explored a lot of my reservations with using this style to communicate. I feel the basic product discovery type of stuff. Like I would start with that. I would kind of ignore this. I feel the, the point you should take away from this is. You should involve the whole team in both discovery and delivery. A better version of this would be one diamond that shows the middle of the diamond where the most chaotic stuff is happening. And that's, that should be normal. Okay? But like, I just don't like these two diamonds together. I, I I went through this whole podcast. I was hoping to have a revelation. I was hoping to find on the whole wide internet. A better version? These two diagrams put together and and you haven't, we just didn't, yeah, we didn't. I really like your, the diagram that you came up with, with the, with all the very chaotic middle. That was probably the best diagram I've seen. Somebody came up with it, I just leveraged it, but yeah, it's a single diamond. Well, I think there was an attribution on the slide, so we'll figure that out and, and posted the show notes, but Sure. Single diamond, which is very chaotic in the middle. I think that was the best interpretation of what's going on here. So first of all, I just want to go back briefly to the statement You just made here which is involve the whole team Absolutely, right This is not a part of a team or some other team like there's a team and you gotta involve them all and I will tell you just frankly like that is my biggest problem with this diagram. This diagram seems To imply you can separate between different teams or individuals or like maybe the entire development team is on the right and it's a much broader audience and on the left you just have the product manager and the designer and the middle what joins the two diagrams is the tech lead and that's you just write a document and throw it over the fence that doesn't work that it fails. It's terrible. Don't do it. Done. Yeah, I agree with all of that. It is a, it's a big failure, right? Of this model to not kind of Effectively illustrate that it's, it should be the whole team. The other thing it doesn't effectively illustrate for me is you should involve the customer throughout. I don't care if it's the messy middle, right? It's only a messy middle because you're not getting the feedback from that customer. You're right. So it doesn't show that. that's another reason I don't like the customer is not shown anywhere on here. I mean, you can infer like, Oh, well we're defining the problem. So we must be talking to customer, but it's not, Again, if I'm showing leadership, this double diamond, if I'm training them or whatever, the customer is implied on here. Yeah. And I just, I don't like it. Agreed. Agreed with both of those things. Okay. Well, hopefully you've got something out of the, the double diamond and that should be a single diamond perhaps? Dual track. Dual track. Dual track. With swords. Right. Yeah. D U E L. No. Let us know in the comments below and don't forget to like and subscribe.