Podcast Ep. 12: The Importance of Embedding a DevOps Skill Set into Your Team

Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

Your host, Dan Neumann, is excited to bring you two guests for this week’s episode — repeat guest, Eric Landes, and Barry Matheney. Eric and Barry are AgileThinkers alongside Dan at AgileThought, and are both experts in the DevOps space.

Eric Landes is a Scrum.org certified professional Scrum trainer and currently serves as a Senior DevOps Consultant, ALM Director and Solutions Architect. Barry also is a Senior DevOps Consultant. Prior to his role at AgileThought, Barry served as Director Enterprise Applications at Kforce Inc.

Today, they’re talking about DevOps and the importance of having it on Scrum teams. They cover whether the barriers between Agile, Scrum, and DevOps are good or bad; what well-functioning Scrum teams look like when they have DevOps skills embedded into them; how to incorporate DevOps into organizations; what DevOps skills could bring to a team; and how DevOps can fit into even the most traditional of companies.

Note: The views and opinions expressed in this podcast are solely those of the host and the guests. These views and opinions do not necessarily represent those of AgileThought, other organizations, or other individuals. 

Listen on Google Play Music


Key Takeaways

  • Is it good or bad that there are barriers between Agile or Scrum and DevOps?
    • It is disadvantageous to separate DevOps from Agile or Scrum, because it is important that your team has all the skills they need to deliver software
    • You need DevOps skills on your team and it should be a goal to incorporate it
  • What do well-functioning Scrum teams look like when they have DevOps skills embedded into them?
    • Self-sufficient
    • Not limited by dependence on other teams or organizations
    • Eliminates walls and allows for continuous delivery
  • How to incorporate DevOps into organizations:
    • Use baby steps
    • Use it to inform the beginning of the development cycle and product decisions down the line
  • What DevOps skills bring to a team:
    • Experimentation or hypothesis-driven development
    • Rapid deployment and continuous delivery
    • Tons of not-so-visible benefits (such as auditing, compliance, security, deployability, and testability)
  • How DevOps can fit into traditional companies:
    • Remove constraints (such as specific deployment dates)
    • Automate the value the compliance brings



Mentioned in this Episode:



Eric Landes’ and Barry Matheney’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 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:17]  Welcome to the AgileThought podcast. I am Dan Neumann. Our goal here with the Agile Coaches’ Corner is to bring you agile topics in an approachable way. So if you have a topic you’d like us to discuss, you can email it to us at podcast@AgileThought.com or you can tweet it with the #AgileThoughtPodcast. I’m excited to have two guests with me today. Barry Matheney and Eric Landes, both fellow AgileThinkers and experts in the DevOps space. And we are here today to talk about DevOps and the importance of having that on Scrum teams. Eric, Barry, thanks for joining.

Barry Matheney: [00:55] Thanks.

Eric Landes: [00:56] Thanks for having us.

Dan Neumann: [00:58]  A lot of times there are barriers I think built around, you know, there’s the agile and the Scrum stuff and then DevOps separately and good thing or bad thing. What do you guys think?

Barry Matheney: [01:08] Oh, I’m gonna take this. Uh, and my take on this and experience with it has been that yeah, we kind of separate DevOps into its own silo. And when we talk about, let’s say Scrum, do you want our teams, our development team specifically to have all the skills it needs to deliver the software. So that’s where I want to emphasize, especially with, with Scrum teams. I want to emphasize, you need to have the DevOps skillset on the team and we can talk about how you get to that point. And that should be a goal really for teams. The goal should not to be to have a separate DevOps team. Because what I’ve seen, we tend to throw that software over the wall and leave really some of the things that I believe that the team should have an investment into the devops scene. And so that’s, that’s where I’m coming from. And what, what we tend to preach is, you know, we want to embed those skillsets on a team and give Scrum teams and agile teams that skillset so that they can deliver from the beginning of the lifecycle of the end.

Dan Neumann: [02:25]  And Barry, what are you seeing when, when you have well-functioning Scrum teams with the Devops skillsets embedded in it?

Barry Matheney: [02:35] So I think that natural thing that Eric has talking about specifically is you are completely self sufficient at that point, right? So now then my capability to deliver is not limited by the dependence on other teams or organizations or somebody else on the other side of the wall and I’m not delivering over the wall anymore. Right. Production becomes mine and I own it. I operated, I can, I make sure that it gets the care and feeding. I make sure things in my backlog get prioritized. All of the things that Scrum and agile teams for set out to do in the first place. Right. To make me own the product all the way through to providing that value.

Dan Neumann: [03:18]  Yeah. So you’re, you’re ripping out those walls then that might exist.

Barry Matheney: [03:22] Yeah. And you know, we’ve talked previously about things like WaterScrumfall, right? So with water the, the analogy is water still the planning, the budgeting and all that type of thing. And then we got to do work in the Scrum manner. And then the fall is when we throw it over the wall to the operations team to do the run part of the idol. Right? But if we can just eliminate the fall and just make it the WaterScrum, we’re going to be in a much better place for that product long-term.

Dan Neumann: [03:49]  Well, and as a, as a Scrum guide, say let’s eliminate the water part too and try and get to the point where we’re just delivering a value continuously and eliminate all those walls.

Barry Matheney: [03:58] I’m not, I’m not arguing with you at all. I’m just talking about one piece of the puzzle at a time. I think that’s a different, that’s a different audience and a different conversation.

Dan Neumann: [04:07]  Right. Well, right. Well and you bring up an important point and Eric we’d love to get your thoughts on that as well. So one piece of the puzzle at a time, you know, there’s a desired state for DevOps and a Scrum team with all the skills necessary to deliver it. You had mentioned owning production, and we’ll want to come back to that a bit later, especially in maybe more regulated places, but let’s get everything together. But we have to do that in some baby steps in most organizations. You know, is that how you’re seeing things come about, Eric?

Eric Landes: [04:37] Yeah, I would say definitely baby steps. And I would believe actually DevOps in, and I, I believe Barry and I are are on the same page here, but I want to clarify that waterpark DevOps should be informing the beginning of the, of the seat of the development cycle. So DevOps should be helping give good data about what customers are using. That should be part of what we’re delivering when we talk about production, right? We’re delivering telemetry, that kind of stuff. So we can go back to understand what your actual data is and here’s what our customers are actually using and you’re spending money on these things that maybe they’re not using or those kinds of things. So, so getting that right, getting that correct can really help that water part of the WaterScrumfall hmm.

Barry Matheney: [05:36] Well and to pile that a little bit, I think it even goes a little a little deeper than that, right? Because if you’re building a product, to me that’s the water and the planning and the budgeting. We’re just in what you’re talking about is, are the features that I’m adding to this product at this point going to continue to continue to add value? Right. So if they, if we have the telemetry and we have the metrics and we have the capability to determine through DevOps practices, you know, different types of testing, target audiences, those types of things, then it becomes a, it’s an affirmation that our, our, our tests are running the way we expect them to and we’re going to get the return value that we’re looking for.

Eric Landes: [06:17] Right. And I would say though that the, we should be also influencing that that information should not just be influencing features, although that’s a large part of it. But it would also influence our product decisions. Hey, we thought x amount of customers would be engaged with this application this time of the day. And it’s not meeting our expectations. Now we can effect the budget because we have actual numbers, right? So, so that’s where I was going. Insane. It should influence that water falls that it’s not just the feature information, it’s giving you actual customer data that should inform product decisions down the line. Again, once you get that set up and you and you get a baseline, going back to those baby steps we talked about, Dan is, uh, you’re not going to do that day one of starting to have a DevOps culture and embedding some, some DevOps concepts on your Scrum teams.

Dan Neumann: [07:14]  Right. I think what I hear you two describing are maybe a couple of different scenarios. One being a greenfield environment. Barry, I think maybe you were alluding to this where we maybe don’t have any thing released yet. So we’re setting up a new team. We’re setting up a Scrum team with DevOps and there’s more of the, maybe the waterpark before the Scrum in what you were describing there. And then Eric, I think maybe what you are describing is after something is released to production, which is hopefully very early and often, then we’re starting to collect the information that telemetry, the metrics about usage, doing split tests, those types of things and leveraging the DevOps skill to help that inform how we continue forward on that roadmap.

Eric Landes: [07:59] Yeah, I would, I would agree with that. I don’t know what to think Barry. I mean one thing I would, I want to point out, cause we’ve talked about this Dan before, is the idea that hey, maybe we don’t need to invest more in that speaker or even product. And that’s where I was going with this is where you’re going to have data to make those decisions to say, Hey, let’s invest over here, not over here. And that investment could be a feature. But I also believe it could be at that product level.

Barry Matheney: [08:28] Yeah. And I would also just to, I totally agree with everything that you just said, Eric, and I know that you and I have talked about, you know, the books the DevOps handbook and those types of things. And one of the most profound feature or one of the most profound statements out of that whole book is that almost two thirds of features either to provide zero or negative value, right? So are we building the right thing and do we have the data to make the determination about whether we’re building the right thing or not? And the only way to get that is through that experimentation and testing that you’re talking about.

Eric Landes: [09:03] Absolutely. And actually that’s a great point, Barry, the experimentation. You know, we’ve talked about the, the lean culture and values and those kinds of things. And one thing I like to emphasize is that idea of hypothesis driven development or experimentation where, you know, hopefully the DevOps skillset brings that and the lean thinking brings that to the team, hey, let’s test what we think is going to happen with this feature and get some real data back. Uh, and, and if we have a production mindset, you know, live site mindset, we can actually do that, right? We can say, Hey, this, we think this is going to happen when we release this, let’s release it. Let’s test that hypothesis. If it works great. If it doesn’t, we’ve learned something. Let’s take that winning, let’s apply it to our backlog and whatever else we have. Right?

Dan Neumann: [09:58]  Absolutely. And we have an episode with Adam Jewelry, a few episodes back where he talked about the experimental mindset. And so now with the DevOps practices or the DevOps mindset, we’re able to take the experimental mindset, actually measure things and then use that to inform our path forward using that hypothesis driven development. What are some places maybe where you’ve seen some really strong positive examples of of DevOps people are like, okay, I get the way on DevOps on an agile team, but maybe I’m still having a hard time wrapping myself around. What would that look like when it’s really being successful?

Eric Landes: [10:36] I have experienced a Scrum team that was doing really, it was machine learning and doing some big data type, uh, new greenfield project. And we had a team, a fairly large team with developers, very large Scrum team and DevOps role was part of that team as well as other, you know, testers. And that became the base was the client was very happy with the results because the team was able to get the data models out into their production site quickly. And in that particular instance, they were actually modifying data models constantly. And so, uh, being able to deliver frequently, it was something they had to do in that project. So we actually had that, all the roles that we needed to get out to production on that team, lots of powershell scripting and all that kinds of stuff happening, but also feature building and we didn’t have a separate team doing delivery. So that’s, uh, that particular client was, was a success. Barry, I know you have some.

Barry Matheney: [11:41] Yeah, I’ve got a couple actually. So, um, and I think the, the, the more interesting one is the delivery. So this was, I won’t call it Greenfield, but it was the implementation of a SAS product. So we built that product and those Scrum teams with that in mind of, we know it’s not going to be continuous delivery, but we won’t rapid delivery. So we built agility, flexibility into the delivery mechanisms to, we built test automation. We did all the best practices. And that’s, I think that’s a key component here too. It doesn’t have to be around just new software, Greenfield, any of that type of stuff. You can apply DevOps principals and do practices at any level, on any type of application. You could just have to decompose it and it depends on how far you want to go as to what the benefits you’re going to get out of it. Um, that one we wound up in a culture where, you know, deployments were every three to six months and we were ready to go, we could have gone weekly if we’d want it to. So, uh, those are huge improvements. Uh, and again, I think some of the best stories are, wow, the deployment happened and nobody knew about it. That’s exactly what’s supposed to happen, right? It got the pride and there was no upset. You just show up in the new feature’s there and you’re ready to go. Right. And those are the best, the best case.

Eric Landes: [13:02] Absolutely. I love it when, you know, I’ll use the Netflix example that I used in a lot of my classes, but when I watching Netflix and I go to, you know, view a new, a new series, a TV series, this is the catalog, you know, I, I, I said I’d love to watch this and all of a sudden it automatically went to the next episode in that series without me having to press a button. I was like, wow, this was amazing. Right. And that it happened automatically. And those are, that’s the kind of thing you’re talking about, Barry and I love it when that happens with, with our continuous delivery model.

Barry Matheney: [13:40] Yeah. And I think another topic that we want to bring up in this, probably for a completely different conversation, but we need to really start talking about the a nonfunctional aspects. So we’ve talked a lot about the Scrum team and getting features and delivering business value, but there are also a lot of not necessarily visible benefits such as audit and compliance and security and all of those things being built in from the beginning. Deployability testability, all of those features that aren’t features of normal, you know, software delivery products where they become built in and now they are a feature of everything that you’re doing.

Dan Neumann: [14:20]  Actually I want to touch on that for a second because you know Netflix obviously does some wonderful things. I hear a lot of counter examples with folks when they’re like, well yeah, but we are not a, we’re not a .com you know, we’re not able to release to production because separation of concerns, different environments, different gates they have to go through and I think it would be helpful for people listening to maybe talk about how DevOps fits into some of these more traditional places. Sometimes it’s bigger companies that are just now maybe going to a more agile mindset and they’re really struggling with how do we go to production if we are, let’s say an accounting firm of some kind with separation of duties.

Eric Landes: [15:00] We have actually worked with that particular concern and the concern isn’t we want to deliver every 11 seconds like maybe we do on Amazon, right? What you want to do is I want to deliver when I need to. Yeah, that’s what I like to say. So I don’t want to be constrained by something I would say is really an artificial constraint. Like, oh, we only deploy on Tuesdays or we only deploy monthly, quarterly, whatever. Take your pick, right? Whatever your policy is. So let’s see if we can remove those constraints. So what are they? And one of one of our clients that happened to be about around compliance and that is definitely a valid concern. So it’s, you know, let’s look at it. I think in the DevOps looking at this, we’re going to look at this as what is the value that the compliance brings and then can we automate it and how much can we automate the value that’s bringing there. So in this case, maybe we’re validating something like a build pipeline and making sure certain people can’t modify those templates. Can we automate that part of it? And not just the build, but can we automate and who has access and the compliance part and the auditing part. And I would argue we can. And there’s lots of ways to do that. Barry, I know you’ve got some examples too.

Barry Matheney: [16:19] Oh yeah. So just for context, right? So there’s continuous integration and continuous deployment and continuous delivery. All you can, you can, if you’re willing to invest and design your application in a manner that allows it, you can do to continuous deployment irrespective of the field or industry that you’re in. And I’ll just go back to part of the reference material, one of the best things that I heard, and I heard it originally from a jazz humble thing was, you know, the real metric is how long does it take you to get a single line of code from check in and to production. And so don’t think of it in terms of a feature. Think I would, in terms of zero day security breach, I need to do it right now because my environment is at risk, right? I can’t go through or I need to minimize as best I can, that lead time that it takes to check in that code and get it into production so I could limit, you know, and if I don’t do these things, I’m dramatically limiting my businesses ability to continue to stay in business even because they’re going to, you know, security things are probably going to be the, uh, one of the biggest reasons that we’re going to need to deploy fast anyway. So, and, and the other thing is, is single piece, right? So it’s a single line of code. How do I deploy that rather than deploying the whole application. So again, a lot of those are architectural design principles. A lot of them are, um, just, you know, develop best practices. And again, it comes back to, are you a Greenfield? Are you, do you have an existing application? And how do I retrofit that? Which is kind of where we started. How do you build this in from the beginning, right? Or how do you approach it differently? If you’re going to be coming into a project that’s already established and maybe it doesn’t have the capability to deliver more than once a month or something like that. So how do you go about that? Right?

Dan Neumann: [18:10]  Yeah. The scenario you mentioned of a security breach or some other compelling business reason to go plug a gap that you have, it’s a different mindset on it. It’s like, yeah, you know, we, we might not need to release quote new features at a, at a high rate of candence said, boy, if we have a a compelling reason, we need to get some kind of change out, boy, we better be able to do that.

Barry Matheney: [18:30] And there’s actually some use cases. Fannie Mae actually had that very problem. They had a zero day breach and their site was down and they made decisions and they had the release capabilities to go in and they repaired it. Almost no time at all. Right. And it was a, it was a serious breach that we were talking about. So it’s not impossible. But again, you have to, if you’re not designing for those types of situations, it’s going to be problematic and you’re going to have to take exceptions to every rule, um, that you’re, that you have put in place or implied by not doing best practices necessarily. So something else that you also mentioned Dan, and I just want to make sure that everybody understands that separation of duties and separation of concerns, it doesn’t mean that a developer can’t deploy the product. What it means is a developer has tools that takes the control of a production environment away from them so that they can’t do damage beyond what the intent, right? So again, I have to design a process and design tools. There are tools out there that separated so that, you know, somebody has to approve and all those kinds of things. Those were all great and fine, but you know, maybe the product owner is the one that says, oh, I’m ready to go to pride, pushed the button. And it goes, you know, I don’t even have to be a technical person to do those things. So, but it could be a developer if he found a bug and he fixed it. There are lots of companies that are PCI compliant that are doing those types of things.

Dan Neumann: [20:11]  You mentioned compliance. And that was exactly where my mind went for an organization that has to be compliant is there educating of an auditor that may be needs to be done if they’re having an internal or external auditors come in. To what degree are maybe auditor’s realizing what these things do fit the compliance models versus there’s some education or building a case that you have indeed achieved, let’s say PCI compliant or, or you know, insert your framework.

Barry Matheney: [20:38] So I would, um, and Eric can pile in on this too, but I would say that it actually makes compliance and audit easier because I’m going to, again, from a DevOps perspective, I know what audit questions I have to answer every quarter. Why wouldn’t I build that in such that I have that collateral sitting off to the side and I give the, the auditor a UI to go through to give them the same information that I would have given them anyway. Right. So again, it goes back to application design and release pipeline design and those types of features that you design into your continuous delivery practices that facilitate that stuff.

Eric Landes: [21:20] And I would add with, uh, the, the whole idea is, and you really said it, the team is collaborating with the compliance folks. So when we talk about that DevOps skillset, we are saying, hey, we may need the skillset from the compliance folks. And that may, what that may mean is they work with us for a couple of sprints. If we’re a Scrum team to create that automation that helps them. And I agree with you Barry, on, on that point that we definitely can improve the auditors experience, right? And, and, and help them do even a better job and maybe make it, make them focus on the value they burn rather than digging into code and that kind of stuff to to uh, to do more what I would think of as more boring tasks. Right?

Barry Matheney: [22:11] Yeah. And I think from a level of involvement, time commitment, how do we do this? Right? So the Google SRE model is that one SRE for x number of Scrum teams. And what they do is they teach that team to learn how to operate their own services and from a security and from a compliance perspective, if you have somebody that’s involved, you know, maybe on their end for the first two sprints or three or whatever the number is, and then what you build is a level of trust on that team to know that you’re going to build all the security controls, all of the compliance audit, all of that stuff in, every time they do something and now that they don’t have to be involved all the time, right. But there may be new features or new areas that they have to come in to consult on and they become very consultative for the longterm. But their involvement from the beginning should be very, very high. So that we make sure that all those, I’ll call them nonfunctional requirements, but they are actually functional requirements because the business can’t operate unless we take care of those concerns.

Dan Neumann: [23:10]  You use the term SRE? He could you elaborate on what that is, Barry?

Barry Matheney: [23:15] Yeah, I’m sorry. So that’s a, it’s a Googleism I guess there is a role that they have, it’s called a site reliability engineer. Um, it’s effectively a shared group because again, you don’t need necessarily somebody on a Scrum team full time to play that role. So they come in part time and they, they, they mature the service to the point and it’s sometimes six months, sometimes it’s three years to the point where it becomes a operationalist I guess as I, if that’s a, if that’s a word, it’s probably not, but it’s probably something more along the lines of, um, it can go into standard operations mode. In other words, we’re not enhancing that product anymore. Right? So that’s when, when you start to talk about the SRE, handing it over to a run organization opposed to the team owning the product or the production support and the operational support of it.

Dan Neumann: [24:17]  Perfect. Thank you. So we’ve talked about the value of having the DevOps engineers working with the Scrum team or having that complete set of skills and the mindset. What are some sources of resistance that you see? So it sounds wonderful. Not Everybody’s doing it. So there must be some resistance somewhere. And I’d like to hear your thoughts on that.

Barry Matheney: [24:36] And that’s an interest. So the conversation to me is this is a software delivery problem, right? It’s not an operations problem. It’s not a development problem. It’s not a product problem. Um, it’s not a technical problem. It’s not a tools problem. But the challenge becomes, um, and I’m going to use this as an analogy, Dan, and you know how we, how we take this is what happens in a lot of software products is we deploy in VP and we get it to production that first time. And we didn’t do that heart. And I want, I don’t want to use the word hardening, but we didn’t do that maturation of the delivery process. And we continue to rely on those immature processes through the life of the product. And so the delivery capabilities are as functional and as what I’ve said before, as the, um, as the product features themselves, I can’t get the product feature to production in a, in a reliable, consistent way, predictable way, then I’ve defeated the purpose of what I was trying to get delivered anyway, right? There’s pain, and there’s, um, the practice becomes challenging. Deployments take days, those types of things, right? So there’s a group of people, you know, that those people that love to learn, they gravitate towards these things. But there are, you know, in certain environments there are people that have always found their net worth. And this is what something that I’ve always said, DevOps eliminates the hero syndrome, right? So if you have organizations that people thrive off the hero syndrome, it’s where you’re going to run into your resistance because you don’t, you don’t need the same number of heroes in a DevOps type of world than you do in others. That’s, that’s one big example for sure.

Dan Neumann: [26:30]  What you will you describe brought to mind? So we do cowboy coding, then we do manual testing and we deploy it into the snowflake environments and then we pat ourselves on the back because we avoided a disaster again. I mean that’s kind of the mental model that came mind.

Barry Matheney: [26:43] And so, and, and I love to tell the, my favorite metaphor is, you know, when we start managing hundreds or dozens or even more than one machine, we need this learn to treat them like cattle, right? Don’t treat them like a pet. I don’t want him to, I don’t want to nurse it back to hell. I want to take it out and put another one then that looked just like it, you know? So that’s the, that’s the best analogy I’ve ever heard in my life about treating environments like cattle rather than pets. And I think that goes right to the, if I’m treating them like cattle and I take one out of commission and put another one in, I didn’t need a special set of hero syndrome to make that happen.

Eric Landes: [27:22] Very nice. I would add to that Dan. The resistance I’ve seen, and this was, this was probably the hardest one from my perspective is more organizational. So as an organization we’re used to doing things a certain way. We have a DevOps group and we have this, so now when we have this DevOps group then we’ll certainly we should have a group and that should report to, you know, the director of operations or whoever that is. And so we’re going to make that a separate group just because of recording requirements. So organizational resistance is something I’ve seen and really getting around that is, is just showing the power of collaboration. And to Barry’s point, hey, we want this to work. We don’t like the snowflake environments. We don’t want 30 hour deployments over the weekend that there’s a cost there. Right. And so we can measure that and we can make the argument. Yeah, that’s, you don’t want to do that. Here’s why. Usually you get by them.

Dan Neumann: [28:22]  Yeah. So measuring and building your case with some actual facts and data about the cost of doing that. If you’re needing to be HIPA compliant, there’s costs to having a breach because something went wrong in an environment with your test data accidentally exposing things or whatever the case might be. So I like using the, the fact of that data. Well, thank you for exploring the topic of DevOps on agile teams, specifically Scrum teams is the framework we used for a lot of this conversation. And before we go, I’m curious if you could share as part of your continuous learning journey, what are some things that you’re reading and bringing value to your profession or the way you go about your work these days?

Barry Matheney: [29:06] So I’ll go first. I actually, one of the books I just finished was the Age of Agile. I know that I’ve heard other conversations about that. Steven Denning. Right. I can make a couple of recommendations that if people haven’t read, they are, they’re right in line with that actually and actually they marry up agile and DevOps really well. Um, probably everybody and their brothers heard of they so Lean Enterprise, that’s the Jez Humble book. Uh, how high performance organizations innovate at scale. And then I would also, if you haven’t heard them, Nicole Forsgren, uh, she is a phd with Gene Kim and Jez humble. They wrote a book called Accelerate the Science of Lean Software and DevOps Building and Scaling High Performance Technology Organizations. And that is a non technical book. If, if you’re a product owner, or leading an agile team in any way, I would highly recommend that you, that you get a copy of that.

Dan Neumann: [30:06]  Good. We’ll put a link to those different books then into the show notes at AgileThought.com/podcast people can find the show notes there. And then Eric, how about you?

Eric Landes: [30:17] Yeah, great question. I have really been listening to some, some older stuff really was kind of refreshing my mind with Outliers by Malcolm Gladwell. Kind of a classic and really, really just enjoy kind of remembering why that’s important and and applying that to agile and, and the Pixar Story, which to me really shows somebody using new technology and pushing forward and really you know, expanding boundaries. So I enjoy that. Not necessarily DevOps heavy at all, but those, that’s what I’m reading.

Dan Neumann: [30:56]  Yeah. We talk a lot about having t-shaped people on a team or you know, generalizing specialists and I find the same thing applicable when it comes to the information people are bringing in, whether it’s reading a book or blogs they are interested in or activities completely outside the realm of software delivery and business value. You find these interesting things that tie in and can give you a new perspective. So love the Pixar stories. Well thank you both for joining me today and look forward to continuing our conversation on DevOps and other day.

Dan Neumann: [31:27]  Thank you very much.

Both: [31:28] Thank you.

Outro: [31:33] 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.

Stay Up-To-Date