Side effects of going agile

Podcast Ep. 134: The Positive (and Negative) Side Effects of Going Agile

Side effects of going agile
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description

Today, Dan and Sam are joined once again to discuss agility — more specifically, the side effects of being agile.

The side effects of agility are often not the reasons why you should start an agile transformation, but they are still very valuable and helpful to know about.

In this episode, Dan and Sam discuss the positive side effects that organizations might want out of agility, the indirect effects (both positive and negative) of putting certain agile practices in place (or not putting them in place), and how to address the challenges that come along with losing focus on the primary principles of agility.


Listen on Apple Podcasts

Key Takeaways

  • Why should you start an agile transformation?
    • Look no further than the Agile Manifesto
  • Common side effects organizations want out of agility:
    • We’ll get more stuff more quickly/twice the work and half the time
    • Increasing customer involvement
    • Improving the prioritization of features
    • Increasing team buy-in and involvement
    • Adapting to change during development
    • Better understanding the project’s status
    • More efficient planning and estimating
    • Continuous risk management
    • Delivering the project needed at the end
    • Achieving the right level of project structure
  • Potential negative side effects and how to combat them:
    • The agile principle “welcoming changing requirements” does not mean adding requirements
      • When a priority is changed, that means something else isn’t important anymore
      • It is key to clarify the priorities and remind everyone of the consequences/cost of changing them
      • Look at the cost of waiting to start the new thing vs. abandoning the old thing
    • Building lots of stuff that you don’t ship and length requirements lists that you may never be able to get to (therefore generating excess inventory and waste)
      • You should instead focus on delivering value in increments
      • Use the “MVP” (minimum viable product) strategy i.e. getting something potentially valuable to your customers quickly so that they can evaluate it and you can measure it
    • Launching a product vs. the value you want to bring
      • When you don’t embrace agile fully and attempt to scope out a large project by creating a static backlog and ix the team members, you will eat through the backlog (the best-case scenario is that you get a product and the worst-case scenario is that you don’t get a product and have a lot of work-in-progress)
      • Think about your outcome rather than the activity than you’re engaged in or some artificial target
      • When the goalposts are set and there aren’t true inspection and adaptation, it’s not an agile approach
    • If the primary benefits of agile are not met, the secondary benefits will not matter as much and the agile transformation itself will be brought into question and challenged
      • When there is a purpose to what they’re doing, employee satisfaction and fulfillment goes up

Mentioned in this Episode:

 
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]

Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach, and agile expert, Dan Neumann.

Dan Neumann: [00:16]
Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host, Dan Neumann and joined today, like often by Sam Falco, sometimes you know, as a fungible resource, we swap you out for somebody else. Yes, yes.

Sam Falco: [00:45] Thank you. Um, hopefully the, uh, audio engineers can, can get out the sound of my teeth grinding. When you say resources for human beings.

Dan Neumann: [00:56] Fungible resource. One of my favorite terms and I went on just a, I don’t know a rant on Twitter. It was, I is one Twitter rant. I know best practices is another term that just drives me up a wall, especially when there’s no such thing.

Sam Falco: [01:13] Well, best practices are really great for simple domain problems. Um, when you, you, you know what your requirements are and there’s no surprises there, you know how to do it. It’s great. I want my mechanic to use best practices for changing the oil in my truck. I don’t want them getting creative. I don’t need them to have a scrum meeting about it. Just drain the old oil, put the oil cap back on and put more oil in. I actually don’t know if that’s how you change oil. It’s been so long.

Dan Neumann: [01:42]
That’s not, that’s not too bad. So there you go. That, uh, that E how tip then, aren’t you glad you tuned in? Well, they will be glad because we’re going to be talking about agile side-effects today.

Sam Falco: [02:03] Yes. I rather than revisiting click and collect the Tappet brothers.

Dan Neumann: [02:07] Oh, I miss those guys.

Sam Falco: [02:09] That was trending on Twitter a couple of weeks ago. Cause I don’t know, there must have been an anniversary of the show ending or something like that.

Dan Neumann: [02:14]
But anyway, let’s not, let’s not, let’s talk about agile side effects, but uh, but we could, we could add a few skate, some things and some of the other things that seem to work for the car talk guys. Sure. So agile side effects.

Sam Falco: [02:28] Yeah. Oh, this is something we were talking about right before we went on the air. There’s a lot of stuff. Oh, we want to be agile because, and people will name various side effects. That aren’t what agile started out as, uh, intending to be. And there’s nothing wrong with that, but it’s interesting that we hear that, oh, people will be happier. Uh, we’ll get more stuff more quickly. Uh, and all these are great side effects, but they’re not, they’re not why you should start an agile transformation necessarily, or maybe they are, but they could work their initial thrust. Yeah, I guess.

Dan Neumann: [03:06] Right. Initial thrust then for me, I usually go back to the agile manifesto for, they have a very intuitive URL of agile manifesto.org, um, for the values and the principles. And that’s for me, where I go back to with what was the agile thing as first described by the folks that describe it, I guess I’m having a bad English day. Um, and so they don’t talk about, you know, twice the work in half the time or anything like that, they, they talk about the highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Sam Falco: [03:42]
Right. It’s about feedback loops and getting insight into what you’ve built quicker so that you can then make sure you’re delivering what customers actually need and want rather than what they think they need and want, or even if they guessed right, doing the most valuable piece of that first so that they can test their hypothesis and, and move. And then when things change, as they inevitably do pivot and adapt what they’re doing to meet a market need.

Dan Neumann: [04:14] The first agile conference that I attended, kind of the big annual agile conference sponsored by agile Alliance. It was 2009 in Chicago. And one of the books they were giving away was a book called becoming agile in an imperfect world by Greg Smith. And I dusted that bad boy off, um, actually just this week, cause I was trying to look for some better ways to describe what organizations might want out of agility, right? There’s you know, the, the twice the work half the time thing is, is, uh, became pretty popular with a book by that title. And in becoming agile, they have a nice list of about 10 things. It is exactly 10 things actually that, that people might want one of increasing customer involvement, improving the prioritization of features. One of them that I liked was clarify the priorities and remind everybody of the consequences of changing them. Um, which I think is a good one because I see that create side effects. Oh, agile means we can change. It says welcome changing requirements, right there. Number two and they get they’ll go, holy crap. When we, when we change our requirements, that means something else isn’t important anymore. Or when they change our priorities, it means something else isn’t important anymore.

Sam Falco: [05:36] Yeah. I think some poems people see that changing requirements and what they see is adding requirements, taking nothing away and don’t change your don’t change your schedule because you still need to change requirements. Uh, and, and they feel like they can add it. And even when they really do want to change it, I like that idea of that. Reminding people of the cost of change, even if I could afford to buy a new car every month, like let’s pretend that the car payment wouldn’t change and I wouldn’t have to put anything down. There’s still a tax entitled. There’s a cost to making that change. That, that isn’t obvious at first and with businesses wanting to make changes as a cost, you’ve already got people working on something, so you’ve spent money on them starting to build something. And now you’re going to set that aside and it’s not like we can just come back to it and everything is, we can pick up where we left off there’s then a cost of getting our minds back around that problem. Now the code is stale. If it’s a software product, maybe it’s no longer valid because some of the other changes now made that code obsolete. We have to redo the solution cheaper perhaps to just finish the thing before you start the new thing, maybe look at what’s the cost of waiting to start the new thing versus the cost of abandoning the old thing.

Dan Neumann: [06:56]
I see that, that side effect. Yes, we welcome changing requirements. There’s the cognitive load then just to think about more things, if you haven’t captured the value from the previous thing you’re working on. And I see that a lot of times with long running, um, you know, the epics feature story, not in the Scrum guide, but a complimentary practice that some folks usually, uh, embrace and epics take a long time features take a long time. And when those don’t have increments of actual value that can be delivered to customers, that’s just more stuff that stays in progress longer. That’s more costs that gets incurred and there’s no value delivered. And so I think people see the welcome changing requirements part, but they don’t do continuous delivery of valuable software and they don’t do the changing requirements because they want to harness yet for customer’s competitive advantage, which is the last part of that principle.

Sam Falco: [07:56] Right? And when we’re building lots of stuff that we don’t ship for whatever reason, we’re just generating inventory, excess inventory, and actually lengthy requirements lists that we don’t know that we’ll ever get to is also a form of excess inventory. And stepping outside of agile and going to, to lean excess inventory is a form of waste. We’re generating a form of waste for organization that gets overlooked because there’s not an immediate dollar amount attached to it.

Dan Neumann: [08:27]
Agreed. I hear scenarios pretty often with we’re doing a big effort. How do we deliver an increment of value when, you know, sometimes it’s along the lines of an ERP system or some kind of, you know, buy the package configure and customize the package, a launch, the package type of approach.

Sam Falco: [08:50] Right? Another misuse that gets associated though is people will say MVP. And what they really mean is release one a year from now. That’s not an MVP, I guess we’re kind of wandering off the path we set for a agile side-effects but this is a term that has come in and been applied and people think it’s part of Scrum. And so I guess we can talk about it. MVP means get something that is potentially valuable to your customers quickly so that they can evaluate it and you can measure it, not the first release that we’re going to stuff a bunch of stuff into, that’s just doing what you used to do.

Dan Neumann: [09:26] I think the side effect for me is there’s the allure of doing the MVP thing. You know, getting, getting our lean startup on, in a very mature organization. We’re going to do, we’re going to do the cool thing and we’re going to call it an MVP. Right. In reality, it’s, it’s a pretty big launch. Um, there’s often nothing minimal about it. Yeah. In some scenarios, maybe that makes sense. Self-driving cars. I’m not sure I want the minimum. Hopefully it’s a pretty high bar for, for a car to be autonomous.

Sam Falco: [10:00]
Well, let’s, let’s think about that. We’ve already, we’re already going in that direction. Um, there are cars that will resist the steering wheel when you try to change lanes, if there’s someone next to you. So we’re, we are incrementally developing the technologies that will be needed someday to make cars fully autonomous. If that’s actually possible. I keep hearing like, oh, we’re five years away. And I remember I’ve been hearing we’re five years away from curing cancer since the seventies, when I was a kid and I read it in the weekly reader. So, but going, I’m going to go off on that tangent. We’ve also made enormous advances in, I wish this was a video podcast. Cause the look on Dan’s face as I go from tangent to tangent is priceless, but we made enormous. Yeah. We made enormous advances in the treatment of cancer and now cancer is no longer or many cancers are no longer automatically a death sentence. So I think it was Nixon that first articulated the idea of, of we’re going to cure cancer. You know, he was trying to, uh, get his moonshot moment. Um, but what we have done since then is all right, let’s, let’s improve detection of cancer. That that’s a small step. Let’s improve survivability, let’s improve, et cetera. Uh, we’ve made a lot more advances in that. And so while we are maybe still, you know, X number of years from curing cancer, that will never come, we’ve come a long way. Same thing with, um, the way we have made automobile safer and able to, to a certain extent, drive themselves more.

Dan Neumann: [11:45] So I think I want to try that back to the difference between a product we need to we need to launch the product versus talking about what’s the value we want to bring. Cause you were talking about some of the, um, uh, assisted driving techniques. I had a car that at one point just beeped at me when you were changing over what it thought was a line marker, um, without the turn signal. So it seemed on it. So the car would beep there are the ones that resist, um, another step towards making the car safer. There’s I had a rent, these are all rental cars. I drive old used cars, but there’s the one with the radar that will slow you down. If you’re you’re approaching somebody on cruise control. So the outcome I believe is making it safer to travel in a car. Um, it’s not the one big throw the giant lever to autonomous driving, right? There’ve been all these steps of, of value delivered along the way.

Sam Falco: [12:51] It’s a whole different way of thinking about what we’re doing. I like that idea of thinking about your outcome rather than the activity that you’re engaged in or some artificial target.

Dan Neumann: [13:03] And I think that the side effect, I don’t know if it’s a side effect of agile or a side effect of not really embracing agile fully is when we say we’re going to, let’s say scope out the large project and we’re going to create the backlog that we believe is going to be static. And then we fixed the team members. And then we’re just going to iterate in two week chunks towards through the waterfall plan. I don’t even know if iterates the right term. We’re just going to go through in two week chunks and report status every couple of weeks. It’s not iterating.

Sam Falco: [13:37] We eat through the backlog. Eventually we get a product or not, well, best case scenario. We get a product, right?

Dan Neumann: [13:46] Worst case scenario. It follows the trajectory of typical waterfall plan driven things where you don’t get it. You know, you’re, you’re, you’re not delivering increments of value. So you have lots of work in progress. You’ve deferred testing till late. You’ve deferred getting feedback from actual customers till late. Yeah. You might have poked at it internally with your testing and maybe even automated some tests, but when the goalposts are set and there isn’t true inspection to hand adaptation and there isn’t delivery of increments that could be launched, should we choose to. It’s not a particularly agile approach, even though we’re doing it, we have a Scrum Master Product Owner. We’re doing the thing.

Sam Falco: [14:30]
Yeah. Right. And then you get from often higher ups in the organization will be, will, will have the attitude of, well, agile doesn’t work. I’m not getting my products any faster than I was before. I’m not having any greater success or marginally greater success perhaps than I was before. And great. Everybody’s a little happier, but is that helping us? And that’s again, you get the side effects cause you don’t get the actual intention. Not that having happy employees is a bad thing. It’s really important. But if we don’t get the, the rest of the benefits, the primary benefits, then, then it makes people challenge the idea. Why are we even doing this? And maybe I can make my employees happy in a different way that I understand let’s go back to waterfall, but we’ll have, you know, employee happiness initiatives.

Dan Neumann: [15:24] I’ve seen people become more satisfied with what they’re doing at their job when there is an actual purpose to what they’re doing when they make something and somebody loves it. You know, here’s the widget that we made that, that solves your problem. That’s pretty exciting.

Sam Falco: [15:44] That is a pretty good feeling. Um, I worked for an insurance company for awhile and one of the things that people on my team would often do is go sit in the call center, had nothing to do with actually the product they were making because sit in the call center and listen in on people who are calling into, um, because their loved one has just died and they’re trying to navigate the system to get the life insurance payment and boy, do you get some empathy for your end users listening to, to that sort of thing. And even though the specific product that team was working on, didn’t directly connect, they knew that in the end, that’s what they were working toward, was helping people claim their life insurance policies.

Dan Neumann: [16:27] That’s pretty interesting to kind of see how you can impact somebody in a puts typically a pretty rough time in their life. Right? Right. So as part of our time here today, we talked about some of the challenges that organizations face when they’re trying to be agile and in a way lose sight of their purpose. And we talked about, you know, the, the first principle of our highest priorities to satisfy the customer through early and continuous delivery of valuable software. That’s an example where when done, well, there can be indirect effects or side effects of you’re talking about satisfied employees. It’s pretty awesome to be in an organization that is early and continuous and it’s delivering valuable software, right? It can also end up with negative side effects when teams focus instead on roles, events, artifacts, best practices, processes, reporting, et cetera, and, and create a side effect of a very unsatisfied work.

Sam Falco: [17:34] Yes. Uh, if you’re not actually delivering, because then stuff comes down from up above, why aren’t we getting our stuff? Um, why am I, again, going back to why? I think I said this earlier, uh, why are we not delivering any faster than we were before, or even marginally faster, but not enough to justify the money we spent on this transformation. And then, so we’re just going to go back to the way things used to be.

Dan Neumann: [17:57] And as stakeholders on the outside, they’re like, what, how is this different than what I used to get and done poorly? It’s not any different. Exactly. Awesome. So Sam, what are you reading these days? What’s on your continuous learning journey?

Sam Falco: [18:12]
I just started reading a new book, Daniel Conaman and two other offer authors whose names escape me at the moment Daniel Kahneman wrote author of thinking, thinking slow, slow. Yeah. It just came out on Tuesday called noise of flaw in human judgment. And the argument here is that decision-making by humans is influenced by an awful lot of factors that have absolutely nothing to do with the decision being made. In addition to bias, the specific example that comes to mind immediately is, um, African-American, uh, defendants are sentenced to harsher sentences than white defendants for the same crime, with the same general circumstances. We can show that, but also if you control for bias, you still get a lot of statistical noise for the same crime, same circumstances set of circumstances, three years, 12 years of fine. These don’t make sense. And, uh, they are talking about the enormous cost that incurs to society and to companies which make poor decisions or a wide scatter of decisions when we really need a tighter grouping. So I’m only a couple chapters into it, but I’m really excited because thinking fast and slow was so useful in my agile coaching career. I’m sure that the lessons to be learned from this book are also going to be super valuable.

Dan Neumann: [19:45] Awesome. Looking forward to circling back on that sometime, and mine has been dusting off this becoming agile in an imperfect world and kind of finding some different ways to articulate some of these agile benefits or agile wants that that organizations might be pursuing. So I want to thank you again for joining me on the podcast.

Sam Falco: [20:05] I am glad to be here.

Dan Neumann: [20:06] Until next time.

Outro: [20:09] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions and information expressed in this podcast are solely those of the hosts man, the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.

Stay Up-To-Date