podcast-ep-117-agile

Podcast Ep. 117: Don’t Get Your Agile Shorts in a Knot

podcast-ep-117-agile
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

Oftentimes, those who practice agility will turn their nose up at teams or companies that are not doing agile perfectly. And though the agile practices are important and are great pathways to success, many teams and companies often find ways that work for them that are not perfect agile. In this conversation, Dan and Sam highlight some of the ways in which companies and teams find what works for them, why perfect practicing agility isn’t the end-all-be-all, share the key characteristics for succeeding in agile, and, most importantly: Why you shouldn’t be getting your agile shorts in a knot.

Listen on Apple Podcasts

Key Takeaways

  • Should a team or company be doing agility perfectly?
    • If a team finds a helpful practice for them, then that’s what they should do
    • “That’s not agile”, or “That’s not the way story points work”, is not very helpful to somebody
    • It’s important to remember that everyone is on their own agile journey and you shouldn’t judge where they are right now in it
    • An agility mindset is what really matters; they will improve their practice over time 
    • As long as it works for them, they’re delivering, and their customers are happy, then they’re good
    • Just because a team isn’t doing something by the book doesn’t mean they are wrong in doing it
  • Advice in entering a new role within a company that’s getting started with agility:
    • Enter the company/role with curiosity
    • Just because the role states you will be doing certain things doesn’t mean you will always be doing those things/won’t be doing other things
    • Start with what the company already knows/is doing; you can adapt as you go along
    • If you’re interviewing for a position of any kind, it’s not just about, “Do they want you?” but, “Do you want them?”
    • When selecting a company you want to work for it is important to make sure that they breed a culture of innovation (regardless of where they are in their agile journey) and have a culture of constantly wanting to inspect, adapt, and innovate
  • Strategies for failure in agility:
    • There are degrees of planning that can be unhelpful when trying to forecast things out — but zero planning is also a strategy for failure
    • There is this idea that agility is a binary state (i.e. “You either are or you are not agile”) — agility is more of a continuum (it never truly ends)
  • Key characteristics for succeeding in agile:
    • Curiosity is a key characteristic of anybody who wants to succeed in agile
    • Low tolerance for impedance and that we cannot change things; we have to do it this way
    • Question how things could be done/how things could be done differently 
    • Asking: “What would happen if ______?”
    • Having an experimental mindset
    • Don’t make assumptions about what you think are bad practices/what isn’t agile — you could learn a lot from these experiences

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 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] I have an exciting opportunity. I want to share it with you. Coming up on February 25th, we will be hosting a digital velocity summit. This thought leadership event focused on accelerating innovation is designed for anyone looking to build a state of continuous adaptation, empower their teams to accelerate how they work and deliver value to their organization. With sessions geared for people interested in AI, data analytics, agile, and cultivating innovation in their organization. Our guest panelists and agile thought leaders will share their perspectives. During dynamic discussions. Join us on Thursday, February 25th at 1:00 PM Eastern time for this virtual event, go to agilethought.com/events today to learn more and RSVP.

Dan Neumann: [01:04] Welcome to this episode of the Agile Coaches’ Corner. I am your host Dan Neumann here with fellow host, Sam Falco.

Sam Falco: [01:10] How you doing?

Dan Neumann: [01:11] Wonderful. I’m a, I was cruising LinkedIn and of course there’s lots of job descriptions, uh, you know, good, better and different from my colleagues. I’m not looking. I’m sure there are many opinions. But, uh, no, it was a comment from somebody who had stumbled across a job description and the title was project manager, Scrum Master, all four words. And somewhere in that job description was a responsibility to ensure that the team is properly using and updating JIRA. Okay. And the Howells. Oh, the weeping and gnashing of teeth about how some people would never touch that job description and, um, you know, picking on, Oh, that’s just an agile project manager, whatever, you know, whatever that might mean. And it was, it was fascinating just to see people getting, uh, upset or, or sneering at the job description.

Sam Falco: [02:16] Yeah. I saw that too. When JIRA announced sometime last year that they had introduced the ability to do decimal points in story points. I saw someone post, I forget whether it was on Twitter or if it was on LinkedIn, but basically saying, why are you getting your shorts in a knot over this? If a team finds that this is a helpful practice for them, then that’s what they should do. And talking about how that’s not agile or that’s not the way story points work. How was that really helpful to somebody? And we do see a lot of that, right? Where people just turn their nose up at something that isn’t the agile practice they know, or maybe it really isn’t a great practice, but it’s where somebody is right then. You can’t really judge whether someone is agile or not, uh, based on where they are in their practice. Uh, it’s about their mindset. And if this is what they know so far then, okay, is it working for them? That’s really the first question you have to ask is does this work for you? Are you delivering? Are people happy? All right. Then maybe it’ll touch that necessarily. I think I’ve told the story before where I came into an organization and I here’s your team and there’s 15 people. And I thought, well, that is way too big for a Scrum team. That’s the first thing I had to change. And fortunately, I kept my mouth shut because no, that this team had figured out how to work together at that size. They had other problems. And by observing, I was able to say, Hey, here is something I see you’re struggling with, what do you want to do about it? Instead of just coming in and saying, well, in the book it says X and you’re not doing X, so therefore you’re wrong.

Dan Neumann: [04:07] Yeah. I think of the, is it working for them? And there are times when, uh, you know, pre pre COVID pandemic where we could actually be in a room and actual post-it notes on a physical wall might be a legitimate strategy for a team to coordinate on transparency and collaboration. That’s a challenge in a distributed workforce. To use post-its on a wall. I said, it could be done. I suppose, you know, everybody put the post-its up, share photos back and forth. Point the camera at the wall. I’ve done strategies like that in the past, even pre COVID. Um, but gosh, you know, Azure DevOps and a board is pretty effective at moving things around. JIRA is pretty effective and it’s really hard to collaborate when people don’t update the tool that enables collaboration. So yeah, proper use of a tool is a legitimate strategy.

Sam Falco: [05:09] Right. So we see this job description that says part of the role in this, uh, job description is making sure that the team does this while someone might need to do that right now. So maybe you go in and you see how things are going, and maybe you teach the team to keep it updated on their own, just because the job description says, this is what she’ll be doing. Does that mean you’re always going to be doing that? And maybe the organization is open to a better way. That would be, if I were interviewing for that job, I would say, Hey, I see this. Here’s some things I’ve done. Would you be open to that? Would your teams be open to that? Because of course, if you’re interviewing for a position of any kind, it’s not just about, do they want you, but do you want them? And I think if the organization says, well, yeah, we just that’s the way we do it right now. Well, okay. Let’s, let’s start with that.

Dan Neumann: [06:07] And I think that the reaction that one might get would say a lot about the degree to which that’s a good culture fit for you, independent of, you know, the pass/fail on your personal sniff test for agility or not. Right.

Sam Falco: [06:21] And I think if you’re, I mean, if you’re looking for a job where you won’t have to have any challenges in helping people improve, well you’re looking for a job where you’re probably going to be bored, I’m reminded of a friend of mine. One time told me that he and his wife had found the perfect church and he said, and then we joined it and ruined it. It’s pointless. There’s no such thing as perfection, we’re all human. And he didn’t want to be in a perfect church. He wanted to be in a church where everybody understood that they had their struggles and, uh, and being better people and working together on that and, and holding each other up when they, when they stumbled. And I think there’s a similar thing in the workplace. If I joined a perfect company, I’m going to mess it up because I’m not perfect.

Dan Neumann: [07:12]
When you were talking about that, Hey, you know, um, would get bored. You know, if, if, if you weren’t improving, I suspect I would as well. But I, I also feel like as I go about life, there are some, there are a lot of people that are pretty happy in the process that doesn’t change. Um, pick on some of the civil servants, right? Government isn’t known for rapid innovation in a lot of places and doing the same thing for 10, 20 or 30 years is a pretty successful path to a happy retirement.

Sam Falco: [07:41] It can be. Although I will tell you, um, tell you a little story about, I live in Pinellas County, Florida, and about the emergency response system. Um, I think it was probably about 25 years ago before I actually moved here. There was a case where a kid got hit on a highway and part of his body fell in the County. And part of it fell in a municipality and he died because no one could figure out who needed to transport him to the hospital. And what, but what came out of that was a countywide EMS system that is pretty robust. It wins awards. They do, um, EMT competitions, uh, and Pinellas County wins that a lot, essentially if you’re going to be in an accident or have a heart attack and you want to survive it, try to have that happen in Pinellas County,

Dan Neumann: [08:33] Get dragged over there.

Sam Falco: [08:34] That’s a, that’s a great chamber of commerce slogan. I think if you’re good, if you’re going to get hurt, come here .

Dan Neumann: [08:42] Come here just in case.

Sam Falco: [08:44] There was innovation and there was constant innovation. I took a public citizens course where they, they take you to the various things and learned how they had created system. And it is constant inspection and adaptation. If we position ambulances in this way, will that give us better response times? Yes/No. Um, how, how can we get people help as quickly as possible?

Dan Neumann: [09:08] No, that’s yeah. Yeah. And there are some, some places of innovation. And then at times there are some of those where yeah. Innovation hasn’t come by for a few years, but let’s get back to sneering about other people’s agile. Right. So, um, I think there are titles in organizations that will also kind of trick well, for me, admittedly resource is a trigger, but I read through the same job description. I saw something about resource management and I was like, uh, but there were parts in there that were positive, protect the team from interruptions, uh, coach them to constantly align with program standards. Um, it drive continuous improvement within the team with focus on agile principles. So like, there’s a, there’s a lot of good stuff in there. Um, we can play a game of find the job post.

Sam Falco: [10:02] Well, you know, the term resources. Yeah. It, I often am triggered by that term. Myself. A resource is something that gets consumed to me. Um, I’m, I’m even more horrified by, I see people using the term human capital management like, Oh, capital is livestock. No, thank you. Let’s go back to resources. People in business have been calling people resources for decades. It’s not something you change overnight. So just seeing that and going, Oh, well they must suck. No, that’s, that’s crazy. Once again, you gotta find out what is the culture actually like and see, yeah. See where, where they go with that. I must admit when I first joined AgileThought I was working with a client and someone on the client team referred to resources. I was very sharp about saying, we call them people. Now it worked in that case, this was someone who took that to heart, but it was, I should have been a lot more gentle with that and, and, uh, versed in a different manner because he, he didn’t know what my meaning of the word was. And I didn’t know what his meaning of the word was. So I made some bad assumptions and, uh, jumped to a conclusion. It, it worked out okay. But there was a case where I could have done a better job of asking someone when you say that, what are you thinking?

Dan Neumann: [11:29] And I think that, so what does one, do you know? Uh, there are degrees of planning that I think can be unhelpful when we’re trying to forecast things out and expect that if everything goes right, we’ll hit this, hit this target. Uh, and with agility, zero planning is also a strategy for failure. So simply creating a release plan or creating a project plan or, you know, whatever it, isn’t a pass, fail test for agility. And I think that’s another place where I see, um, you know, people kind of looking down their nose. Well, that’s, that’s not the planning I would do. What’s the context of the work? How well known is it, how knowable is it?

Sam Falco: [12:10]
Right, right. I think, um, here’s an idea that agility is a binary state. We either are, or you are not agile. And that’s, I see that from organizations who are, we’re going to have our transformation complete in three years, I often hear that three years thrown around, uh, as a target, we’re going to be agile by then and we’ll be done. But I also see it on the part of some people who should know better in the agile community, where they will say that’s not agile. Well, is it valuing individuals on our actions over processes and tools? That’s the question we want to have. And agility is more of a continuum I think.

Dan Neumann: [13:12] In some of our essentials classes that we do at agile thought, one of the icebreaker activities is asking people to kind of align themselves on a spectrum from related to their comfort. So how comfortable are you on individuals and interactions, to processes and tools running the thing, and people line up there and it’s the processes and people are comfortable with processes and tools. It doesn’t mean they’re not agile. It just means that they’re comfortable with those things. And that helps us know how to coach each of those individuals.

Sam Falco: [13:45] Yeah. Yeah. And I’ll hear, people will say, no, I really need a process. Anyway, if you dig into that a little bit, you find out maybe what they’re doing, the work is more knowable. So a process is maybe appropriate, or they just have some fear that they’re going to be slapped if they don’t follow at least following processes to see if they can say, Hey, it didn’t work, but I did what it says. And maybe they need to be moved or help to feel more comfortable. Maybe there’s an organizational problem where all right, we need to stop the behavior that’s leading people to fear making a mistake or fear reaching out. One of the things I noticed early in my agile career was in the principles behind the manifesto. One of the lines, continuous attention to technical excellence and good design enhances agility. That suggests to me that it is not only not binary, but it is not something you ever arrive at. It is sort of an asymptomatic curve. Like the faster you go, the more energy it takes to go faster and you’ll never reach light speed. The more agile you get, the more, the harder it is to actually be more agile, but it’s never something that you are. I am now agile. I am the Nadia Comaneci of, of the business world showing my age, that’s the gymnast that comes to mind for me.

Dan Neumann: [15:12] I think that, I think, uh, yeah, she’s probably pushing the stroller around there. A stroller probably she’s gone past stroller. She’s probably in a chair. I’m going to Google that later. Another thing. So, yeah. Um, I kind of vividly remember coaching a team quite a while ago now, years. And we had, we had the agile naysayer in the group. Agile is not going to work agile doesn’t work, et cetera. And one of the activities we did, uh, because we also had the person on the team who was saying, ah, we, we absolutely need a lot of documentation. So we did, uh, an, uh, a journey line exercise, and we had people take their, their professional timeline. And, and, uh, so from long ago to today and the plot line of the high points and the low points in what was happening in there for them personally or professionally, and the, the, the agile naysayer around, uh, the technical side, he was at a place where their product was deployed basically for big cities. And anytime they had a bug, they had to go fix it for California and they had to go fix it for San Francisco, they go fix it for Miami. I’m like, Oh my God, there was no technical excellence. They were doing copy-paste bug fixes for all these. I’m like, okay, that doesn’t sound like what I would think of a good agile team from a technical excellence standpoint. Can we agree not to do crap engineering? Okay. There we go. Addressed. And the person who had a strong bent towards, we need to document everything came from a strongly regulated background. You had to document because an auditor was going to climb up your nether regions and give you an exam. And if you didn’t have your documentation in order, you were going to fail and it was going to be uncomfortable. Okay. We’re not in that world now. So how do we strike the balance of how much documentation, but yeah, it’s not a pass fail and, and, you know, agile gets used for all kinds of stuff. Sometimes it’s actually used to describe agile and sometimes it’s not. Yeah. Yeah.

Sam Falco: [17:24] Yeah. And I think you’ll hear this phrase. Oh, you purists, usually from someone who has been abused by agile, uh, been, been told, Oh, that’s not agile. And they get really ticked off. I had a director of engineering at one place I worked to kept saying, don’t tell me the answer from the book. And at first I took that to mean, I don’t want to know. I don’t care what it says in the Scrum guide. I’m going to do whatever I want. But what I later learned was it’s fine to tell me what the Scrum guide says, but you better be able to tell me why you better show me how it’s supposed to work. And if I tell you, I’m not getting value out of doing that, don’t tell me I have to do it because it’s in the Scrum guide. And once I understood that I had a much better ability to work with him and understand where he was coming from. And it turned out that some of the things that some teams were doing really Scrum wasn’t right for them. So don’t force them to do Scrum.

Dan Neumann: [18:19] Yeah. I, the episode immediately prior to this was with Johanna Rothman and the moniker she uses is the pragmatic programmer. And when we pulled on that, I will encourage people to go listen to the whole episode, because she’s one of my favorites. Like, of course you are too Sam. I mean, you’re, you’re just close second. But she, she, um, she describes herself as a pragmatic programmer because it is grounded in theory. And at the same time it better work. So when the theory doesn’t work, let’s find something pragmatic. Maybe it’s Scrum. Maybe it’s not, maybe it’s not agile, but let’s find something that works.

Sam Falco: [19:04] Right. Right. Yeah. I had a Product Owner who was not particularly thrilled with Scrum. You’ve been told you’re going to be the product owner because he was the person most qualified for it. And one of the first things he said, when we met for the first meeting of him and the developers who were going to work on it. And me, it was a, it was a complete Greenfield project. And he said, you agile, people always say waterfall doesn’t work. And I am here to tell you that I have seen it work. And I said, I believe you, because I won’t tell you that it won’t work. I will tell you that it can be really costly. And maybe there’s a better way. And we got along famously as a result of that. He was someone who had worked in some pretty big waterfall projects at Microsoft back in the mid-nineties. He’d seen waterfall work, but yeah, when we got into it, I’m like how much money were they throwing at this and how painful was it?

Dan Neumann: [20:01] Yeah. Okay. Well, in my first decade out of college was in a consultancy. I started off slinging C plus plus code and ended up, uh, doing project management and engagement management, but we did pretty okay. You know, we’re doing waterfall projects, requirement specs. Uh, we did the guessing game at the request for proposals, or like based on the three paragraphs, we think it’s a, you know, a 10 person team for a year. Can we have some money now? But, uh, that company is still in existence. They’re still making money. Um, I think we’re pretty darn good at delivering value for our customers. And it happened to all be waterfall. Very rigorous CMMI waterfall. Yeah.

Sam Falco: [20:50] Agile has oodles of benefits. Um, waterfall has its place in where you have a lot more, um, ability to predict requirements and ability to understand how you’re going to get there.

Dan Neumann: [21:07]
And I think some time to get there too. I mean, a lot of those efforts were year long efforts where we didn’t deliver any single increment. It was a 12 to 18 months. You’ll get a thing. And it was fine for the, you know, late nineties.

Sam Falco: [21:20] I’m specifically thinking of the Stacey charts. Maybe we can put a copy of that in the show notes, uh, by Ralph Stacey created and he was talking about management styles, but the two axes are, uh, how certain are you about the requirements and how, or how much agreement is there about the requirements, how certain are you about the technology to be used? And the closer you get to the inner part of those together, those are mapped to the kineffin domains as well. So if you really have a close understanding of the requirements and agreement on the requirements, and you really understand the technology, that’s a simple domain or obvious domain problem, you don’t want to use Scrum for that. You don’t want to, you don’t need to use an empirical process. You can predict that. We have, I always use the example of an oil change, right? When I go take my car to the mechanic, to have an oil, have the oil changed on, he can tell me exactly how long it’s gonna take when it come pick my car up. Um, if you move a little out on that, then we get into the complicated domain where this may be a few more unknowns. We have to do some, some planning, but like construction. We’ve been building houses for centuries millennia, almost. We have a lot of data and a lot of predictability around that. Would you use Scrum for that? That’s probably overkill. Where Scrum or agile in general works is when we really, the requirements aren’t predictable. We don’t know if we can actually have the technology exists, or if we’re going to be able to build it, then we need to iterate towards things.

Dan Neumann: [22:57] In the automotive example for iterating towards things that comes to mind for me know that the name is escaping me, we’ll, we’ll play a game of see if we can remember it here. Uh, it was using Scrum towards the automotive X prize to get an automobile that, to go a hundred miles to the gallon. And I know that car was at one of the agile conferences a couple of years ago, and they’re iterating on it. They, Hey, what, you know, if your team has a new body design, you know, spin it up, plop it on there, and let’s see how things go. If you want to. Wiki speed. Speed, speed. Yes. Hive mind. Uh, and so yeah, we know how to do oil changes. You typically Scrum wouldn’t be used there. We don’t know how to make a street legal car that gets that much efficiency out of a gallon of gas. So lets iterate and use empiricism.

Sam Falco: [23:47] Yeah. And if you’re interested in looking into that wikispeed.org is where you can find out some information about that. I was just looking at that about three days ago, so nice coincidence.

Dan Neumann: [23:58] Fascinating project. Yeah, yeah, yeah. If, uh, I don’t know. I guess it was high enough on my list of interest. I’d do something about it, but it’s just kind of like, it’s, it’s cool. And I like knowing about it, but I’ve not

Sam Falco: [24:11] Had some insomnia the other night. So that’s where I ended up.

Dan Neumann: [24:16] Uh, I think I ended up watching a series on world war one when I had my insomnia recently and I, and I got drawn into it. Um, I think there’s something relevant here. Uh, it was.

Sam Falco: [24:28]
I guess we’ve moved into the, how are you, uh, doing journey?

Dan Neumann: [24:33] Um, what was interesting for me is just the number of poor decisions that go into something like that. Uh, you know, it’s not one poor decision, you know, you hear about the DSS and nation of Archduke Ferdinand? Yeah. Yeah. That was a thing. But that, wasn’t what started it. And just like the sinking of the Lusitania for the U S that wasn’t what triggered us to get into the war. It was when Charlie said, Hey, Mexico, why don’t you go take Texas back? That’s when the U S was like, all right. All right. We’ve had, um, tying it back to this agile conversation. I think there’s a lot of stuff about World War One that I thought I knew. And I think there’s a lot of stuff about agile that people think they know. And th there’s, it’s much more complex than that. And so, absolutely curious and trying to get that. I pull it back in?

Sam Falco: [25:20] I think you did a fabulous job. I think curiosity is a key characteristic of anybody who wants to succeed in agile. Uh, how could things be different, low tolerance for, for impediments and low tolerance for the idea that we can’t change things. We have to do it this way.

Dan Neumann: [25:45] I like the question, how could we do it? Or how could it be different? And it’s an expanding question instead of we can’t because.

Sam Falco: [25:55] Yeah. What would happen if there’s another question, uh, what would happen? We took this piece out the helps. It’s fascinating to me to watch my dad problem solve. He was an electrician for many years, and then he managed engineering for hotels for a long time. But when something breaks, he will, he will just stare at it across his arms and stare at it and say, why or why does that not work? And he’ll just start looking at components. And he is taking a very empirical approach to, to this. What does that component do? What if I pull it here until, ah, here’s the problem? And then we solve it. Now, those are mechanical problems. Those are not technically things that are best solved by agile, but the mindsets there of experimenting. What don’t I know, not just assume, Oh, I know, I know how to fix this. I know what the problem is. What don’t I know about this system? What can I do to troubleshoot it?

Dan Neumann: [26:52] Yeah. Um, and then sometimes you have to take it to an expert, you know, and that’s, I think where the agile coaching with, from an outside party can come in, Hey, we’ve tried this agile thing. It hurts. Um, my, my son drives a 2001 Chrysler Sebring because he was 16 when we got it for him and it was cheap and the top goes down. So that’s kind of fun, but a 20 year old cars also not mechanically reliable all the time. Right. And so, uh, we did, we had something going on. The battery would die within a week. So we had to take it to the expert and be like, ah, we’ve tried what we know to get the car to run properly. Help. And I don’t know it, they tried one thing and they were actually wrong about that, but it didn’t cost much. So we took it back again and they found the root cause and they fixed it. And so I see that with agile teams too. Hey, we’re doing well, we’re doing agile air quotes. You can’t see that because we’re only releasing audio. We’re doing Scrum and we’re not getting the results we want help. Right. Then having some outside perspective on that can be super valuable. Well, cool. If people have a favorite job description, they want us to pick apart. They could send it to us at podcast@agilethought.com.

Sam Falco: [28:08] It’s funny when you raise this, I thought, you know, I’m guilty of that, myself of seeing job descriptions that I said this jokingly one time that I wanted to apply for this job, not because I wanted the job because I wanted to go in and tell them how they were doing it wrong. And that is an example of that. I know better about your culture than you do. And maybe we should all have some humility recognize that we don’t know what’s going on on the other side. And if you want to make the assumption that, well, that would be a bad fit for you. That’s fine. But if you want to make an assumption that those are horrible people, and they’re not agile, you’re stepping over a line there.

Dan Neumann: [28:46] Well put. Let’s explore continuous learning journeys.

Sam Falco: [28:51] Well, I’m still working through discover to deliver that. I mentioned when we recorded last week. So, uh, I’m, I’m, I’m not much farther to be honest, I’ve been, I’ve been pretty busy. Um, how about you?

Dan Neumann: [29:05] I have a three book backlog at this point. Thanks, actually, to Johanna Rothman. Um, yeah, so I just, um, there, I don’t think they’re on audio book at this point. And so I will have to find some time to actually sit down and read.

Sam Falco: [29:31] That’s horrible for you.

Dan Neumann: [29:33] You don’t know half of that.

Sam Falco: [29:37] I can’t use audio books. I, if someone’s reading to me, I go back to I’m three years old and bang I’m out like a light. Even if it’s something I’m fascinated by I, and I can process by reading with my eyes. I don’t want to get into the whole argument. Is audio book listening the same as reading, but I process visually so much faster than I do audio. I am always like, Oh, it’s, you should watch this as your transcript. I can absorb it for, you know, I very rarely watch like political speeches because I can read it the next day. And I can read it in about five minutes instead of watching 25 minutes of people talking.

Dan Neumann: [30:19] Oh, interesting. Uh, so modern management made easy is the three book series, a practical ways to lead an innovative organization is the last one before that is practical ways to lead and serve slash manage others. And then it starts with practical ways to manage yourself. And so she really does encourage people to start with you. Yeah. Go on to others. And then organizations. So many people want to jump in an organization, but I don’t want to beat that horse because just go listen to the previous podcast. So, um, I have to consume that and, uh, hopefully we’ll have some additional lessons. And, uh, at some point you have Johanna back with the next books that she references that she’s writing at this point. So yes. Thanks for joining Sam and joining this agile thing again.

Outro: [31:08] 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 and 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