Why, what, and how of Agile
Definitely, Maybe AgileOctober 26, 2021x
35
00:21:4915.01 MB

Why, what, and how of Agile

Developing an agile process is not only about following a set of steps to the letter but how you're going to take that idea and apply it in your environment. Dave and Peter explain the importance of the Why, What, and How of Agile. This week takeaways: Recognize that there are two paradigms Mindset shift The same solution can have different consequences We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, co...

Developing an agile process is not only about following a set of steps to the letter but how you're going to take that idea and apply it in your environment. Dave and Peter explain the importance of the Why, What, and How of Agile.

This week takeaways:

  •  Recognize that there are two paradigms
  •  Mindset shift
  •  The same solution can have different consequences

 
We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com 

New episodes released every Thursday to challenge your thinking and inspire action.

Listen and subscribe:

Peter

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your hosts, David Sherrock and Peter Madison. So how are you today, David?

Dave

Peter, I'm doing great. Looking forward to a weekend, a bit of a break from the from everything we've been up to. Now, we were just kind of prepping things a little bit and we'd settled on the topic of the why, what, and how of Agile. Let's start that one off. Why, what, and how? What's how do they connect?

Peter

Well, I was uh came across this uh in a conversation on a on a Slack channel on the part of the other day about this idea of uh when we as uh consultants come in or as when you turn up to a conference very often, you watch all of these sessions, and it's all talking about the the why you need to do agile or DevOps or any of these other practices and the what you get when you when you do it and what it'll look like and all the wonders of that. So we've got the why and the what. And that's really the bread of the sandwich, but we we don't talk a lot about the how, like how will you take and apply this to your environment and how will you do this? And this how piece, I think maybe where we start to trip up when we talk about the why, what, and the how. And uh and you had some interesting points you were raising right before this.

Dave

So well, what I was gonna say is is, and I think this is where we we may have a slightly different perception or perspective on this one. In uh Simon Sinek, the golden rule about you know, you start with why and things like this. We're all familiar with that. We know that we need to understand why we're doing things in order to make changes. And to your point, there's a lot of discussion around the how practices. If we go to a conference or any sort of community event, you can learn how a definition of done works or how a scrum daily stand-up, some sort of daily scrum might work, or any you know, all of these different practices. But when we go into the field, if you go into an organization, what you in many times experience is that the how has been somehow morphed into something which doesn't serve the purpose that we understand it to have served. And so those practices get diluted as they're applied in lots of different organizations. And I think there's a really good reason for that, but I'm not sure that focusing on the how is going to actually solve that particular problem.

Peter

And I wonder if it's about focusing on the how as much as understanding that the lettuce has gone off, that uh understanding that we're coming back to look and check that uh our how is actually still serving us, that it's actually um the the how that we want, the how that's actually useful and valuable to us, that we're it's this because when we we go, we often see a lot of these presentations, we see them in the context of the person who did them. So it's their how, it's their how they did it, how it worked for them, and often if that gets taken verbatim and moved into some other context, it doesn't provide exactly the same results. And this piece that I I find often gets missed is this willingness to go and look, even if it did originally serve you, maybe it worked great. I mean, I've seen that happen often enough. You implement a set of practices, it's fantastic for a week or two, and or for a month or two, and then and then after that, uh it's uh not so good. Something's uh smells a little fishy here.

Dave

But I think uh what you're touching on there is the the kind of um the bit that's missing, if you like, coming back to the why and the what, and specifically the why, is one of the realities or the ex the the the things we may want to kind of get our head around and accept around agility and whatever that family of stuff is around lean, agile, DevOps, and all of those pieces, is that it's a paradigm shift in how to manage organizations. And it's certainly grown out of a paradigm shift in how to manage IT development or digital delivery, but it's a lot more than that. And when I look at, for example, so many implementations, it's an extension of tailorism of the old management paradigm, in the sense that you know there's been a hundred years starting with time and motion studies, uh literally at the beginning of the last century, in terms of looking at how work is done and the process of work getting done. But the mindset there is it's a mechan mechanistic approach. It's something that you can sit with a stopwatch and observe and change, and you can optimize and continually get better and better at that process. But when we look at the the agility side, the paradigm shift is it isn't that sort of mechanistic process. People are much more substantially involved in the success of delivery in the world that we're that we're working in today. So then that approach to a more biological or organic way of thinking about process is it has to be recognized before we move to the house.

Peter

And this is where I think there's that piece where we see this. We see that somebody somebody got there. They they they they set their why, they they aligned, they they got to all of the wonderful benefits that they managed to get out of the transformation and the piece they implemented, and they did this through a set of practices that they adopted and they brought in. And then they you you take that and then they mechanicalistically apply it to their own environment, and they end up with stand-ups and they end up with tickets, and they end up with where they end up with stories, but those stories don't really reflect stories. They're not uh they're not really what they're intended to be. They often end up being these tiny little uh slices of which are essentially technical tasks that need to be executed in sequence in order to achieve the outcome that you're looking for. Uh well, maybe not even the outcome, usually just the output that you're getting. It's uh not even the outcome. Uh, because that means that we would have at least focused on having some idea of what we're looking to achieve and allowed some freedom as to how we might get there.

Dave

I know I think the example of user stories is a really good one in the sense that from an from our mindset, we we look at user stories as it's often described a placeholder for a conversation. It's the beginning of a discussion. It's inherently ambiguous, and there is room for think of it as the evolution of that story as you have a discussion and you understand what the real intent is and what you may want to change and so on. So there's uh there's a lot of sort of um lack of detail or lack of clarity about it because that is intended to come out of a conversation. In a mechanistic mindset, that user story is treated as a specification, as a detailed uh description of the task that needs doing, uh the widget that needs building, whatever it is. But that's that old paradigm where we're leaving on the table a couple of things. We're leaving on the table the creativity, the innovation innovation that comes in by by the human interactions, that individuals and interactions over well-defined, articulated, detailed uh descriptions of what the activity is. Um so how is it we're able to interpret it's it's very often that you're going to see those user stories in a mechanistic mindset become detailed, become task-oriented, and so on. And yet you can see exactly the same how in an organization that understands that the paradigm has changed, which have ambiguity at their base, which are a starting point for a conversation, not an ending point for a description or a specification. And yet it's the same how in both cases. The paradigm is what's different.

Peter

So there's an interpretation element here, right? There's the I saw this thing, it worked there, it got an outcome that I'm interested in achieving where I am. I want to take that, I'm gonna apply it, and my but my how doesn't end up resulting in the same result that I expected to. And and you see this even in within the same organization when it gets applied. I can think of an organization that had 14 different teams, and of those, I would say two of them really got it, and they they managed to really truly start to develop some excellent uh agile practices and uh really started working well together as teams. Uh, and the other 12 were in varying different degrees uh too, and uh not that we want to compare them, but it but they were definitely different interpretations of the how and what this meant and how they were doing this. And it uh it was interesting to see the those differentiations and how that it was impacted. And then I I think if we went back as well, you might even look at it that some of the consequences of that was the work and the number of dependencies that the different teams had, and because there were some slight differences in what the teams were working on. But that's possibly a conversation for another day.

Dave

But I I actually think what you're just you know, that is what you're going to expect is you have a paradigm shift, you've got the two paradigms overlapping for a period of time. And so if you have 14 teams, you may only have two or three or four or six, which are really beginning to benefit from that shift in paradigm, whereas the others will be using processes over and above what allows you to um, you know, extending that mechanistic mindset. So they're still using the same artifacts and the same practices and the same how that we see on the agile teams that have adapted or made that or are on the journey of making a paradigm shift, but they're still using it in the old paradigm. It's a little bit like I'm sure that when Henry Ford introduced the assembly line, it's not that all cars suddenly were assembled on an assembly line or all manufacturing had flipped over. There would have been um specialist shops continuing to use craftsmen to build products for many years, even as the assembly line paradigm got introduced, they're running in parallel for for many years, and you can still today buy products that are crafted that have craftsmen and that aren't assembled on an assembly line. It's not that you know it's all of one or all of the other, they're going to live um alongside one another.

Peter

Yeah, I mean Etsy, I believe, is a place you can go buy a lot of those.

Dave

So exactly. Yeah, so there's loads of there's loads of examples, and there's there's value in it. It's just that um when we're looking at it right now, the the um that paradigm shift gives something to companies as they're making that shift that they don't have when they use the mechanistic mindset. So, what would that be? What is the advantage of of shifting paradigms and not just adapting or extending agile practices in the current paradigm that your organization might be in?

Peter

Well, this is where the truly being able to bring in those practices and get the benefits from them. So the this, I think, and think this is where some of that interpretation piece comes, is that you start with your why and your understanding and defining that. And I think this is so I think organizations often um come and they they may not necessarily spend the time that it really takes to truly understand what their why is going to be and and how they're going to start aligning the teams and spending that time and really truly understanding what we're going to create that alignment against. But even if they do, then understanding the and having an understanding of what the outcome they want to achieve from all of this is. Why are we doing this at all? Like what is the what is the purpose of all of this? What is the outcome? How will we know when we get there? What will that look like? And then when we come to the how, we we take these mechanistic practices, we apply them into place, and we do exactly the set of rituals. We do our stand-ups, we uh do our sprint planning, we do our retrospectives, we if it's following Scrum. I mean, pick any practice. This isn't just Scrum. I would seem to be picking on Scrum a little, but it's not just Scrum. Um, and it's any kind of framework where you bring the framework in and you follow it verbatim without considering is this serving us in context of all of the other things that we're looking to achieve? Is this moving us towards those outcomes? If we continue down this path, are we stopping to take a look at those practices and seeing uh if this how is actually helping us? If uh because that's the piece I think for me is critical there, that uh taking the time to look back at whether the practice itself is still serving you.

Dave

Right. I I'm pausing a little bit because I I think uh what you're describing is a very internally focused, kind of laser focused on the internal how, you know, what is it that we're trying to achieve? Why are we doing this as an organization? And in order for there really to be a paradigm shift, I think the the pressures have to be much, much broader than a single founder or leader within an organization saying this is what the change would like to be, we'd like the change to be. So in many situations when we're looking at organizations, what it interests me is that if if you think about it right now, that we're in a position with uh COVID, with uh with uh the shift to digital products and strategy being, you know, technical strategy being a huge part of any business strategy because technology is pervasive in most of our lives. Where the the work environment uh is uh has to change to be responsive in that in that space. Now that covers everything from digital product development and how rapidly in iterative delivery against that, how learning what customers are needing, not uh predicting what customers are needing and building it and saying, you know, that whole paradigm of build it and they shall come, well, that doesn't work anymore. The consumers need to be engaged in that conversation in terms of what the product might be. That's one aspect. But if you look even at the people in terms of working, and now this whole conversation that we're having through this quarter about the great resignation, well, that's coming about because the same kind of changing uh understanding of what a good workplace looks like is beginning to pervade the workforce. All of a sudden, the workforce have a lot more power because honestly, they don't have to go into an office. And it's not clear that in two years or three years' time everybody will be back in an office. We're beginning to learn that there's a lot more fluidity and a lot more opportunities to work fewer days, to work from wherever it is that we want to be. So all of these shifts are adding up to mean that your paradigm of how you work is less about treating people as a fungible asset, treating consumers as people who, when we tell them this is a brilliant product, they will buy it and enjoy it into one where there's much more of a conversation. It's a discussion with our employees, with our partners, with our stakeholders. It's also a discussion with our customers and and and aspects like that. And I think that's the paradigm shift where a mechanistic approach is fragile in that it's too much all or nothing, and a more biological organic approach, an agile approach, agility, not agile being scrum or agile being anything else, but an uh kind of that agility mindset is different, it allows much more interaction and engagement.

Peter

And I I talk about this in terms of the the complexity of the environment and the world that we live in, and the the exactly as you're describing, these interconnections between people, both as employees and as citizens and as um just people in the world in general, and all of those interconnections now become much more of the fabric of our lives, uh, thanks to uh uh technology is one huge part of it through uh well social media and through communication channels and prevalence of information and how all of these different pieces impact how we interact with each other. And it's pervasive. And so this idea that um everybody would get up from from nine to five and they would come into an office and they would type away and then they would go home again, it just isn't as appealing. And we've uh there's lots of other reasons behind that, and there's plenty of uh reading that people can go out and do around that. I mean, one of the the big pieces that I see is that uh um COVID sent everybody home and broke a lot of the tribal bonds. A lot of people were were doing these work, this work because they enjoyed going into an office and to be with the people that they uh saw at work every day because they enjoyed working with those people, and that in being sent home, they realized that those ties weren't as strong and that in fact the work they were doing wasn't enjoyable enough. So, hey, I'm gonna go do something else somewhere else. And that's uh this ability to move away. But uh even even that, and that's just one of the many things that's uh in happening in that, there's many different influences of that. But when we look at all of this this complexity that's going on in the world around us and the changing workforce and uh and how we interact with each other as human beings and what organizations are and and how they deliver services into this more complex environment, uh imagining a mechanistic system that will just churn things out in the same way every time, um it's hard to imagine that that is going to successfully deliver into that kind of complex environment.

Dave

Well, I I think it brings us back to that whole why, what, and how of agile, where the how is perhaps the most uh misunderstood, but not misunderstood in terms of how does a particular practice work, but misunderstood because if you take that pool of practices and you apply it with a mechanistic mindset, with an expectation that this is an extension of management theory that started with Taylorism, that went through what's gone on in the last century right up until this point, if we extend the practice that mindset and apply the practices, we're not going to get what uh the new paradigm is offering, which is that uh that uh engagement and uh continual iterative cooperation and uh and impact with uh end users or employers, uh employees, sorry, partners, and the creativity and the innovation which is going to allow organizations to succeed in an environment which is increasingly complex, which is increasingly volatile in what the current trends are or what the desires uh needs of the marketplace are, um, they're not going to have those if they're applying if they still see it as an extension of classic management theory, right I'm speaking classic being the last hundred years or so of management theory, as Gary Hamill would describe it.

Peter

Yeah, and we're when we're still evolving and we've got a long way to go. And I like to use the word ecosystem to describe this interaction between the different parties that are involved in and all of this. So so as we as we come up to our uh our time here, how would you like to sum this up in three points?

Dave

So there's the the the what, why, how pieces. So if we start with the why, recognizing that there are two different paradigms, that there are two non, it's not a contiguous change, it's a a step function, there's a there's a a break between the old paradigm and the new paradigm. And I don't think we talk enough about the fact that it's not an extension of last year's thinking, but it's the beginning of a new way of thinking. And so that in itself is a is a shift in mindset. As a result of that, that leads you to uh the how and how it's applied, whether it's applied using the old mindset or the new mindset, the same practices, the same hows will have very different effects, consequences in those the way they're applied. Uh and that obviously leads then to the what you get as a result. So if you if you apply the how of the new paradigm using the thinking of the old paradigm, you're not going to get the what that is promised when you look at agility. If you apply the new how in the new paradigm, you stand a much better chance of getting the what that is described when we talk about agility.

Peter

But only a better chance if you don't pay enough attention to not doing looking at what that how is.

Dave

Well, you it's interesting because the probability the probabilistic approach is one of the big paradigm shifts, right? Yes. The old paradigm is deterministic, the new one is probabilistic. So, yes, absolutely. It's not a guarantee, but knowing where we are and what we're doing, you stand a much, much better chance of achieving the what's that you're that are promised on the camp.

Peter

Yeah, and I would definitely agree with that. So with that, let's let's wrap this up for today. And uh uh, if you would like to provide us some feedback, you can at feedback at definitely maybeagile.com. And uh as usual, thank you very much, Dave, and uh hope you enjoyed the conversation. And uh we'll see you next time.

Dave

Peter, that was a fun one. Looking forward to the next one. Thanks again.

Peter

You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrock focus on the art and science of digital, agile, and DevOps at scale.

Agile Process Development,Process Flexibility,Why What How of Agile,Agile Application,Adaptation to Environment,Mindset Shift,Two Paradigms,Contextual Solutions,Agile Thinking,Consequences of Solutions,