Scrum Cling-ons and Culture Shifts

Podcast Ep. 152: Scrum Cling-ons and Culture Shifts with Chris Pipito

Scrum Cling-ons and Culture Shifts
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

This week, Dan Neumann is joined by Chris Pipito, agile coach, to talk about Scrum cling-ons and culture shifts.

In this episode, Dan and Chris are talking about the aspects that cling to the Scrum framework and really impede organizations’ ability to shift cultures from where they were to a point where there are more agile stands using the Scrum structure. Dan and Chris dive deep into the roles of Scrum, the struggles faced when trying to achieve a culture shift, the real purpose of sprint reviews, and how to narrow stories (instead of splitting them) among other valuable inputs on the matter.

Listen on Apple Podcasts

Key Takeaways

  • The three roles of Scrum: The Scrum Master, Developers, and the Product Owner
    • Product and portfolio managers do not exist in Scrum
    • For anyone who does not fit into these three roles, there is a need to find a place in the organization where the employee’s skills can be applied and are valued
  • What is really a culture shift?
    • The team sizing is an important matter as well as not having the team departmentalized bureaucracy
    • The necessary organization needs to be in place for different departments to work together
    • In most organizations, people don’t even read the Scrum Guide and they work with people who don’t have the proper certifications either, then, as the result, the entire experience with Scrum and agile is not that satisfactory
  • The cling-ons make it easier not to change behaviors
    •  Is the team clear about the reasons why they are building something? What is the goal that the team is looking to achieve? Standardized forms sometimes do not contribute to the overall goal of a project
    • Are you talking directly with your customer?
    • What is really the point of the Sprint Review? To inspect the increment and respond to the new information
    • Teams who work on properly-sized stories check on the customer to make sure they are on the right path; this is much better than assuming they are right
    • Narrowing stories is different than splitting them; you need to keep the overall objective you are trying to achieve as well as all the different things that you will be able to do, then narrowing that to a “happy path” to build it, without missing the core functionality of what you are trying to reach
  • What are the challenges to be confronted in order to make a shift towards agility in an organization?
    • Regarding departments, the teams’ sizes need to be appropriate
    • Make sure you look for the skill sets that are needed in each team before just assigning one
    • Assess the resource allocation fallacy: It’s not about “getting the maximum utilization out of the fungible resources”
    • Tip to try in bigger organizations: One group could be separated and treated as if it is an entire organization and show them the results of what is coming up. Sometimes this might mean keeping “management” out

Mentioned in this Episode:

Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]

Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach, and agile expert, Dan Neumann.

Dan Neumann: [00:17] Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host Dan Neumann. And today I’m joined by Chris Pipito, who is an agile coach from outside of the AgileThought organization. And I want to welcome you and thank you for joining Chris.

Chris Pipito: [00:30] Thanks for having me Dan.

Dan Neumann: [00:32] The topic we’re going to be discussing today. We’re calling it Scrum, Cling-ons and culture shift. And see, this is where I get my nerd street credit. Isn’t quite legit, but you know, Klingons in star Trek. I always have to pause and like star Trek, star wars Klingons were in, in star Trek, but that’s not the Klingons we’re talking about today. We’re talking about the things that cling on to the Scrum framework and really impede organization’s ability to shift cultures from where they were to something with a more agile stance using the Scrum framework. So what comes to mind for you?

Chris Pipito: [01:12] Yeah, well, for me, a few of the top things would be like planning poker for estimation requirements meetings, the duration at which sprints are standardized to the two week format the story format itself, or a few that really caused some of the headache that aren’t necessarily pointed out in the Scrum guide, but kinda end up in practice anyway.

Dan Neumann: [01:38] Yeah, for sure. And I hear questions like, well, what does a business analyst to do in Scrum? What does a, you know, fill in the blank, do in Scrum and it’s not prescribed.

Chris Pipito: [01:52] Right. As we all know, the Scrum guide prescribes three rolls of Scrum, the Scrum master, the development team and the product owner. So product managers, portfolio managers, they don’t exist in Scrum. So if you’re going to use Scrum, you need to figure out where their skill sets of those people exist and how they fit into the Scrum model. And if they don’t, that goes to the culture side of things where the organization should be not looking to just get rid of these people, but trying to figure out if they can’t fit here, let’s help them find somewhere where they do.

Dan Neumann: [02:33]
And what comes up to mind for you when you think of a culture shift, what are you, what are you looking for as an agile coach? When you’re saying, Hey, these things maybe get in the way of a culture shift or don’t allow for a shift to something else. What kind of shift might you be looking for?

Chris Pipito: [02:47] Well, I guess on the team structure side of things the, the team sizing is a big deal, but also not having the departmentalized bureaucracy, I guess, would be a big one. So the development department, the product management department and the QA department, and then how they work together, isn’t really a team as much as it is groups where you the, the product management people get the requirements and how much I hate that word. And then they give it to the development team and say, build this and all the effort that went into gathering the requirements and building the BRD and specking it out and even providing screenshot level detail that it almost looks like it’s already inside the system. And then any of the team in that same, just build exactly what we told you to. And then the team builds it. Developers, let me clarify the development part of the team, builds that, and then chucks it over to all the QA and QA is now stuck in this gotcha kind of role, or they’re just trying to catch things and throw it back and forth between them and development. And then eventually the user gets to see it. And then when that happens, it’s usually when the aha moments happen for users, where they go, oh, well, now that I’ve seen it I don’t really like that. I don’t really like this and now I can’t take it at all. And that’s just pure dysfunction within the organization and it’s supported by those siloed departments. So the approach that I take to that is eliminate the departments and build the practice, the communities, right? The centers of excellence. If you would say that are communities of practice, if you would say that and build your teams with the skill sets from the departments and just eliminate the departments altogether.

Dan Neumann: [04:39] And I think what you’re describing is a fairly common pattern where we have the departments with their specialization. Then we select people. We organizations select people from those groups. They put them into an air quotes team together, but the silos still exist. The developers expect the analyst to hand them baked requirements, put a pin in it, we’ll call them user stories for now, but they’re really just requirements in a, in a different form. And then somewhere in the sprint, they hand off to the QA air quote team, even though they’re all on the same Scrum team. And, and we have things like code freezes, and we have challenges about how do we handle bugs. We find within the Sprints and it creates this bizarre set of behaviors that shouldn’t be happening in a, in a well-formed Scrum team, or we’re all actually moving together to move the ball down the field much like described in the new, new product development game, back in the eighties. So for some reason, 40 years later, we still haven’t quite got it.

Chris Pipito: [05:46] Yeah, it’s not it’s not ringing true. And there was trying to remember who it was and forgive me if I’m wrong. I think it was Jeff Patton who said to me it was probably sent to a bunch of people at this point, wait, we tried waterfall and we didn’t like it. Then we’ve tried agile. And we didn’t like it. I’m starting to think where the problem. And that’s a really interesting way to think about it because you come up with these and I’m not a big fan of the term, but these best practices or a way of doing things and you lay it all out and then people say, oh, that makes sense. But then you don’t do it. You find your reasons for making that fit your way. Well, then you’re not really trying to change anything. You’re just trying to make that fit your model. And it happens with Scrum consistently. I’m going to drop another quote here. I think it was Andy hunt who said agile has become, we do half of Scrum poorly and use JIRA. And that’s, that’s kind of what, what is happening out there. And then most organizations is people really don’t even read the Scrum guide, or if they do, they end up with someone who just barely has enough information or experience from the certification and they get in there and they try it, but then it gets morphed into something else. And then all the experience with Scrum is bad. And since people equate Scrum to agility, now agile is bad.

Dan Neumann: [07:24] There’s a lot of threads in there to pull on. Yeah, well, one, so, I mean, are the humans the problem? There’s a pretty good chance that the humans, the humans are a challenge and the work we’re trying to do is complex. We’re not pounding out widgets. We’re not making hamburgers at a fast food place. The work varies. And the people who are asking for something often don’t know what they actually want until they get it. And then they see something they’re like, oh, that’s, you know, that’s not quite what I meant. And so then we have to iterate. And so how can we shorten those feedback loops and shift from a backlog that’s composed of user stories, 300 deep, which is really just a requirements document in a different format to something where we’re truly identifying a product goal, which is what Scrum would advocate for. And then every sprint, we have a sprint goal that takes us closer to the product to goal. And we’re not just tearing the top of the backlog off, throwing it into the sprint and crapping out a status report at the end of the sprint.

Chris Pipito: [08:32] Right, right, right. That’s yeah, there is quite a lot to pull on. There that’s quite a lot.

Dan Neumann: [08:40] But, but these things are the, the, the Tagalongs that kind of coming back to our, our Scrum Klingons and a culture shift, this, these things that cling onto the Scrum framework, make it easy sometimes to not change behavior, we will have a requirement. We’re going to call it a user story. We’ll use the user story item type in JIRA or Azure DevOps or version one, or it doesn’t matter what tool. Right. Well, we’ll put it in a thing that says user story, but there’s no story. We haven’t shared a story to create a common understanding. We’ve just used the item type and a description field. Maybe the user story format that you refer to. I think affectionately is the cone format.

Chris Pipito: [09:24] Yeah. Well, it’s originally the connector format, but like Mike Cohn is kind of taken that ball and run with it. And I, I know I’ve, I’ve gone to classes with Mike Cohn and teaching user stories and, and how you use them. But I think part of, one of the things that comes the tag-alongs is that format that as a, I need, so I can format then it’s forced a lot where it just doesn’t fit all the time. And there’s often, often what I see is, is really dysfunctional is people drop the, so that if you’re going to use it well, that’s the why. And if you don’t understand why you’re building something, then again, why are you building it? What’s the objective, what’s the goal you’re looking to achieve? So yeah, that format has, I see it used poorly a lot as a developer. What are you doing? Why are you writing it that way? You’re, you’re not really the target here. So yeah, that, that standardized format as part of band practice and, and, ah, man, there I go again. So using that practice thing that, that I think forcing it is, is not exactly beneficial to anyone. I actually prefer that a lot of the of the teams that I work with prefer to put the why first. So it’s just, it’s terminology shift really in order to achieve this, or what’s the purpose of this, right? So the why doesn’t get lost. But that’s the formatting of a story. And I don’t want to get drunk too much down into that because I think the purpose of a story is really how you use it. You, you, you put the story out there and some quick sentence or two of what, what the objection objective is, or, or what their goal is, but then you have to have that conversation. That’s the promise of the story is to have the conversation with the user that ha that needs this thing. And oftentimes when you’re working within an organization who builds internal tools for internal users, like in accounting or marketing or so forth, the business analyst takes on the role of that, that user. And you don’t actually get to talk to them when you’re on the team. So you’re really disconnected there and that’s another dysfunction and the story format always comes in as an accountant. I want this thing, so do it. So do it, this kind of like what you end up with, there’s a disconnect.

Dan Neumann: [12:03] Yeah. I was a, I had the pleasure of interacting with a financial institution. And if, if people were seeing the video, you’d see an eye roll there because it’s rarely pleasurable to deal with a financial institution. And, and, and I had a need and I talked to a human actually on the phone and they were like, oh, well, this is no, that’s this other department you have to, you have to like, you can’t do that with us. You have to go into your local bank branch. And I’m like, I just want my problem solved, but I bet somewhere, there’s a user story that says, as a person on the phone, I need to X, Y, Z in the system. And, and somebody at the branch has a different need, but somewhere in the, we need to help our bank customers solve the problem that they’re trying, they’re trying to work through, got lost in this. And we’ve ended up with two sub optimized systems and a very confused bank customer from, from my standpoint. So we lose that story. We lose the, what we’re actually trying to achieve for, for a human being.

Chris Pipito: [13:08] I think all of that. Yeah. And I think often what the cause of that is, is when you’re, you’re not talking directly with your customer. So in larger organizations, it’s nearly impossible sometimes to really work in an agile way.

Dan Neumann: [13:28] Well, and I’m sorry, what I got excited about, and I’m afraid to cut you off was customers that are product owners, surrogates, this surrogate, that surrogate, we ended up with people in the middle and you’re right. It’s not developers and the business working together daily. It’s the developers talking to somebody who talks to somebody who talks to somebody who assumed they knew what the users want. I’m sorry.

Chris Pipito: [13:52] Yes, you’re absolutely right. It’s the whisper down the lane thing. So it’s the what was the name of the, I don’t even know if that was the name of a game we played telephone, telephone. That’s exactly what happens. And you only find out, like, I think I mentioned it before, but you only find out that you got it wrong or miss something when you reach your UAT acceptance phase. Right. and the user actually gets to see it, which is another dysfunction of the sprint review when you’re demoing your product to a user in the sprint review. If I go down that road, okay. First off, that’s not the point of the sprint review. If you’re going to use a demo type of thing in a sprint review, just have your user use your increment in front of you. And every time they have to ask you a question about how they do something, that’s a spot where you failed, because you didn’t build something intuitive enough for the user that asked to do the job to understand how to do their job, or to achieve their goal or whatever they’re using it for. So let’s see, send me down a path here.

Dan Neumann: [15:03] So you want your users to actually inspect the increment live and in front of you. That’s crazy talk.

Chris Pipito: [15:10] Isn’t it, isn’t it. Well, it’s, it’s definitely an agile way of working. And it’s the, it’s one of the main things out of XP. I, I love XP and you know, on-site customer is is a very difficult thing for larger organizations to grasp the concept though, because what they say is, well, what will my analyst do? I don’t know what else can they do? What skill sets do they have? How else can they help us? Are they subject matter experts that can, that have the user might understand what they need, but who understands how that impacts something downstream? Or if we do this, what else is it going to bother in the system or financial institutions or, or mortgage companies prefer example, you could change one thing upstream that drastically impacts another user way downstream this, you don’t have that knowledge on the team. Yes. I may have just built the perfect thing for this user, but I really just broke something for somebody else. And I don’t know about it yet, but that’s also another problem with monolithic systems, but that could be where a business analyst could be beneficial with their skillset and knowledge and experience to share those types of, Hey, did you consider this when trying to build that or what impact that has on this thing here? So, but ultimately you can get your answers from your users, and there’s a lot less risk involved in the the, you got the scope wrong, or their scope creep thing or the rework, if you just ask the user, I think one of the best things that, that I’ve experienced with being on teams or working or coaching teams is the teams that will proper size a story. And I don’t mean estimate proper size something that’s small enough. You can get through it. And within within a couple of days, really to deliver it. And while they’re doing that, they’ll ask the customer, Hey, can you take a look at this? We’re in the middle of building it, but can you take a look at this and make sure we’re on the right path? It’s definitely better than assuming you’re going down the right path, because that’s what the BRD said. And once you start working that way, you get away from the contracts, the, the whole I, I built what you told me to conversation, or the, the scope changed on us conversation or the, the the development team isn’t predictable or reliable, or, or they don’t deliver on time. That that relationship starts to crumble. When you have that transparency, transparency in the way that you work.

Dan Neumann: [18:18] Touched on something in there that I wanted to see if we can we can pull on some of them get a running start at it. We’ve got you talked about the user stories. And if the four, if user stories if telling a story about what the user wants, make sense, do that. If throwing a task in the product backlog, because it’s something that has to get done is what’s appropriate do that, right. It, we don’t have to force fit things into the user story format because yeah, because we just, don’t right. Not, not part of Scrum. And then you talked about the onsite customer and extreme programming characteristic, which is super handy in Scrum, Scrum, doesn’t say don’t do XP practices. So, okay. Maybe we have an onsite customer. Maybe we show them things as we go throughout the sprint, as opposed to let’s invite the customer in, at the end of the sprint to show them in a sprint review. And like, I liked that you are not calling it a demo, right? It is a sprint review it’s to inspect an increment it’s to get feedback it’s to respond, to change, and we expect change. It’s not scope creep. It’s learning it’s Hey, we thought we wanted this. We see it. Oh, here’s a hangup. I didn’t know. And couldn’t have known, and the analyst couldn’t have figured it out. So let’s just move fast, show somebody, something, get feedback, and figure out where we go next. And, and you mentioned having proper sized stories as a, an enabler for that stories that can be delivered in small slices, many of them per sprint, typically.

Chris Pipito: [20:00] Right. And, and it’s I think where people, miss story splitting is more along the lines of I think they, they approach story splitting and the term maybe needs to change. I recently had this conversation with Alan Holub and he uses the term narrowing rather than splitting, because a lot of things that people do are they take a story. And I’m trying to, I’m going to steal this from somebody. And hopefully I remember who said it, they use a really great example of a Rubik’s cube versus apple. And when you have BRDs and things are requirement’s people take the splitting stories that are built that way, like splitting a Rubik’s cube. If you break out the Rubik’s cube and do a bunch of different schools, their own squares, and you build that square, that’s not deliverable because I can’t use it it’s by itself. But if I sliced an apple and I took one slice of apple and threw the rest of the apple away, I can still eat that slice of apple and get the essence of apple. Right. I know I’m eating apple, but you could build the entire Rubik’s cube, split out that way and leave out the bottom square. And I still can’t use it. So when you’re narrowing a story, what you want to do is take what’s the overall objective of what they’re trying to get to and all the different things that they’re going to be able to do, and narrow it down to the, I know people like to use the term happy path to build it, but what’s the core functionality of what they need to do. That can be so freeing to have the team look at that and say, well, I don’t have to nail it all the way up to scale version of, of production ready, working software. I can hard-code and mock some data and show it to them within a few hours and know that this is the right way to go and then complete it and deliver that that’s a better way of working, I think, than trying to get all of the different pieces of functionality of the Rubik’s cube built out in like, oh, the button needs to be this color. And when I click it, it does this. Okay. But what’s the end goal. Like I see stories and to build the button, okay, I’m glad I got a button. What can I do with it? Nothing but, well, that’s not a story. That’s a piece of something of a whole, or the whole loop. I just drop that one, a piece of a whole thing.

Dan Neumann: [22:52] I love it. And so I like the term a narrowing. So narrow the story down to something that still captures the essence of what you’re trying to do. It’s not about the button and its color and its position. It’s about when, when a user engages with it, do they get the result that solves their problem? I don’t care how many pixels around the button and the shading and the CSS, blah, blah, blah, blah, blah. I want to know what, if I click the ugly button, can I achieve my business goal? Like, I’ll take an ugly button that gets me my business goal, and then we can pretty it up afterwards. I love that the terminology of narrowing, the focus of, of the backlog item to deliver the essence of what the customer actually cares about.

Dan Neumann: [23:35] Yeah. And I can, I can give an example. One of the teams that I worked with recently had a, a story of, and this is industry specific, but it’s okay. Where they have to add, what’s called suspense conditions to alone. Something’s wrong with the loan. So we have to suspend that temporarily. And so we get some piece of information. Well, in that process, they have to decide what’s the suspense condition that it falls under. They have to act, they have, have the ability to add a comment as to why it’s there. If they add an error, they have to be able to clear that error. When it clears, they have to be able to clear the suspense condition completely because now it’s fixed. It has to go to somebody else for some other piece of the workflow. Well, if you try to build that, all of it at one shot, you’re going to have pain. It’s going to take a long time. There’s a lot of connected parts that would have to come together. So why not just say you can add the suspense condition. Can’t add a comment. You can’t pick an activity type that goes with it. You can’t clear it. You can’t say that you added it in error. Just give them the ability to add it. Well, now I just narrowed down the scope of the story. If you’re using scope, it just narrowed it down and gave them their core functionality. What’s it take to build that? A day or two? Okay. So within a day or two, we can show them that we can give them that, and then we can ask them, okay, what’s the next, most important part of this workflow? So we have your flow. We’ve mapped it out. Story maps are fantastic, but we’ve mapped out your flow. What’s the most important thing you need first. Okay, let’s do that. Now. What’s the most important thing. And now that you’ve seen that? When you have that transparency with your customer, that also leads away from that problem. We talked about earlier, where they’d only see if you built the whole thing over your two week timeframe. If that was your time box and delivered it to them. And you, even, if you had all the functionality, they might then be saying, oh, well, not this way, that way, not that way, this way. And that’s not bad, but if you involve them earlier then you could have avoided that.

Dan Neumann: [25:55] No, I love, I love the example and there’s elements in there of do, do a slice, get the feedback, discover what’s next, most important when the clock runs out, you know, you’ve, you’ve still had different slices of your apple or your different pieces of the apple. And maybe you’re not completely full, but you’re not as hungry as you were at the beginning. Whereas I was literally the kid who had popped the squares off as a Rubik’s cube and put it back on to solve it because I couldn’t figure it out any other way. But yeah, when the bus ride to school was over and I only had half the Rubik’s cube pieces popped back in, I didn’t have a toy. I was like, darn my timebox expired of my bus ride. And I have nothing to show for it, except pieces I’m going to lose in school. So I’m right there with you literally on the Rubik’s cube example.

Chris Pipito: [26:46] Yeah. And sometimes, and sometimes just the last close that out. Sometimes you don’t have to build the rest of the apple. Right, right. They’ve used it. And that that’s enough. Let’s move on to this other thing. That’s more important now than giving me a common feature on that. Right.

Dan Neumann: [27:03] Exactly. Exactly. So let’s touch let’s circle back cause we’re just kind of speaking of timebox, it’s kind of looking at our general timeframe here, the culture pieces. I want to kind of connect some things back to, to culture shift with these little Scrum cling ons that we have of user stories. And we didn’t maybe name it explicitly, but there were nods to things like refinement and some of the roles of what do we do with the analysts. Do we have a QA team within the Scrum team, all of these things. So when you’re trying to make a shift with an organization and then the stuff that’s floating around, the Scrum framework clinging onto the Scrum framework comes in, what challenges does that make for you? And then maybe what are some of the strategies you’ve seen to, to knock some of those Klingons off and really get back to, are we making a shift towards more agility?

Chris Pipito: [28:03] Well, I guess the there’s so many, there’s really so many to think about. As far as the, the shift goes, when you have the, I guess thinking with a department based thing where you have a QA department and development department, a project management department when you try and remove those silos, first off, the team size has to be appropriate. You can’t have 20 people, it just won’t work. There’s too many lines of communication. I think it’s what does it stops at 14 or when you’re using that? I can’t remember the name of the graph that has that whole thing laid out that spider map kind of thing. 14 people is 96 lines of communication or whatnot.

Dan Neumann: [28:55] It explodes.

Chris Pipito: [28:56] Right. So team sizes is, is really important for that. But you have to, you have to try and look across your departments and say, okay, what skill sets do we need for, to formulate this team? And one of the big culture shift things that I like to use is instead of talking to middle management or leadership, executive management, and saying, okay, who should we put where? When you have a large team that you’re trying to split and you ask them, these are the different products that are in this, in the system, where do you want to go? We we’re trying to have a team less than 10 people. I know some people like to have a specific format, like a X number of development to X number of QA to X number of analysts. Okay. Again, analyst isn’t in Scrum, but okay. But you want to try and get that that going instead of assigning them to a product and that’s a product versus project thinking, but instead of assigning people to it and saying, this is the team, you will work on, ask them where they think they fit best. Obviously you might end up with like, okay, well I have 15 people all on this one and nobody’s over here. So, so you give them the opportunity to say, okay, look, obviously what we’re trying to do here is make it a cross-functional self-managing team. You guys know what your skill sets are, who would rather go over here now, like she was going to flex worse there and really give it to them to make that decision on who’s going to work together on what product.

Dan Neumann: [30:34] Yeah. Like we know, we know Dan’s on the team, but like somebody, you still, somebody who’s gotta take one for the team and go, go work over there with him. I know.

Chris Pipito: [30:44] Right. And one of the best practices that I’ve seen work, man, I’m good at again, one of the best things that I’ve seen work that teams implement is mob program or ensemble programming because it literally starts to break down that silo. And, and also it’s, it’s working on the same thing. You’re working on the objective that you’re working on, whatever that goal is. One at a time it’s not, you’re not scattered gathered, right? You’re not okay. Dan, you take this story and go code that. And then I’m going to take this story and go code that. And then when we’re ready, we’ll call on this person who is our QA person. And they’ll start testing. Whoever gets to them first, that’s not a team, even if it’s properly sized, that’s not a team that’s, you’re still working in the same silos. So implementing things like mob programming, ensemble, programming even pairing is one way to start to break down those silos. And some of the big concerns that you run up against when you try and implement something like that to shift culture into a team kind of environment is the resource allocation fallacy, right? Like, oh, well what are, what are you doing if I’m coding it? And you’re sitting there,

Dan Neumann: [32:05] Oh yeah, we’re not getting the maximum utilization fungible resources.

Chris Pipito: [32:11] Right? So those conversations are really, really difficult to have. When’s when, especially in the larger organizations, that’s why most larger organizations can not move this way. They can not make that shift because they have too much bureaucracy in them. And they’re so set in their ways. They can’t even imagine the possibility of what would happen and you have to have the conversations around, okay, well, the way we’re working now, you have code reviews. You have quality in their own silo. Nobody talks to each other and it’s taking you X amount of time to get something out the door. And one of your biggest concerns are your deployment frequency and your quality, right? So if we put them together on a story and we, right-size the story, not write an estimate right size, and we get it out the door within a few days, well, now we’re deploying faster and we’ve had more eyes on it. So we don’t have to spend time on code review. It’s not a separate exercise. And the quality was thought of while we were building, right? Like, so you’re eliminating these problems and you don’t have to think of it. Like we’re not usually utilizing our resources to the best, right. A hundred percent capacity. So you have to show at work essentially is what it is. And the, the large organizations I’ve been successful taking one group and literally almost separating them out as if they were an entirely different organization, not letting management in just showing them the results of what’s coming out right here. You can know what we’re working on, and this is how often we deliver. And then our quality is increased and things of that nature. But if you try and do it as the whole, all your own from engineering, it’s going to be an uphill battle the whole way.

Dan Neumann: [34:12] Yeah. So some of the patterns that you were describing in there was, was moving together. And in fact, one manifestation of moving together as moving those people out to be in a bubble, if you will an operating bubble so that they don’t have the weight of how the organization is used to operating and continuing to kind of pull it back into the organization. And I love the, the ensemble programming term. I’m familiar with mob programming. I think the, the term ensemble is a little more artistic and less, less pitchforks and torches. So I, I like that.

Chris Pipito: [34:51] It’s starting to move in that direction.

Dan Neumann: [34:54] I like it. Well, we inspect and adapt, right? Why would I want a mob running around my organization? Yes, that’s perfect. Well, I want to appreciate you taking some time, Chris and sharing about the, the Scrum cling ons and some of the ways that you try to influence a culture shift in an organization from kind of where they are to a more, more agile stance. So thank you very much for doing this. And I know there, the list of cling ons is long and distinguished and perhaps there’ll be a chance we can pull a few more of those apart and figure out how to handle them in a future episode.

Chris Pipito: [35:30] Yeah. Yeah. And actually look forward to that. Thank you. I did want to share though a couple of things because what am I reading?

Dan Neumann: [35:40]
What are you reading?

Chris Pipito: [35:42] Right now I’ve actually gotten into a reading the fifth discipline. That’s the art and practice of a learning organization from Peter Singe. But I just finished actually reading mob programming from what he’s all. And that is a good, that is a good read as well. So I’d recommend that.

Dan Neumann: [36:01] Very good. I apologize for almost not pulling on that thread. So 5th discipline and mob programming, and I know Woody is a very regular conference speaker on the topic, but I have not, I’ve not read the book. I’ve seen him talk and, and would, would do that anytime.

Chris Pipito: [36:19] Yeah. The book’s actually on a leanpub, I believe.

Dan Neumann: [36:22] Perfect. A nice format where, when he updates the book, you get the updates for free. You don’t have to go buy version two when it gets updated. So super cool. Yeah. Folks not familiar with lean bub, definitely check that out. And we’ll, we’ll put a link to those books in the show notes.

Chris Pipito: [36:37] Yeah, absolutely.

Dan Neumann: [36:38] Awesome. Thanks again, Chris. Really appreciate you taking the time.

Chris Pipito: [36:42] Yep. Thanks Dan.

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

Stay Up-To-Date