877.514.9180Tampa | Orlando | Atlanta
Agile Blog

Podcast Ep. 16: Challenges with Large-Scale Software Delivery, with AgileThought Colleagues

large scale software delivery

Episode Description:

In this week’s episode of Agile Coaches’ Corner, Dan Neumann is joined by two of his colleagues at AgileThought — the Vice President of the Build Practice, Taylor Howard; and the Vice President of the Transform Practice, Steven Granese.

Taylor’s work with the Build Practice involves supporting the absolute best practitioners in the business — including Data Scientists, Architects, Delivery Leaders, Engineers, and Analysts with multiple technical competencies and domain experience. Taylor and his team translate business strategy into a technical roadmap, delivering cloud-first and hybrid solutions at a global scale. Steven’s work with Transform Practice is focused on organizational consulting. They help their clients figure out the right way to work, the right product to build, how to implement agile ways of working, and DevOps (i.e., how to get that software that the teams have created to the production environment and make sure it’s stable, scalable, and secure).

Today, Taylor and Steven will be discussing the challenges with large-scale software delivery and how to overcome them. With scaling comes a whole different set of challenges, so Taylor and Steven not only outline many of the challenges their clients are facing today, but also some of the challenges they’re facing internally, at AgileThought, as they scale themselves.


Listen on Google Play Music


Key Takeaways:

  • Challenges with scaling:
    • Understanding what the business outcomes are that the client is looking for
    • Aligning the stakeholders to make sure that they truly understand each other’s vision and are speaking the same language
    • Making sure that the teams are coordinated (i.e. everyone is headed towards the same goal and they’re being measured in the same way)
    • The danger of issues getting buried
    • The ways teams interact (or don’t interact) with each other
    • Getting connected to your customer
    • Making sure there’s alignment with the objective that’s to be achieved
  • How to address these challenges:
    • Implement Agile ways of working
    • Look at areas that need improvement and have active feedback cycles
    • Use data to support all the teams (to either replicate the good or improve the not-so-good), bringing them to the same level with more predictable outcomes
    • Be transparent, inspect, and adapt
    • Embrace a culture of curiosity and ask questions about the data
    • Blame the system; not the person
    • Leaders need to make sure the system is healthy so the teams have what they need and can be freed up to do what they do best — build software
    • More time needs to be spent communicating the dependencies
    • Lots of feedback loops and channels for communication
    • Be pragmatic in delivery
    • Align to the larger vision
    • Moving from an “us/them” mentality to a “we” mentality (amongst the teams)



Mentioned in this Episode:



Taylor and Steven’s Book Picks:


Like what you heard? Check out our podcast page for more episodes full of interesting discussions, agile insights, and helpful resources.



Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought, the podcast, the 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:17]  Welcome to this episode of Agile Coaches Corner. I am your host, Dan Neumann. Thank you for joining us today. We hope bring you agile topics in an approachable way, so if you have a topic you’d like to have discussed on this podcast, email it to us at Podcast@AgileThought.com or tweet it to us with the #AgileThoughtPodcast. I’m excited to have a couple of my colleagues, the vice president of the build practice, Taylor Howard and the vice president of transform Steven Granese joining us today and as usual, what you’re going to hear are the opinions of the folks participating in this conversation and not necessarily those of AgileThought or other folks or organizations. And today we’re going to be talking about challenges with large scale software delivery and how to overcome those. And as some context, AgileThought is an organization of 450 some professionals now. And so we have some scaling as well. And maybe you can talk about how we’re structured to address some of those scaling challenges. Taylor.

Taylor Howard: [01:18] Excellent. Yeah, well first Dan, thanks for having us here. Really excited to be here and to, and just for the audience, a little bit of background there, when Dan and I were talking about this, you know, getting ready, we were talking about scaling, you know, a software delivery. And during that conversation I said, look, we really got to have a, you know, my counterpart Steven Granese on this as well, because it’s a, it’s two sides of the equation. And to give a little bit of a little context and color to that, uh, the build practice, you know, that’s where we essentially do the construction of software. So you have your delivery leaders, which is like a project management role, your developers, your architects, your analysts. And so, you know, we love to build software. Um, but the other side of that is to transform, which, which Steven does. And so if we’re building something and we realize that, all right, we’ve got all of these stakeholders, maybe it’s a multinational we’re working with and uh, they’ve got, you know, different senior level team members up there that all have different perspectives on that. How do we bring together that vision? And that’s where Steven’s group does an amazing job, you know, making sure that they’re aligned so that way when it comes to build, we’re building, you know, the appropriate solution with the right outcomes and we’re measuring it. So it’s really, it’s a, it’s the two of us, you know, and, and really not us it should say, but the team members and the practices working together and there’s a nice venn diagram that overlaps that and definitely looking, uh, looking forward to getting to some of the details there and, and really Steven you’ve got to take it away on your end and, and put some more color there. I hope I did it some justice. Um, but, uh, it’s always good to work together, work together on that.

Steven Granese: [02:45] Thanks Tyler. And thanks Dan for, for this podcast and getting us together to talk about, you know, these great topics that, uh, that our industry is focused on right now. Um, and so, yeah, in the transform practice, you know, we’re focused on organizational consulting. Really. We help our, our clients, um, fair figure out what’s the right way that they should be working. And we focus on helping our clients figure out what’s the right product that they should be building. We focus on how to implement agile ways of working, agile frameworks and methods. Um, and then we focused on DevOps as well. How do we get that software that, that the teams have created? How do we get it all the way out to the production environment and make sure that it’s stable and it’s scalable and secure. Um, so those are the challenges that this industry is facing right now. And, and as Dan mentioned, when kicking off this discussion here, um, those are challenges even for a single team to overcome. Um, but it’s scale, it’s a whole different beast really. It’s a whole different set of challenges. And that’s what we want to talk about today and the challenges that our clients are facing. And at the same time, some of the challenges that we’re facing internally as we grow our own company.

Taylor Howard: [03:52] Yeah, absolutely. Um, you know, and as I, uh, as I think through some of this, it’s, it’s not just, um, you know, we’re building software, there’s a particular software outcome we want to have and we just look at the developers and architects. Sometimes that’s where the conversation initially kicks off and where we go to, but it’s really a holistic perspective, you know, we’ve got to make sure that when we’re introducing technology that that’s something that the team is comfortable with. You know, putting all the DevOps around that, operationalizing that, and ultimately handing that off, you know, to the group that’s going to own and manage that and have the full care and feeding of that. So it’s really a, it’s a product and holistic approach that we have to take. Um, so it’s everything from, you know, Steven mentioned really understanding what the business outcomes are that we’re looking for, how to align those stakeholders and make sure that we truly understand each other’s vision and that we’ve got the same language that we’re speaking from. We’re saying things where we understand, you know, if there’s, uh, a particular, uh, you know, business domain we’re in, we’ve got to understand that. So we’re speaking the same, you know, the same language and have a really good understanding of those terms that we’re working with. Then make sure that that’s all put into an appropriate, you know, structures where we can build that out with the architecture development. Then make sure that, you know, that the operations side of it, you know, is also comfortable taking that over. And then you get into all these other things like a open source technologies, containers, you know, making sure office of general counsel is even involved in some of these things. If what we’re allowed to go ahead and consume. And you can see that there’s a lot of moving parts to this and it’s really important to make sure that we’re thinking through all the angles on this as we go through it. Um, you know, to make sure that we’re, we’re taking into the appropriate considerations for, you know, that organization that we’re partnering with. Um, so no small task. And, and I think that one of the things where we really strive to, to do this, it’s say, look, as we go through these, you know, let’s employ some of these agile frameworks. They’re fantastic. Let’s not be overly prescriptive on this. Let’s know that we’re going to get, let’s get 80% of it, right? Going out the gate. Let’s go ahead and look at areas we need to improve. Let’s have those active feedback cycles and continue to evolve. And there’s all kinds of tools we can use that are often very situational based on the needs of that organization we’re working with. And not just, you know, us, AgileThought working with them, but also the other vendors. Um, you know, the other, uh, you know, influencers in that that all need to be a, you know, brought together. So there’s a lot of pieces to that and it’s, it’s very important that we’re respectful of all of those elements to bring those together to make sure we get that great outcome.

Dan Neumann: [06:26]  Yeah, you touched on quite a number of things there. Uh, so I, I’ll see if I can, can recap a couple of those things we alluded to, even with small teams, getting connected to your customer can be quite a challenge and those challenges get amplified as you have more and more teams presumably getting farther away from their customers. So getting that connectivity is challenging. And you’d also mentioned making sure that there’s alignment on what the objectives are that we’re trying to achieve. If you’ve got a program of 10 or more teams and we have a common vision, how do you make sure everybody’s aligned to that and then delivering frequently? So we have, uh, you know, the agile manifesto has a principle behind it of trying to deliver software early and continuously. We want to have valuable software in short timescales. And so those factors come up.

Taylor Howard: [07:24] Yeah, I would say to touch on that, I mean, you know, running a, running a tight sprint cycle and being really respectful of those ceremonies I think is, you know, I mean let’s start with foundations right there. You know what I mean? Um, and let’s measure ourselves, you know, on predictable velocity. Can we get to predictable velocity? You know, if we can do that at a small scale and then keep on moving up with additional teams right there and we can keep predictable velocity. Um, I think that’s a great litmus test for holding ourselves accountable to what we owe, you know, the organization that we’re partnering with and also those other groups within that larger deliverable that are dependent on us. Um, so when I say velocity, just for everyone out there to put some context to that and make sure, uh, that we’ve ever, everyone’s on the same page, that is, you know, how much work are we going to get done in a particular sprint cycle? Be that a two week or three week, whatever that cycle is, the groups agreed upon, let’s make sure that’s something that we can, we can measure, we can look at when we make changes, you know, what’s, what’s affecting that in a positive way, but also what’s affecting that in a negative way. Um, and as we add those more teams, how is that affecting that velocity? You know, and as you know, as we go through and do our planning, that’s going to be one of those things that’s key ultimately for these often capital projects when we’re dealing with the enterprise that say, all right, you know, what’s my runway to get this ultimate deliverable? That may be a year, you know, six months, a year, a year and a half down the line. Really all of that’s going to come back to our velocity and how those teams are efficiently working together.

Dan Neumann: [08:53]  Oh, you touched on one of my favorite things, which is metrics and we’ll, we’ll probably have to dig on that. It may be a different episode at one point.

Taylor Howard: [09:00] We want to be careful for that one. I’m a data guy, so again, we can go down the rabbit hole quick, so I’ll rely on you to pull us out.

Dan Neumann: [09:06]  Oh cool. And I have a conference talk about all the dangers of assessing and measuring and the weird behavior you get. So yeah, it’s awesome. So Steven, Taylor had mentioned a bunch of things including some technical guts about containerization and, and some cloud technologies. Uh, but maybe you could, could jump in on some of the challenges that you’re seeing and especially with some of those alignment topics.

Steven Granese: [09:29] Sure. And it’s hard not to respond to the, the uh, the measurement conversation right there, right. I mean, uh, Taylor certainly talked about velocity, which is a term that most practitioners of Scrum, uh, are familiar with. Um, you know, with a single team using a measurement like velocity to determine how much work that a team is doing and being able to get into some level of predictability with your sprint cycles is always important. But then at scale, what do you do? Does every team have to use the exam? The same type of measurement. Um, there’s help from some scaling frameworks and, and that’s that there is certainly some guidance there. But the real challenge is, as Taylor mentioned, when you’re working at the enterprise, when you’re working at large organizations, large software programs, um, it is a challenge to make sure that the teams are coordinated. Um, you know, how do you make sure that all the teams are, uh, are delivering software and they’re, that they’re building the right thing? Um, again, a single team working on a, let’s say a two week time box is, is a challenge enough, especially when they’re new to agile. But you know, at scale, a lot of these questions, you become real challenges real fast because we need to make sure that everybody is marching towards that same goal and they’re being measured in the same way.

Taylor Howard: [10:46] Yeah. And you to touch on that and then really just, you know, kind of unpack this thing and shine a bright light on it is when you’re, you know, when you’re building software for your organization, it’s all internal. Um, and you look at hypothetically two teams that are running, you may see two very different velocities, you know, Team A versus, you know, a team B and, uh, you know, you see different things, right there, different outcomes. Team members, they’re all people. They have different capabilities, strengths, weaknesses. When you’re in a consulting world and the, you know, someone will look at you and say, all right, well why is Team A delivering so much over here? But the team B, I’m seeing a different delivery. And that could be, you know, positive or negative. And, and I think what Scrum does and a lot of these agile frameworks, which is important is they really open up the dialogue. Let’s not hide from that. Let’s have that conversation. Let’s explain that people are all different in how they deliver, but that’s something we really need to be active on. You know, we need to talk through that and, and, and see that this is not about, um, you know, getting back to metrics. You know, Dan, as you mentioned, we don’t want to weaponize. We want to weaponize those metrics. We want to use that data. Is something to say, all right, you know, what can I do to support, you know, Team B if, if they weren’t delivering at maybe a, a velocity that we’d like, I’m in better understand that. Or look at what Team A is doing and say, wow, what, what, what are these guys doing over here that is really making such a difference and how can we replicate that? So there’s an opportunity there for a conversation. Um, you know, that in the consulting world you really have to be, you know, I think it’s really important to have that very open, honest dialogue. And, and that’s one of the things I love about agile and Scrum and Kanban and all of these frameworks is they really do shine a bright light on the good, but also the areas where there’s opportunity for improvement and you know, embracing that opportunity for improvement is going to be the key there. That will, I think, be a big judge between, you know, or, you know, indicator of success versus failure.

Dan Neumann: [12:38]  The other Scrum framework has the approach of transparency, inspection and adaptation. So for folks that are doing Scrum, lots of transparency, you inspect and adapt for folks that are doing Kanban, perhaps with or without Scrum, you have visible work streams, you have a lot of transparency that’s happening with that, with the board, with the data, the throughput, et cetera. And I think one of the challenges then that you touched on, I wanted to come back to is how do we, how do we look at the system? How do we measure it? And especially then for stakeholders, how do you use that data for information and not for evaluations? So not to look at a metric, whatever it is, and go, good team, bad team. As soon as you do that, the teams are smart enough, they’ll figure out how to manipulate that metric. But how do you look at that and go, oh, that’s interesting. I see you talked about velocity, lots of fluctuation and velocity. What’s happening? Is there something in the way? How can we improve the system as leadership, as management, so that we get a more predictable outcome if that’s what we we value. And so I think one of those, those challenges and what works really well is when you start to embrace a culture of curiosity and inspecting that and asking questions about the data as opposed to, you know, demanding that the data stay fluid. And I know we don’t demand that it stays fluid, but have seen examples where when any fluctuation is bad, teams know they’re being evaluated. They will no surprise. They will make that data look stable, whether the system is improved or not.

Steven Granese: [14:15] Yeah, Dan, it’s such a huge topic. Um, you know, as, as a consultant and certainly as a, you’ll hear a lot of agile coaches in the industry talk about, you know, blame the system, not the person. And really what that means is, you know, let’s make sure that we’re understanding the system that any individual person or any individual team is operating within. So rather than blaming a team for their velocity being down, uh, for a specific sprint, for example, let’s look at the systematic reasons that might have caused that. So that’s certainly a topic that is very familiar in our industry, but it’s scale. Again, that really gets highlighted even, you know, much more dramatically. So for example, if we’re on a software program with, with 10 teams, some of those teams are not going to have a good sprint. It, it just, it’s just not it, you know, there’s never a situation really or never, um, a sprint where every team does well. But there’s reasons why that happened. Um, there could be technical challenges, right? There could be challenges with um, maybe the, the customer, the end user, where they weren’t clear on what they wanted to build. Right. And this really comes down to leadership frankly because, um, at the, at the leadership level, if the leaders understand that their job is to make sure that the system is healthy, uh, meaning the teams have what they need, meaning the individual people have what they need to be successful, um, that any impediments are being dealt with in a very quick fashion. I mean, that’s the job of leadership inside a large scale software program, um, so that the teams can be freed up to focus on what they do best, which is, which builds softare and deliver software. Um, if the metrics are being used as a weapon, meaning if the metrics are being used against teams to prove why they didn’t do a good job, you know, that just makes the challenge of, of delivering at scale that much harder. So yes, they’re scaling frameworks and yes, there’s lots of guidance, but at scale, it just, every client, frankly, that I see that is, that is struggling with this. It really is a matter of they just don’t understand what’s the right way to lead this program. And that’s, that’s a challenge for so many organizations.

Taylor Howard: [16:25] Yeah. And, and to Steven, I agree with you 100% into dove tail on that, you know, oftentimes we’ll say, you know, problems only ever get larger. You know, if I’ve got a challenge right there, and if I let it sit and don’t deal with it for two weeks, it’s pretty rare it’s going to go away. It’s probably just going to grow. And, uh, with all of these frameworks that we have, you know, these agile frameworks, I sometimes distill that down. What I’m, what I’m talking with someone about it or speaking with my wife or a friend or someone outside of the industry. Ultimately the goal there is to, is to make it okay to bring up problems cause they’re small, bring them up right away. You know, and as Steven just mentioned, we want to deal with those right away. Um, but when we do that now, you know, it’s like the canary in the coal mine, that early warning system, we can address these strings and it’s intentional that we’re going to call them out, make it okay to call it out, make that an important thing. We’re going to need to adapt every, you know, every in every project and product we’re working on will have its situational elements. And let’s make this say a, a good place where we can bring up those challenges and work on fixing them and give it, you know, give it some active energy as opposed to not dealing with that. And that’s where if we weaponize these metrics, if we do these, we’re going, we’re going the other direction where it’s not safe to bring that up and things are being missed and they’re not getting addressed and it’s going to, you know, the chickens will come home to roost as they say. And uh, we want to make sure that we’re, we’re spending some, some good energy on making sure that everyone is in a good place to bring those things up so we can, uh, we can fix it and make changes.

Dan Neumann: [18:07]  Definitely. So we touched on a couple of things. The team of focus and shifting that, really elevating that to more of a system focus as a way to address one of those challenges. And then the danger of issues getting buried and really working and looking at the system then to put in place ways that those issues can become more visible. One of the other challenges with scaling is the way the teams interact with each other. If you’ve got specialized teams versus cross-functional teams and the architecture and the way we’re building those systems and maybe a, I don’t know, Taylor, that fits pretty well into with some of the, the technologies that are applied to it. And then Steven of course with some of the organizational design that that gets applied to helping organizations be more resilience. Maybe we could touch on that challenge in some ways to address that.

Steven Granese: [18:56] I mean I’ll, I’ll actually start, I think we often start with the organizational side of things first. Um, uh, you know, again, with a single team that’s building software, there’s often a focus on how do we build a cross functional team that has either zero or minimal dependencies on other areas of the organization. Frankly, um, we know we like to help our, our customers understand like can you get a software team a cross-functional team as close as you possibly can to the customer so that they can just focus on delivering software for that customer. At scale, that’s really challenging because now you have multiple teams that need to coordinate with with one another, not only before they start a sprint to build software, but during and after as well. So organizationally, yes, we want to have cross functional teams as much as we can, but there’s a lot of dependencies on, on certain specialty teams. Taylor mentioned before, not just software delivery functions, but, but what about operational functions? What about governance and oversight? A lot of, a lot of these enterprises that that we work with have their own organizational challenges that cannot be changed just because we’re building software for them. So we have to work within inside those systems. So organizationally there’s a lot more focused on the communication of dependencies. Yes, we want to eliminate dependencies. Certainly that would be a perfect world if we can, but they can’t all be eliminated. So a lot more time needs to be spent communicating the dependencies, you know, are, for example, there might be one piece of functionality that this program needs to build and deliver and three teams might be responsible for coordinating together to build that. Can they do it all within one time period of the sprint? Do they need to build one piece first? Then the second piece, then the third piece, um, it’s, it’s always going to be different. So from a system perspective, we need to make sure that there are lots of feedback loops, there are lots of channels for communication and that teams don’t get siloed into being all by themselves and just building software that’s on their individual team backlog and they’re, they’re not understanding the broader organizational context and they’re not understanding the need to communicate those dependencies.

Taylor Howard: [21:04] Steven, I’m really glad you brought up the systems view and perspective on this because I agree with that. And, and there, you know, there are a lot of areas or really I’d say all areas where it’s really important to have that holistic perspective. And, and I guess if we look at this, I’ll kind of go into a, a bit of an example, but a lot of the organizations that we work with are multinationals, they’re in highly regulated or a compliance driven industries. And, and so from a technology perspective, even the, the tools that we use right there, we have to be very intentional about what’s allowed, what’s not allowed. You know, right now open source software is a, it can be a, an incredible accelerator and most organizations are adopting those. But if there is a new open source library you want to pull in, well for that organization, can they go ahead and use that? You know, what are the channels to working with our office of General Counsel to get that approved? You know, what licensing agreements? So you have all of these things that if you’re running in a single team that might present a particular challenge and that energy, we’ve got to put around that on, around what sort of technology we can bring into the solution. But when you’re running at scale, and now this is a, a delivery that is in multiple Geos, you know, uh, different, you know, regulatory bodies looking at that, all these other things come into play that it’s really important we’re cognizant of. Because if, if we, if we consume, you know, something that is not approved, it’s actually never going to make it out the door because we didn’t work with those other departments. That could be very much outside of what oftentimes when we think of is, is pure IT. So having those channels, understanding those, understanding the organization you’re working within is key to make sure that the software delivery side of it’s working well. And then of course, you know, the final part of that is it’s got to be up and running and operationalize. So there’s all kinds of technologies that help us with that. But, uh, a good DevOps and, and working well with that operations team to say, what are, what are you able to consume? What’s your comfort level? How are we going to kind of push this out there? Um, you know, we’ve got to have those dialogues and, and that’s really that systems view of it, not just pure, let’s build this thing here. Let’s make sure that it’s going to work in the overall ecosystem that is presented to us, uh, you know, to, uh, to solve those business challenges.

Steven Granese: [23:12] I think a lot of what, um, you know, this conversation is about, um, obviously it’s about scale. It’s all it’s about, you know, large enterprises. A lot of the, uh, I would say that the, the guidance from let’s say the agile community around different frameworks, oftentimes it’s around startups frankly, or new product development, you know, concepts like building an MVP, um, you know, which is about a new product, getting it to market, getting feedback. Are we building the right product? Will the marketplace accept that? Those aren’t really the challenges that a lot of enterprise clients face? Yes, they have challenges of new product development, but oftentimes their challenges are more of what, what Taylor was saying, making sure that technology libraries are compliant. You know, much of the challenges of large enterprises these days is around security. Making sure that, you know, the data is not being hacked into. Um, and you know, challenges like that. And so, um, you know, getting software to market in two weeks, for example, is not necessarily something that the enterprises are worried about right now. And in a perfect world, they might be. But, but that’s just not their primary focus. So much of the primary focus is on security, which in a lot of ways feels like it goes against working in an agile way. Agile methods are often about moving quick and getting something to market quick and getting feedback fast. And oftentimes enterprises are saying, well, yes, we want to have the ability to do that, but we also can’t, we can’t screw up. We can’t deliver it something to market that’s not compliant. Um, um, and so those are, again, it’s, it’s, um, it’s, it’s always a balancing act. You know, from our perspective, we want to make sure that we’re delivering solutions and guidance that are in alignment with our customers’ needs and challenges. And not just because, hey, that’s what we’ve learned and that’s what we think we should do. And that’s what some other startups or smaller companies do.

Taylor Howard: [24:53] I mean, really the takeaway that I’ve got there is you’ve, we’ve got to be pragmatic and delivery right here, you know, and, uh, the cloud brings all kinds of optionality to the table and what we can do, how we can consume things. Um, but it, it all boils back down to, you know, understanding those, uh, those needs that are going to fit into with that organization, what their capabilities are, you know, meeting of course the tactical things that are near term we must do, but we’ve got to align to that larger vision, uh, as well. So, and that, that really should be a big driver. And, and how we, uh, you know, package put that solution together and, and really, you know, partner on the ongoing care and feeding of that.

Dan Neumann: [25:28]  Agreed on those things who are talking about. We had an episode, a couple back with Barry Matheney who was talking about DevOps. And while we might not typically want to go to production very rapidly, especially with some of the bigger programs with the highly regulated, when there’s some kind of vulnerability that’s discovered or a breach that needs to be addressed, you also have to have a system that can be fast enough. And so while some of these practices might not get used on a day to day basis, you need to have them in your tool belt. So that when there is something that requires an immediate and rapid response that the organization’s set up to do that. And not looking at it for the first time going, oh Geez, wow. Uh, what do we do now?

Steven Granese: [26:10] And that’s a great point, Dan, because so much of it is the mindset of, of the clients we’re working with or the leadership involved. Because to your point and to Barry’s point, right? Um, yes, we actually want to teach our clients and help them with, to have the ability to deliver continuously, um, to have the, the ability to automate as much as possible. And sometimes your clients that are new to this, um, and especially when they’re focused on the challenges that we mentioned before around security and, and making sure that nothing breaks, frankly, um, they, they feel like agile is the wrong way to go, or the wrong mindset perhaps because hey, we don’t have, we don’t need to move fast. And, and again, that’s not what this is about. To your point. Um, frankly it’s about teaching them that yes, you can deliver continuously and that can help you be more secure because when there is a problem, everything’s automated, right? We could make the fix and we can automate it, uh, you know, automate the deployment and that can go out to the production environment right away if needed and it’d be, and it’s shifting from an, it focus to a business focus, which so many organizations, frankly, especially people that have been around large enterprises for a long time, IT has held the business hostage for years. Um, and so there’s a mentality that it’s business versus IT, that IT owns the keys to the kingdom, so to speak. Um, and a lot of these, these methods and a lot of these, uh, uh, frankly, mentalities are about, um, helping the organization shifts so that the business is a collaboration between the two. But the business can decide when they want to deploy, when, how fast they want to move. And IT is just an enabler.

Taylor Howard: [27:45] Yeah. And, and I think that when we do so working with, I mean these, these, uh, these operations groups for these enterprises, they have a a, I mean, that’s an incredible amount of responsibility on their shoulders and, and the work they have. I mean, let’s not minimize that. It’s, it’s, you know, it’s, it’s substantial. And so as we can bring those two groups closer together and business has a better appreciation for what you know with those operations teams are doing and sees how we can, can be agile with some of that automation as Steven talked about, um, you know, we’re seeing some great partnerships develop within the organization and, uh, you know, it’s nice to be a part of that, you know, but, um, when we see those two groups get closer and closer, you know, a lot of those silos, you know, can be broken down and still respect the controls that are necessary, you know, for delivery.

Dan Neumann: [28:33]  What came to mind for me as you were describing that is moving from an us of the mentality, you know, us, the Devs, us, the QAs of them, the compliance them, the legal to more of a we mentality and really look at the overall system there. And the other concept, just to plug one more episode with uh, Eric Landes who was talking about full cycle developers. So instead of having one team build it and hand off to another team to support it or operationalize it with DevOps and with a development team that is kind of full cycle, being able to own that from cradle to grave. So for folks that are looking for more they could go look up that episode as well.

Taylor Howard: [29:07] Yeah, no, definitely. That sounds a little, a little, a little podcast from my drive home this afternoon, so that’ll be perfect.

Dan Neumann: [29:15]  Yeah. Well, thank you for, for joining and discussing this topic. I am curious as part of your continuous improvement journey or you’re learning, are you reading or listening to or watching anything that’s kind of inspiring you these days?

Taylor Howard: [29:30] So I’ll go ahead and jump in on that one then. Um, so a book that I’ve been, uh, been brought up, I should say instead of reading, I would really, I’m a big, uh, big audible guy, so I love listening to that as I’m going from A to B or on a plane or something like that. Uh, but Scrum Mastery From Good to Great Servant-Leadership by Geoff Watts. Uh, it covers a lot of ground, which I think is, is great. And gives some situations where, you know, different frameworks, whether it’s Scrum or Kanban, you know, it can be applied and we’re, we’re big proponents of servant leadership here at AgileThought. So bringing those two together, I mean, I think it’s a natural fit, but that’s been a great, uh, a great listen so far. I’m actually kind of listening through it again. Sometimes it takes a few times, but, uh, really enjoy that right now.

Dan Neumann: [30:12]  Sounds good.

Steven Granese: [30:13] Yep. And um, I’m also a big audible fan as well, but I still just refer to it as reading. So, uh, but I’m currently reading a, The Age of Agile by Steven Denning. I actually saw him speak at the Agile 2018 conference last year and a lot of, a lot of the, uh, people in my practice have been reading that book as well. And one of the things I love about that book is really the focus on the business side of agile. Um, and understanding the difference between, you know, optimizing a business for, for shareholder value versus for customer value, which the agile movement is so much about focusing on customer value and how to make those, the shift in your organization or frankly, how do you make sure that they align so that there’s not a big gap in a big fight, let’s say, between the, the teams that are using agile and the shareholders of the organization frankly as well. So it’s a fascinating topic.

Dan Neumann: [31:04]  You guys touched on a couple of things there. So Scrum being done in a masterful way is hugely important. You know, sometimes somebody says, oh, we’re doing Scrum. And it’s like, cool, we’ll tell me about it. And you find out that it’s, um, a very weak implementation of Scrum without any of the values and the principles behind it. Or it’s even lacking roles and events. So doing Scrum well, and then the challenge with scaling, a lot of these companies are publicly traded companies and you end up with tension between shareholder value versus customer value. How do you invest and grow and where do you cut costs? And that whole challenge, it can drive shortsighted thinking and that’s a real challenge for big organizations embracing agility. Well, thank you very much. Sorry, Steven, did I just cut you off? Did you want to add?

Steven Granese: [31:50] No, I was just going to agree and, uh, uh, just wanted to thank you, Dan, for giving us the, the, the opportunity here to talk a little bit about what we’re doing here at AgileThought and um, and thank you to Taylor for joining as well.

Taylor Howard: [32:01] Yeah, definitely. Yeah. Thanks Dan. Thanks Steven. This is great. And uh, looking forward to, uh, maybe jumping on a few more of these. This is a, this has been a lot of fun.

Dan Neumann: [32:08]  Thank you folks. I appreciate it. Really enjoyed the time and, uh, we will be sending out more calendar invites. Thank you very much.

Outro: [32:17] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought, get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.


How can we help
you succeed?

Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.

For a better experience on the web, please upgrade to a modern browser.