Episode Description
This week, Dan Neumann is joined by Eric Landes to answer a listener’s question about development. Our listener asked: How can a non-technical Scrum Master or a Scrum Master introduce technical skills and practices to strongly opinionated engineers?
In this episode, Dan and Eric are sharing how to shift the mindset from wanting to know it all about the design to one where emergence is embraced. They share practical tips and examples of real Agile scenarios to make change easier and lessen its costs.
Key Takeaways
How to help engineers to embrace emergence:
Model the behavior and examples.
Go on a learning journey together. Invite them to join the process if they have some technical knowledge.
What is in it for them? They don’t have to spend time on a design to release that later could not scale as expected, or didn’t address the customer’s needs.
How to make change easy?
Emerging design is critical.
The design is fundamental to the core functionality, but the architecture is probably going to fall over in an unexpected way, even with experts things don’t always get exactly right. Testing rapidly is the way of finding what is wrong earlier.
Make critical architectural decisions first, instead of waiting until the last possible moment.
What are the things people need to get right in the first Sprint?
Chose at least one programming language to use.
Identify the tools that are going to be used and where are you going to deploy the first iteration.
Let’s experiment with the architecture.
The cost of change in the development is still present.
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 agile coaches corner by agile thought the podcast for practitioners and leaders seeking advice to refine the way they work. Van pave the path to better outcomes. Now here’s your host coach band, agile expert. Dan Newman.
Dan Neumann [00:17]:
Welcome to this episode of the agile coach’s corner podcast. I’m your host, Dan Newman. And today I have a guest that hasn’t been around the podcast for a while and I’m, I’m kind of bummed. Yeah. Eric Landis. Welcome back long time. No talk.
Eric Landes [00:32]:
Thanks Dan. Uh, yeah, it’s good to be back. No idea why, but, uh, rectify that in the future. I’ll I’ll come up with some topics.
Dan Neumann [00:42]:
You have no idea why it’s good to be back or you have no idea why you’ve been gone so long.
Eric Landes [00:47]:
Oh yeah. Both. No, just kidding. I’ve been gone. That’s good.
Dan Neumann [00:51]:
Well, right. And I mean, if you’re back that pretty much screams, we’ve got something that might be related to development as one of our topics.
Eric Landes [01:01]:
Yes. And very exciting.
Dan Neumann [01:04]:
It is exciting. And it is brought to us from a listener. I will, uh, just use their first name Andrew, and they say, how can a non-technical scrum master or scrum master introducing agile techniques and practices to strongly opinionated engineers. And, and I think I might have tripped over some of the words, but I mean, engineers are known to be a little strong minded. They’re analytical. Hopefully, otherwise I wonder if they’re any good. Um, and this person says, Hey, you know, I used to be a software developer. I’m paraphrasing here, not an expert on, in the way things are done at this point, but they’re not very far removed from being a production level engineer in their career. And they find themselves in a challenge of trying to convince people to take a less architecture, upfront approach, to embrace emergent architecture, move forward, versus having to quote, get the design. Right. Um, and I’m pretty sure I’ve lived this challenge. It’s almost like an email to my future self at one point. So I reached out to you Eric, and thought, let’s talk about what we might do to help shift people from I’ve gotta know all the design stuff to one where they embrace the emergence.
Eric Landes [02:19]:
Yeah. I love it. It’s it’s always a, a tough question. If you’re non-technical it sounds like for Andrew has some technical background, that’s that’s myself as well. I, I keep a toe in DevOps for sure, but production level, uh, development. I haven’t, as they say, coded in anger for quite a while. So, uh, I do stuff on the side though. So I, I personally use that to help connect with developers. A lot of times, if you can come back to a developer or an engineer, you start talking about unit testing, let’s say, uh, here’s a, a framework I can use in unit testing. And, and here’s maybe I understand get, and, and I know how to use your source control. That connects a little bit with, uh, with some of the development types that I’ve worked with. Uh, so that’s a way, if you have a technical Ben, you might, I might do that. Uh, I know this is not an uncommon challenge, uh, around emergent architecture, uh, specifically Dan, what do you think I’ll
Dan Neumann [03:36]:
Well, so what I think you’re describing is a little bit of, instead, it, for those who have that skillset, instead of telling it’s a little bit of a showing or a little bit of a pull up alongside them, and let’s do this together, let’s go on this journey together and see how it might work for us.
Eric Landes [03:55]:
Yeah, exactly. I think that will help build trust with the engineers. That you’re not gonna be somebody who’s doing production level development, but you’re also not talking from a place of ignorance. Now, I think that’s one way to do it. Now, if you’re don’t have that technical Ben, you know, feel free to read up like Bob Martin has some great stuff. Uncle Bob on emergent architecture, it’s a little older, at least the stuff I’ve read. So it’s, it’s definitely some good stuff from Bob Martin on emerging architecture and really the, of software development. So you can point teams to, they have a learning series around software craftsmanship, which directly addresses a lot of the emergent architecture. You can certainly to why these systems that emerge are much more resilient than arch than big design. We’re responding to change quickly. We’re responding to market forces. We’re more adept. Uh, there’s, there’s a lot of ways you can do that if you have some ex examples.
Dan Neumann [05:21]:
Yeah. So I think what you’re describing, right, the first one was here. Let me show you let’s come alongside, which could expose maybe as, as a technical person, you might learn some things about that particular domain that make emergence more challenging or have some nuance to it. And then you were talking about some of the, uh, thought leaders in emergent architecture, Bob Martin, and some of the ways, uh, learning some of those materials. It still strikes me that we’d have to convince or create an environment where these development specialists would want to go on that learning journey with you. So it’s not just, here’s the book. You gotta go read uncle Bob’s, you know, book X, Y, or Z, but how do you, how do you pull them in and create interest? Which means what’s the phrase what’s in it for me, with them, what’s in it for me, or how do you create some, some pull for that, learning
Eric Landes [06:16]:
That, that great question. And there’s a couple ways I would do it first. Are there folks that the engineers would listen to who would be an ally for you? Who, who get emergent architecture? I’d first start there, cuz that’s a, a little bit of an easier sell mm-hmm <affirmative> getting those folks involved and maybe having them suggest things like coding katas and stuff to learn that to, to become more emergent in, uh, in the design. And if that’s not an option, then you really have to start to maybe start a book club with a team or something along that line to have them start reading some of that more modern architectural design, if you will, for software and, and get folks involved, get questions going, then you can answer those questions for them. Uh, when they have that, uh, you had what’s in it for them. Well, I don’t have to spend three months in a design phase. And at the end of this, realize that my design was messed up and didn’t didn’t, uh, scale well, or did not, uh, address the customer’s needs that that’s the fear of the big design upfront. Um, and it’s a non way to do it. So those, those are some things I would use.
Dan Neumann [07:48]:
Yeah. It strikes me when people want to, you know, get the fill in the blank. Right. I, I think when I talked, I probably said this once upon a time in the 180 or so previous episodes, but when you get my specialty figured out, we can go be agile. When you get the data model, if I’m a database guy, you just figure out the data model. Then we, that UI stuff’s easy. We’ll just go iterate on that. Cuz that’s, that’s easy. You get the UX designer. Who’s like, whoa, until we do the journey map and the personas and the, the mockups and the blah, blah, we put, then we’ll just iterate through the development cuz we’ve nailed. And it’s, if we can just get everybody to realize that their specialty’s not that special and that it has the same flaw to it, which is you are not gonna know everything up front.
Dan Neumann [08:37]:
You can’t, you won’t stop it, give it up. The question is how do you make change easy? How do you make your architecture so that it is, I’m gonna throw out some terms like I know I’m here loosely, coupled, right? Loosely coupled your architecture or you’ve got separation of this part is responsible for function a, this part’s for part B and, and they’re not, oh, we’ve gotta get the exact thread all the way through figured out. Um, so how do you make it easy to change instead of hard to change? Cause hard to change is what drives. We’ve gotta get it right first.
Eric Landes [09:08]:
Yeah. And I would use war stories as well. If, if you have any, um, one of my best stories is an application. When I first started doing agile, we actually went to an uncle Bob bootcamp, uh, learned XP. And uh, and this was right before I met Dan who ruined my life.
Dan Neumann [09:30]:
<laugh> did I tricked you into joining me somewhere? Yes I did. And look at that. We just held hands and skipped down the road together after that <laugh> <laugh>
Eric Landes [09:39]:
And then I tricked Dan to come.
Dan Neumann [09:41]:
You did, which
Eric Landes [09:42]:
Thank you. And it works out great. He’s doing a podcast. So
Dan Neumann [09:45]:
Six years at agile thought, uh, going on almost six and a half. So yeah.
Eric Landes [09:50]:
Nice.
Dan Neumann [09:51]:
That worked out pretty good following you.
Eric Landes [09:53]:
Yeah. So this proves
Dan Neumann [09:54]:
I’m proves I’m a better salesman though, because I got you to buy something. You probably didn’t want <laugh> that’s true.
Eric Landes [10:03]:
No, it’s all good. It’s all good stuff. But before I met Dan and really when I started the agile journey, um, we created an application and had a lot of resistance from the management there as far as using XP and using that iterative development model. But we did it in such a way. We did that emergent design. We did, um, unit testing. We did acceptance driven, testing everything automated. Of course, when I say unit and acceptance testing, apparently I have to qualify that even you,
Dan Neumann [10:41]:
You do, we have a war story about that we could share at some point. Yes. Yes.
Eric Landes [10:46]:
But the, the, a couple of things first, we had a huge architectural issue in the middle of design because we did emergent design. We were able to in one sprint, turn on a dime, change, that architecture, cuz we hadn’t fully flushed everything out, made us more flexible. We figured that actually would’ve taken us like two months. If we had done it that big design up front and then had to encounter this issue, um, as we were developing. So that was a, a, a great, great thing that happened. And I would like to say because of that emergent design boy, I wanna say three or four years ago, this, this happened say 15 years ago, three or four years ago, somebody told me that application is still in existence. They haven’t really touched it. And it’s probably the most rock solid application that group ever put out. And it’s a global app in internally for that company. So that’s my war story around emergent design. Hopefully you’ll have some, but you know, feel free to steal that if it, uh <laugh> if you want
Speaker 1 [11:58]:
Habit topic, you want us to tackle, send an email to podcast agile thought.com or tweet it with a hashtag agile thought podcast.
Dan Neumann [12:08]:
That’s a great story. And I’m looking at the words that Andrew used in the question, you know, they, the, the people he’s talking with say, you know, the design is fundamental to the core functionality of, of the entire thing, which is true. And it, it makes me think of the betting metaphor. Are you gonna slide? Yes. It’s important. So are you gonna slide all your chips in and hope that card comes up because there’s more, there’s more scenarios where your architecture is probably going to fall over in an unexpected way than even with really smart people, putting a lot of thought into it, them getting it exactly. Right. Um, you know, I, people are launching rockets right now and yeah, they have some design, but boy, they test them quick now. Right. And, and they still get it wrong. Things explode occasionally. So the question is how do you get ’em to explode early and quickly versus latent catastrophically
Eric Landes [13:04]:
Great point. And that’s, that’s really what you try and do in emergent design. Of course you have to come up with, Hey, what are we going to code in typically? And you know, where are we gonna put this stuff? I mean, those are decisions you have to make architecturally, but I believe those can be made pretty quickly. We don’t have to take three months to do ’em, you know, we can, we can actually, I like when we start and we kind of know what we’re using and we make some architectural decisions in that first sprint and try to do some things with it and evolve from there, make those critical architectural decisions first and, you know, uh, wait until the last responsible moment to change that architectural decision.
Dan Neumann [13:54]:
Oh, so I’m gonna, I’m gonna use that foil again. So, well of course my dis of course, the thing I care about is going to fall into Eric’s critical bucket. So at, I think when you say, what are the critical ones I’m hoping there’s a pretty small set. Yeah. Are we gonna use.net or whatever, some other technology are we going to use this code repository or that one, are we gonna use, uh, maybe Amazon or Azure web server. And actually I think if you container eyes and do some of those cool things, you get some flexibility there. So what would, what’s your short list of things maybe people need to quote get right in their, their first sprint. And I won’t call to sprint zero. Cause you wanna do something with it in your first sprint deliver an actual increment. So what do you gotta nail?
Eric Landes [14:39]:
Y you certainly would wanna nail at least one programming language you’re using to get part of like, assuming your coding. You know, if you’re doing, let’s say, uh, uh, you know, analytics or something, it might be, you know, what are we using for that? Not here’s the data model. We’re not creating the data model. It’s what tools are we using? Where are we going to deploy this for our first iteration that that could change right? To, to your point, if we contain our eyes, we start developing for Azure and Microsoft may not like me for this. And then we decide to go to AWS or Google. We have a low cost of
Dan Neumann [15:22]:
Change, then you’d realize it was a mistake and you come right back to Azure anyway. But
Eric Landes [15:26]:
Thank you. Yes.
Dan Neumann [15:27]:
Yeah, of course. And then
Eric Landes [15:28]:
You, when you realize how much better it’s yes. <laugh>.
Dan Neumann [15:31]:
And as you were describing that scenario, it occurred to me that there’s a bit of a trap in, we have to pick one first and there’s nothing wrong with trying both, let’s try two or three different cloud things like super skinny, right? You’re not gonna build the application for all three cloud things you wanna do, or for three different languages you might wanna try or three different patterns. You’re not gonna do it very robust, but take a small thing. You do well, you, and I let’s say do it together in, in language a, B, and C and see what happens, try it in cloud X, Y, and Z, and see what happens. So then you’ve got an increment and you, aren’t just sitting around with the great debate continuing on for months usually.
Eric Landes [16:17]:
And, and, and that’s a fantastic point, Dan of let’s experiment with our architecture. I mean, we talk about experimenting with stories and doing some experiments to see if we’re right, let’s do that in the architecture. Let’s get some fundamentals outta the way. We probably have some standards that we code by. We probably have some standards around what we code in and maybe even where we’re deploying, if we’re containerized or not, those are pretty simple follow the patterns that, uh, you may, you may say, Hey, we wanna follow these particular patterns. We need a, you know, message bus. And we’re gonna use that with, to get our messages, to all the different applications we’re gonna have APIs, blah, blah, blah. That’s great. I mean, we all kind of know that language now. So those are pretty easy things to do. Let’s start simple and build from there. And let’s experiment with the architecture. Um, maybe, maybe we do Azure arm templates and Docker containers for the first couple sprints. We see which, which we like better. Right. Uh, feel free to do that. So it gives architects a lot of freedom. Like you said, to, to make the right decision in the end, instead of putting all our chips in that, uh, Azure bucket or Docker bucket, whichever way we’re going, because things change like now we have to pay for Docker. Right. Um, locally, maybe we gotta do that. Maybe that impacts us.
Dan Neumann [17:54]:
Yeah. So thinking through, um, oh gosh, I’m gonna date myself. I know in the nineties I saw things that, uh, things being charts that would show the cost of change as you get later in development, it was one of the reasons why in waterfall, you had to get your requirements, right. And your design, right. And your code. Right. Cause boy, if you discovered something, a test, oh my God, you had to go back and do the whole, and those are super expensive. But if you just nailed the requirements, it was gonna be really cheap. Uh <laugh> and, and here we are. I feel like that mindset is still present. Even though the ways to address the cost of change have improved change. When you’re embracing certain practices can be less expensive than the charts that I saw 26 ish years ago.
Eric Landes [18:45]:
That that’s for sh that’s very true. The cost of changing. If I’m doing something in the cloud, architecturally, I can spin things up, realize it’s wrong. And instead of having bought a machine, I’ve spent a fraction of that to realize that was the wrong way to go. Now we can spin up that other those other services or whatever we’re using. And it’s a, I don’t wanna say it’s an easy change. Yes. It’s gonna take time, but it’s a much easier change than getting to the end and telling your business folks, oh, by the way, we can’t really scale up to those, you know, 200,000 users because we only built this for 20,000 when you told us that at the beginning, and now you realize it’s, we have to scale much more.
Dan Neumann [19:37]:
Yeah. Um, as I think through the question, the scenario again, I think, uh, a, an unsuccessful pattern would be, try to wear them down with arguing. That is probably an unsuccessful pattern. Uh, what do you think of taking it to the team? Crazy agile thought, take it to the team with how could we lower the cost of change? What would it take to make change easier and have, have them bring in, Hey, what are three things we could do to make changing the architecture easier?
Eric Landes [20:12]:
That is crazy. Talk Dan, to take it to the team. I was thinking, are you an agile coach or something? That’s
Dan Neumann [20:17]:
I play one on TV. Yeah,
Eric Landes [20:20]:
Of course I am being facetious. When I say that <laugh> that we certainly would want feedback from the team on how to do that and getting that engagement with the architecture folks saying, if, if that’s a separate group, Hey, the team says we can do it this way. They’ve got a plan. Why can’t we do it that way?
Dan Neumann [20:42]:
Perfect. Also being crazy agile people, you have a time box and we’re coming up that in just a couple minutes. So I want to, uh, maybe just think through a little bit of a recap. So part of what you were suggesting was, uh, modeling the behavior, modeling some examples. That was where we started, um, going on a, a learning journey together, right? You had talked about doc, uh, Dr. Bob uncle, Bob Martin, um, who, uh, definitely does not have opinions for people who are not familiar with him. He is not opinionated at all. Um, so that, that is part of it and definitely engaging the team in a journey of exploration, whether it’s trying out different approaches or, uh, thought exercises for how could we make the changes less expensive, um, on your way out, what is on your continuous learning journey right now, Eric,
Eric Landes [21:36]:
My continuous learning journey. I’ve started, uh, doing some open source development on react. I’m trying to learn some react cause I know JavaScript enough to be dangerous. And I just wanted to learn something new. So doing that and getting a little more, actually, I should say a little better with GitHub actions. Cause I, I know how to do pipelines and stuff in Azure DevOps. Now I wanna try GitHub.
Dan Neumann [22:08]:
That’s awesome. So we like give a prize for people who could find your, um, your submits out there on GitHub <laugh> yeah. Send critiques to podcast to national thought.com and we’ll make sure to pass those along to Eric. <laugh>
Eric Landes [22:24]:
I love it.
Dan Neumann [22:25]:
Not creating safety, is it?
Eric Landes [22:27]:
No,
Dan Neumann [22:27]:
<laugh> sorry.
Eric Landes [22:29]:
Sorry. I just, yeah, I’ve done like, uh, I’ve got, I’ve gotten maybe two commits myself into the journey, so
Dan Neumann [22:36]:
That’s awesome. You’re you’re probably a couple commits ahead of me. I’m not sure I’ve, I’ve done that, but uh, I could close my eyes and pretend that I can still do software development. Uh, like we all do that right? The mid nineties. Yeah.
Eric Landes [22:48]:
That’s awesome. <laugh>
Dan Neumann [22:49]:
Eric. I wanna appreciate that you joined. And I also want to, uh, remind folks to send us questions or things that are interested in hearing explored@podcastatagilethought.com. I do read them sometimes it takes me a little while to work ’em into the schedule, but they, they are consumed. And Eric, thank you for joining on this question from
Eric Landes [23:08]:
Andrew. Thank you, Dan. This has been fun.
Dan Neumann [23:12]:
All right. And we’ll do it again.
Outro [23:16]:
This has been the agile coaches corner podcast brought to you by agile thought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of agile thought. Get the show notes and other helpful tips for this episode and other episodes@agilethought.com slash podcast.
Want to Learn More or Get in Touch?
Share These Tweets!
“Make critical architectural decisions first, instead of waiting until the last possible moment.” — Eric Landes
“Take the cost of change to the Team for them to figure how to lower the cost of change and to make an architectural change easier.” — Dan Neumann
