Joining an Agile Journey in the Middle

Podcast Ep. 136: Joining an Agile Journey in the Middle with Sam Falco and Adam Ulery

Joining an Agile Journey in the Middle
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

Most literature around starting an agile (or Scrum) team makes the assumption that you will be starting from scratch. But oftentimes, you’re joining an organization with teams that are in the middle of a half-built or fully-built product.

As an agile coach being brought into an organization, you usually have to work with pre-existing teams that are in the middle of their product life cycle with pre-existing behaviors and norms.

In this episode, Dan and Sam are exploring what it is actually like starting in the middle of an agile journey and offer their tips and advice for agile coaches in addressing common challenges associated with pre-formed teams, products in the middle of their life cycle, and organizations already in the middle of their agile journey.


Listen on Apple Podcasts

Key Takeaways

  • The different ways you can be “in the middle”:
    • In the middle of an agile journey
    • In the middle of team formation (or by working with an already fully-formed team)
    • In the middle of building a product
    • A combination of all three
  • Addressing challenges of joining a team that is in the middle:
    • There needs to be a mindset shift around the whole team being accountable (rather than each individual for themselves)
    • When a team already has its behaviors and norms established, they can be nervous with new roles and expectations being introduced
    • It is important to respect the team’s history and knowledge
    • Scrum doesn’t say “abandon your job titles,” rather, “You work out how you want your team to look. As long as you can get to done.” (i.e. it’s okay to stick with your original job titles as long as you remember that you’re all in this together as a team; not individuals)
    • Those in senior positions (i.e. those with more expertise and experience) should shift into a mentorship role for those junior to them 
    • Recognize that the team is going to have to take smaller bites at the apple every Sprint instead of taking on these huge challenges that will take months
    • Create safety by delivering in smaller chunks
    • Do regression testing more often
    • Slow down and automate the old stuff
  • Addressing challenges of a product life cycle that is in the middle:
    • Sometimes, adding value to the product might be in removing features that nobody (or few people) use, that are slowing down the delivery of new features that people will use
    • If it’s expensive and not giving your team/organization a return on investment, reevaluation should take place around why you are spending money to maintain this feature
    • Look at value investments from a product standpoint even when you’re not starting a new product from scratch
    • A challenge with jumping into products in the middle is that the strategy has been laid out in a fairly plan-driven way (the requirements are largely thought to be understood)
    • “Scope creep” isn’t actually a monster; it’s a friend that helps you have a better understanding of your requirements
    • Bring users in earlier and ask for feedback earlier (this helps get users engaged, interested; you’re able to correct course mid-flight to create something that users actually want)
    • You don’t have to wait until a Sprint to adjust
  • Addressing challenges of joining an organization that is in the middle of its agile journey
    • This usually takes the form of A) the organization has tried to do an agile transformation themselves and now recognize they need help, or B) they had a consultant or coach come in previously, dismissed them when they thought they were done, everything went off the rails, and now they need to bring in another consultant once again to fix it
    • “[Agile is] a journey; not a destination. So we have to continue going [forward]. I think it’s actually a misnomer to say that we, [as agile coaches], come in in the middle of an agile journey. It’s all middle. Once you take that first step, it’s ‘middle’ for the rest of time.”
    • Agile journeys take a long time; there’s not a magic want to shift behavior
    • The organization needs to learn how to do the learning because it never stops
    • Adam Ulery’s tips for being brought into an organization “in the middle”:
      • First, understand where the organization is right now
      • What do they do really well right now? Where are the gaps that need to be addressed? 
      • Conduct an assessment (doesn’t need to be formal) to understand their current challenges
      • What are their goals? Their business goals, their agile journey goals, and where they would like to be in the not-so-distant future (i.e. six months to three years)? Based on this, develop a plan on how to move forward with them

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 by Sam Falco principles trainer and professional Scrum trainer from Scrum.org. How you doing Sam?

Sam Falco: [00:29] I am doing great. How are you?

Dan Neumann: [00:32] Wonderful, wonderful. We, uh, we have, we have a topic that I hope people find interesting today.

Sam Falco: [00:39] Absolutely. A lot of literature, actually, almost all of the literature you see on starting an agile team or starting Scrum teams or whatever makes the assumption that you’re starting from scratch. That’s a Greenfield and you can spin up some teams and things will be wonderful. And I’ve never had that experience coming into an organization. I have spun up new teams, but always when there was already a lot of work in flight, uh, we are attempting to now apply agile ways of working to an organization that is well steeped in other ways, and on a product that is often already half-built or well along the way to being built or even fully built and just being continually improved with an earlier mindset in play.

Dan Neumann: [01:39] Yeah, I think, uh, I think I’ve seen situations like that as well. Sometimes. Like there’s lots of different starting in the middle, which is kind of going to be the theme of our, of our discussion here today. It might be there in the middle of some agile journey already. You know, they’ve done some things they are, um, you know, not at the beginning, not at the end, the team that we start to interact with is not a new team. They’ve been together, maybe constituted as functional teams versus cross-functional teams. The product you said might be planned and now we’re coming in to help quote, iterate through the requirements or something in those lines. So it’s way more flavors of middle than I think of. Okay. We, how would we like to do this project in an agile way? How do you like to form a team? How do you like to kick them off in a really nice, clean, nimble way? And often it’s we’re in the muddy middle right out of the gate.

Sam Falco: [02:42]
Yeah. My, my first foray into agile fits into the second category you named where the team has already been together for a long time. The team that I was working with, I was a QA team lead at the time. And we’d been together for years already. And our company was acquired. The new company said, oh, we do this thing called Scrum. And we got some training. Well, one person got training and here we’re doing Scrum now. And for us, it actually made things a lot easier because we already had all of the team dynamic stuff out of the way. We did have some new struggles as how do we adapt to the fact that it’s the whole team, that’s accountable, not I got my stuff done. And what is this new Scrum master person doing? And that was me, uh, still at the same time functioning as the QA person. And at first that was the biggest challenge was we were still functioning in that mode of developers do their thing. And then they hand it off to QA and they would have a code freeze three days before the end of the sprint and then be doing whatever they thought they needed to be doing until then I would find the bugs and then they would turn around and start fixing those not the best way and not certainly the way we coach teams when we’re starting.

Dan Neumann: [04:08] So I’m fascinated. I believe the order was talking about middle of an agile journey, middle of teams together, middle of product. And you went for the middle of the middles, which was the team for me, that was clever whether you did it or not, I should do it on purpose.

Sam Falco: [04:23] But you’ll also notice all three elements are actually in play there. The product was in progress. Um, well, no, actually the first one isn’t no, not really. We were, we were a team, but we were heavily very much waterfall. It was just I think, joined in the middle of this other company, agile journey. So maybe, maybe I’ve got it all worked out in there.

Dan Neumann: [04:49] See how many middles we can get in. Okay, well we’ll stop the middle part. Uh, but your you’ve got the team and it’s God, it’s behaviors, it’s norms. And now there’s new roles that are getting introduced. There are new expectations of behavior code freeze. Just the phrase makes my toes curl because we’re because it’s not safe to change it anymore. That’s why you have to freeze it. And change is scary. So that’s just a bad smell all the way around.

Sam Falco: [05:25] Right. But we were trying to shrink waterfall down into a sprint. Well, because we knew how to do that. I mean, it was causing us problems, but we just thought that, oh, okay. So now what we do is the developers do their thing. And then they finish and hand it off to the QA, which is you can do it that way. It will not help you in the long run. You’ll need to learn some new things. And when we come in and we start a team, we encourage them not to do things like that. But if that’s an already entrenched behavior, that’s a problem. And then as you said, there’s, there’s new roles, but there’s also a, an almost shrinking of roles because Scrum doesn’t care about role names within the developers. It doesn’t care that you’re a senior architect and I’m a QA team lead and you’re a junior developer. It just says, developers work together and get it done. You’re all accountable together. And that can be threatening. So while the team that I was on did fairly well, we did struggle. And there was one person who really resisted the idea because I worked really hard. He thought to become a senior developer. And now you’re telling me that that doesn’t mean anything. And he had worked very hard and it did still mean something, but to Scrum it didn’t. And we had to deal with the fact that he was very much in the mode of, he tells people how to do things and sits back.

Dan Neumann: [06:51]
Let’s talk about some alternatives. Then for folks who are diving into a middle, there are the entrenched roles. Somebody who has worked very hard to accumulate knowledge and expertise over the years, they’ve maybe got a proven track record, hopefully of successful delivery if you’re a senior, but they’ve done it in a very particular way, which might look a lot like I control things. I review the pull requests. I will tell you what the structure is that you’re going to do. I will review I, whatever. So it’s the, the hero approach, uh, and that manifests itself in QA, um, all kinds of specialists end up with that authority based on seniority. So maybe we can share some, some tactics or some ways of working through that, not in a manipulative way, but in a way of trying to help the team get to a better, more nimble spot.

Sam Falco: [07:47] Well, I think the first is to respect that knowledge, respect that history. Yes, you have a lot of knowledge. And the fact that the entire team is responsible for delivering a done increment every sprint doesn’t mean that people can’t do a little bit of specialization within the team. So some of that behavior will, can stay the same, but we want to diffuse the knowledge out. And Scrum, doesn’t say, abandon your job titles. It just says, as far as we’re concerned for Scrum team, it’s just developers. You work out how you want that to look as long as you can get to done by the end of the sprint. So it’s okay to stick with your job titles, as long as you remember that. Now the difference is it’s not, we’re going to be successful if everybody does what I say, but we’re going to be successful. If we all figure it out together, I think that’s an easier transition, although not by itself, easy, but it’s easier than, okay. You used to be a developer. You used to be an architect. Now you’re just developer, which is the way it’s often presented. Now you’re just a developer. Like it’s a demotion. It’s not a demotion. It’s simply a shift in the way we think about our relationship to our peers. If that makes sense.

Dan Neumann: [09:11] So thinking through thinking through that a little bit, the relationship to the peers part, right? So it’s not, I am a senior. I am going to be the all-powerful for anybody who’s below me and supporting it to anybody who’s above me. Uh, but you’re now talking about how can that person with more expertise, more, you know, more time on the job, potentially engage with other people who are also extremely capable, but don’t have that same title, other people with different roles and, and come together to create that working increment, to deliver that product and deliver value on a, on a frequent basis.

Sam Falco: [09:54] So if you’re that senior person, you should already have been mentoring, probably people who are junior to you, but that becomes so much more important because we need to have a breadth of understanding on the team as well as depth. So my dad used to tell a story. He was a master electrician before he got into engineering management in the hotel industry. And he, one of the things he loved doing was mentoring young electricians on the job site. So when he was a member of the IDEW international brotherhood of electrical workers, he was often the one that they sent the apprentices to go work with Sal. And he liked sharing what he had learned so that they could get good at the job because it made everybody’s life easier if people were doing things the right way.

Dan Neumann: [10:50] You should probably have him on one day.

Sam Falco: [10:51] I think I would love to have my dad on the show.

Dan Neumann: [11:02] So there’s, there’s the people side. Are they interested in mentoring? Are they willing to, does the organization support the mentoring? And then there’s also, how do we create safety for change to be made for people to step outside of what maybe before was narrowly defined roles. If it’s not safe for somebody to touch the code, we have a problem. If we need to freeze it so we can manually inspect it or so that we can manually validate it, that’s all expensive, slow, and ain’t going to scale well at all.

Sam Falco: [11:35] Right. So I think we, we also have to recognize that we’re going to have to take smaller bites at the apple, every sprint, instead of these enormous, you know, taking on enormous challenges that will take months. And this is often also difficult for people to get their minds around. What do you mean? I’m, I’m building a small piece. I don’t understand how to build a small piece. Even senior folks will struggle with that because they’ve never done it that way before. So we have to make some space for that. This is where if you’re using Scrum again, a good Scrum master would, help teams understand the limits of what they can do and operate within those and take on very much smaller challenges work with the product owner. Unexperienced product owner can be very helpful here too, because they can say, well, here is a tiny feature that I would like to say, let’s just work on that. So it takes the entire team collaborating on how are we going to change the way we’re viewing what we’re putting together.

Dan Neumann: [12:41] Yes. Thinking through creating safety, by delivering small chunks. And one of the related to that concern of, of safety is, oh, but now I have to go look at the other thing. The, the thin slice that I delivered, because now I made it a little thicker, well, shoot, I have to go regress the whole thing. And that’s where actually investing in automation because those humans don’t scale because you’ve touched something that was working. And in my waterfall days, you didn’t touch something that was working. If you could avoid it. We can’t touch it now.

Sam Falco: [13:16] Right. And with the iterative delivery. So yes, you have to do regression testing more often. Whereas before in a waterfall world, you finished development and now you’ve got weeks, months, however long you have allotted for regression testing. And if you’re lucky, you haven’t squeezed that time by delivery being late. That’s a separate conversation, but let’s assume you have the amount of time, but it’s a long process. So my first Scrum team, when we first started, we, we already had quite a code base in place and regressing, all of that was already a huge problem. And we had to do a lot of changing the way we thought about regression testing too. And none of it was automated. So part of our effort became how do we start automating these things? And that immediately came to full stop. Again, how do we, how do we automate everything? Well, we don’t, we automate a little bit and just automating, you know, the app starting so that I didn’t have to manually start it. When I did my testing, uh, was one way we went with and very slowly built that the problem was we were adding features faster than we could automate because we really didn’t think about maybe we should be automating more backlog stuff, uh, not in the product backlog, but existing functionality. Um, so we were trying to automate the new stuff, but not slowing down to automate the old stuff.

Dan Neumann: [14:50]
And that’s a legitimate strategy in which is let’s just put a stake in the ground for where we’re going forward. A new definition of done, if you will, or a new team norm that says, maybe it’s just some modest level of unit test coverage and some automated functional tests that will at least blow up in the basic scenario. If we break it badly or we’ll tell us if the API, all of a sudden has stopped returning anything or something. I think of it as the Canary in the coal mine test, you know, it’s, it’s not everything, but it’s sure better than nothing. Right? And one of the things that we did come to, one of the strategies we did come to was to try and order the product backlog so that we were doing a lot of things that were in the same area of the code. It was not as tied to value as the product owner would have liked, but we made a strong case that if we do that, we can also in each sprint automate more of the tests because we’re going to be looking in that code. We can add PBI’s into our sprint that are specifically about automating the testing for the existing functionality. And in the long run, we will go faster. Fortunately, we had a product owner who was willing to do that, and that did help.

Dan Neumann: [16:28] And that brings us to roughly the middle of the podcast. And so let’s, let’s pull on that product middle just a little bit. Uh, wait, which you, you were giving a nod to it, which is, Hey, we’ve got a product backlog and it isn’t the ultimate as far as ordered, strictly for value. And we’re delivering, you know, a piece over here and a piece over there and the thing in the middle, but for now there’s we could go through it this way, the way you described, Hey, similar functionality nearby adding some automation, because you’re not doing as much context switching, hopping around. And that’s a legitimate strategy for, you know, acknowledging kind of where an or where a product is in its life cycle.

Sam Falco: [17:13] Right. You’ve got a lot of architecture. Maybe you don’t even have testing in place for all of it. Um, maybe some of it is so old. You have no idea even what’s going on under there. You’ve probably got a lot of features that you’ve built because someone asked for that feature, but we don’t have any data around whether it was actually valuable to build and whether people are using it. So what do we do? Do we drive around it? There’s a lot of decisions to be made a lot to be thinking about as you move forward with that. And so sometimes adding value to the product might be removing features that nobody or a few people are using, but that are slowing down the delivery of new features that people will use.

Dan Neumann: [17:58] It’s a powerful tool in a really tricky one, too, to do that, or remove things of the millions of transactions, a few thousand look like this, do we really need those? Could we have a better product with that? Yeah. You’re going to annoy, whoever’s consuming those. Maybe if they actually care about what’s going through there, but it’s so powerful to say that thing’s expensive and not providing tremendous value, it’s dead. It’s dead to us.

Sam Falco: [18:28] Right. And I think that’s the way you have to look at it the way you said that this is expensive and it’s not giving us the return on investment that we would like, do you want to keep spending this much money to maintain? Let’s just, let’s say, you know, 10,000 transactions a month when we do a million and those aren’t bringing in very much revenue, can we kill those? Can we, can we get the customer who’s using that? Or the customers who are using that on to the newer functionality and newer platform? Can they not run their transactions that way?

Dan Neumann: [19:04] And maybe it’s not this version, but it could be next version. You know, there are, um, you know, Microsoft does this with, as far as I know, lots and lots of their products suites where it’s like, Hey, this thing, by the way, heads up in this version, we’re giving you a warning that it’s going to be deprecated in the future. Next version, maybe it actually is. So a transition time, you don’t just absolutely pull the rug out from somebody. So looking at those kinds of value investments from a product standpoint is valuable even when you’re not starting a new product from scratch. One of the challenges I see as well with jumping into products in the middle is often the, the strategy has been laid out in a fairly plan-driven the way, okay, we’re going to figure out what we want upfront. Where are we going to iterate through it in air quotes, Scrum, um, maybe delivering increments, maybe not so much, um, hopefully some increments, but still the, the requirements are largely thought to be understood. The customer needs understood air quotes understood. And now we just have to drive to the working software that meets all those needs and then the hardening afterwards, or the user acceptance testing. And so it’s, it’s fragile, even though it’s being done with some elements of Scrum framework.

Sam Falco: [20:26] Because what we often find in that lengthy user acceptance testing period, is we didn’t understand the requirements very well at all. Uh, and they, the customer didn’t understand what they were asking for very well at all. So that’s a challenge because people’s egos are invested in, we’ve already analyzed the requirements. We’ve gathered them. We’ve analyzed them. They’re fine. But what you, what you get, if you scratch the surface a little bit, someone will utter the phrase scope creep. They’ll say we have to guard against scope creep. One company. I turned around on the whiteboard and I drew this little doodle of a monster, uh, and called it the scope creep. But, um, I wish I took it. It looks cute. Yeah. But the point is when that phrase is uttered, that’s the opportunity to say, see, the thing that you’re calling scope creep is learning. It’s better understanding of your requirements and it’s not actually a monster. It’s your friend. It will help you. I’m really starting to sound like this is a Maurice Sendak book.

Dan Neumann: [21:39] Are we in like an afterschool special from back in Where the Wild Things Are? Gotcha. Yeah, that’s familiar. Someday I’ll read a book. Um, so scope, um, I had a wonderful interview with a Scrum master candidate and we had a chance to explore, uh, just that topic during the interview, which was, what’s the difference between what we would call scope creep in a waterfall world and air quotes, scope creep in a Scrum world. What, what do you need to control? What is merely interesting and information? Uh, is it bad? Is it learning? It, it was a pretty fun, a fun conversation. So, you know, I don’t know if anybody listening here applies for, into the open agile positions we have, David just might get to chance to explore that. So there’s maybe the question might be being a podcast.

Sam Falco: [22:39] Maybe we make being a podcast guest part of the episode, part of the interview process.

Dan Neumann: [22:44] Your interview will be on the podcast. I just clicked record. Let’s go, oh, I would scare away some people that would be interesting.

Dan Neumann: [22:55] Let’s focus, we’re getting off of it. So we’re just going to do that. Cause that might just attract people like microphones and there’s, there’s already a couple of those here.

Sam Falco: [23:02]
Two of them on this podcast.

Dan Neumann: [23:04] That’s what I was thinking. So scope creep and the difference between learning and something that’s viewed as bad. And sometimes learning is painful. Oh shoot, we missed something big and it hurts to address it. But by golly, it’s better early than later. So what’s the strategy for bringing some of that forward. Again, joining a product in the middle of its life cycle, knowing that on the horizon, there is some big, scary stuff to try to understand some unknowns like user acceptance, will they accept it? That’s kind of scary, right? Bringing users in earlier is of course I say, it’s an easy strategy. It’s in some respects, it’s easy in some respects, it’s difficult because people have demands on their time. But as you do smaller and smaller pieces, it’s less onerous for people to come in and take a look at what you built so far. And so one strategy at a company I was at, they would finish a PBI or thinks they were finished with it. And they would either go to the person who asked for it or ask them to come over and show it to them. And when I first proposed that they do this, they were all taken aback. That’s what the, that’s what the sprint review is for. No. Yes. Demonstrating the working increment is part of the review, but it’s not all the real, there’s nothing wrong with asking for feedback earlier. And so that helped because then the folks who were being asked, first of all, that that helped them get more engaged. They were much more interested in the product when, oh, you’re actually going to ask me what I think. So that helped. And by getting that feedback early, rather than waiting until the sprint review and finding out, no, that’s not what this customer wanted at all. Well, that allowed us to correct course in mid flight in the middle.

Dan Neumann: [25:00] That misunderstanding that the sprint review is the only place to look at. The increment is a fairly common one. Nothing that I noticed in the Scrum guide says, you can’t go to somebody and go, Hey, take a look at this. We think we might be done. What do you think ahead of the sprint review.

Sam Falco: [25:19]
Yeah. The new Scrum guide makes this very explicit. The, let me see if I can remember the quote from memory, the moment a product backlog item meets the team’s definition of done, an increment is born. That’s either exact quote or pretty darn close, but the idea is you’ve got an increment. The minute you finish one, one product backlog item, you could ship that if you sliced your stuff up well, but that idea is that it, it should be ready to go. And so going back to the user acceptance testing, instead of being a months long onerous slog, where people get the impression that their job in doing this is to find problems. And often that pops up in new requirements that, well, we found this new user acceptance testing, and then there’s the argument. Well, that’s, that’s new. That’s not part of the original scope of work. If you’re doing this continually bringing in into the sprint as much as possible. And you find that stuff out early. And when people do say, oh, I really wish that I could do this other thing that has nothing to do with what they’re testing. We can capture it and put it in the product backlog. And maybe it’s maybe it’s the next sprint, if it’s that important. So engaging with your customers, your stakeholders early is going to help with that quite a bit.

Dan Neumann: [26:36] That I think brings us to the third part, which is the beginning of the list of three things, which was, uh, so the team being in the middle and the product being in the middle, middle where the last two and the first ones, the organizations in the middle of an agile journey, potentially.

Sam Falco: [26:53] Yeah. This takes a couple of different forms that I can think of right off the top of my head. One is they’ve tried to do it on their own and they got to a point where they just can’t do it anymore and they need, they need help. And the other is where they had a consultant come in or a consulting organization come in and start them. They dismissed the consultant because they thought we transformed now or they thought they could do the rest of it themselves. And it all went to hell. And so they’ll, they need consultants to get. And the way this manifests for us is often they don’t want to go back to the original consultant for whatever reason. Um, I have heard, well, they screwed it all up, um, which is possible. It’s possible. It’s possible that, um, you know, it’s just miscommunications happen and that they had an idea that we will be transformed by such and such a date, six months, three years, whatever their thing was. And so we’re done now. And then they realized that it’s, as we all always say so much that it sounds like a trite cliche, it’s a journey, not a destination. And so we have to continue going. So I think it’s actually a misnomer to say that we come in in the middle of an agile journey. It’s all middle. Once you take that first step, it’s middle for the rest of the rest of the time.

Dan Neumann: [28:19] That is profound.

Sam Falco: [28:21] I feel Yoda like right now.

Dan Neumann: [28:23] We should just walk out now.

Sam Falco: [28:27]
Take the out of the stand and drop it.

Dan Neumann: [28:33] There was an interesting Gartner article. I believe it’s called agile in the enterprise survey and the data’s a year or two old. But one of the things that I found was really interesting in there was the rather modest percent of organizations that said they were having success with agile in their first year. And I’m a fairly impatient person. I didn’t realize maybe you still don’t fully appreciate these agile journey things take a long time. It’s a lot of change. It’s the people and the roles and the behaviors. And what does compliance look like in your organization? How do we reward people? How do decisions get made? And that’s, there’s not a magic wand to shift that behavior. It simply takes time.

Sam Falco: [29:17] As soon as you change one behavior, you find another that is affected by it. And it’s sort of like, um, I don’t know if you remember the TV show, quantum leap, where he was going back in time to, to fix something that had gone wrong. And every time he fixed something, it caused other problems. So he was never going to be done with this this process was the upshot of the season or series finale.

Dan Neumann: [29:43] I do remember that. And that’s where for us, I, as, as external consultants typically, and even for folks internally, it’s a matter of really knowing that it’s a system and changing one part is going to have an implication to another one or uncover the next opportunity. And so it’s a matter of continuing to, uh, work through those. And hopefully the organization learns to work through that independently. Yeah. That’s typically you don’t engage external consultants forever and always you hire for that hopefully. Right. But the, but the organization needs to learn how to do the learning.

Sam Falco: [30:21] Absolutely. Because it never stops. Right. As soon as you think you’ve fixed a, I’m doing air quotes, one thing, there’s something else. And maybe you come back to the thing you quote, unquote, fixed and discover that no longer works, what you put in place way back in the beginning, back before I even heard about agile, I was talking to a colleague when I belong to the American society for quality and he was retired and he had just been called by a former employer, Hey, could you come do some consulting work for us? And because things weren’t working and he went back in and they said, we’re still, we’re doing exactly what you told us. And he said, I’ve been retired for 10 years and you’re still doing exactly what I set up 10 years ago. No wonder things aren’t working that I, you know, that’s not the Bible. That’s just the way things worked then. So improve. And that was his message for them, not even an actual thing.

Dan Neumann: [31:15] Speaking of coming in, in the middle, we’re joined now by our colleague, Adam Ulery, who is, uh, an enterprise agile consultants with AgileThought.

Sam Falco: [31:25]
Adam, we were just talking about the fact that sometimes companies will be in the middle of their agile journey when we joined them. And one way that that can be expressed is when they’ve already tried to do it on their own and have discovered they really need to help. What are your thoughts?

Adam Ulery: [31:45] Yeah. I like to kind of understand where they are most of the time, because as, as we know, there can be a lot of different places that different clients find themselves. So where, where are they right now? And what have they managed to do pretty well and would like to continue doing that. And where are those gaps that we can help them with? So understand that pretty early on through some type of assessment, it doesn’t have to be a formal thing when I say assessment, but, um, an understanding of what their current challenges are. And along with that, what are their goals? You know, what are their business goals? What are their goals for their agile journey and where, where would they like to be in the not so distant future, maybe six months out from now a year from now and three years from now, it’d be real nice to know all of that. And then based on that, we can start to put a plan together about how to move forward with them.

Sam Falco: [32:58]
I like what you said about looking at what is going well, because sometimes they think that it’s all a big mess and nothing’s going well. And we can say, well, actually you at least started and you’ve taken some steps and maybe it’s not perfect, but it’s never perfect. So let’s look at what you got, that that is worth preserving. And what do you want to change? So that we start out on a positive note.

Dan Neumann: [33:24] One example of that, that I’ve encountered was an organization that their technical practices, no bueno not good at all, but the team had tremendous comradery, right? They weren’t, they weren’t at each other’s throats. It’s like, okay, let’s build on that thing. Let’s build on the whole people and interactions, part. You’re pretty good at that. So how do we leverage that good thing to address some of the things that are more growth opportunities, as they say. Adam, do you have some ways of trying to capture or talk with people about what their goals might be, what outcomes they’re trying to achieve from their agile journey? Things like that?

Adam Ulery: [34:01] Uh, yeah. I, I like to start by just having the explicit conversation because sometimes people will think about their goals. They, they never get written down. They never get articulated clearly they never get communicated. So that’s a great place to start is with a conversation about the goals and explicitly clarifying the goal. Articulating the goal, documenting it because it helps to get it out of one’s head and written down and then communicating that so others can buy into it, support it, and we can start to align that way. And I think that is related to a little teaser here.

Dan Neumann: [34:48] So you’re joining late on this one, but the next podcast, I believe is all going to be Adam. And we’re going to be talking about the difference between some of the strategy things that people would do and some of the tactical facets that people would pursue. And I think outcomes that organizations are hoping to achieve will fit very well into exploring the difference between strategic changes and tactical changes.

Adam Ulery: [35:09] Yeah, absolutely good teaser there. Dan, as you know, I’m a big fan of alignment vertically and horizontally within the organization. Goals are great about that. And what we’re talking about here is getting a good, clear understanding of what the client’s goals are, uh, or if you’re the client, what your goals are in an organization. So we can start to take steps to help achieve those.

Dan Neumann: [35:40] So thank you, Sam, for, uh, joining at the beginning and Adam for jumping in, in the middle, as we were talking, we often do with agile journeys. And I appreciate you talking about kind of some of the challenges with joining an agile journey in the middle, joining the agile teams that are already in the middle and product life cycles that are, that are in the middle. Thanks again for joining and sharing Sam, Adam, always a pleasure.

Adam Ulery: [36:05] Absolutely.

Outro: [36: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