podcast-ep-52-featured-image

Podcast Ep. 52: Anti-Patterns That Interfere with or Prevent Good Scaling in Scrum

podcast-ep-52-featured-image
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

Today’s episode of the Agile Coaches’ Corner podcast marks the first anniversary of the start of the podcast. In celebration of this special mark, host Dan Neumann and his collaborator, Sam Falco, are taking a look back at the very first episode: “Do Scrum Well Before Scaling!”

Tune in to hear Dan and Sam’s anti-patterns around scaling in Scrum and some of their solutions on how to address or stop them before they start.


Listen on Google Play Music

 

 

Key Takeaways:

  • Anti-patterns that interfere with or prevent good scaling:
    • Not having a Sprint goal; not having one clear goal for the Sprint that is understood by everybody (which ends up creating a laundry list of items that are not tied together which can create unrealistic expectations about delivery)
    • Having two Sprint goals (which causes a lack of focus)“If you aim at two goals you won’t hit either of them.”
    • That everything doesn’t have to be integrated or can be integrated after a few Sprints (this can be a side effect of not having a clear Sprint goal), which creates risk build-up
    • If everything is not integrated, technical debt will bring things to a grinding halt and create a mountain of undone work
    • A lack of automated testing and thinking you can build out the unit tests and automated functional tests later, even though later might never happen or, by the time you get to it, the effort becomes far too large
  • Team dysfunctions and anti-patterns that affect scaling:
    • Not making the impediments visibleif you make the impediments and dependencies visible and communicate in-person this can be resolved fast
    • A common dysfunction in beginning Scrum teams is this concept that individuals own the product backlog items which leads to siloed work (which, in turn, can lead to not getting things done because the team takes on more than it can handle and cannot coordinate properly)
    • Assigning stories to individual developers (when it is actually much more effective to leave the PBI unassigned or assigned to the Product Owner)
    • Multiple Product Owners for an individual Scrum team (you only want one, but if there are multiple ones in a scaled environment they should be aligned)

 

 

Mentioned in this Episode

 

Sam Falco’s Book Pick:


Transcript [This transcript is auto-generated and not 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, I’m Dan Neumann and joined today by my colleague, Sam Falco.

Sam Falco: [00:24] Howdy Dan.

Dan Neumann: [00:24]  Howdy. So usually we end the episodes with a little bit of what are you reading that has you inspired? And I thought I would actually start with something I read that had me inspired, which is we had an email from one of the listeners who posed a question about, hey, why should we continue to improve? We’re doing Scrum already, and this wasn’t their question, it was kind of a scenario that they run into, which has me inspired to think more deeply about that topic. So that’s what got me thinking. And in probably a couple episodes, maybe two to three, we should be releasing an episode, kind of addressing that and sharing some ideas.

Sam Falco: [01:06] Cool. Looking forward to that.

Dan Neumann: [01:07]  Good. Because you’re on it too.

Sam Falco: [01:09] Oh, awesome.

Dan Neumann: [01:10]  But enough with that. We’ll get to Sam’s book at the end. And this is the 52nd episode. Yeah. About a year ago we started this podcast and we’ve made it a year.

Sam Falco: [01:22] Yeah. Congratulations.

Dan Neumann: [01:23]  What should we talk about today, Sam?

Sam Falco: [01:25] Well, the very first episode was about doing Scrum well before scaling. And so, I thought we could revisit that topic a little bit, but from a slightly different angle this time. What anti-patterns do we see that can interfere with or prevent good scaling?

Dan Neumann: [01:43]  Excellent. And uh, we will provide some ideas where they’re not self-evident. I’ll tell you what to do about those anti-patterns.

Sam Falco: [01:52] Don’t do that.

Dan Neumann: [01:55]  Yeah. My math teacher, we could end the proof when it was a self-evident truth back in school and uh, by just tried to draw that line a little too early sometimes. So, we’ll, uh, we’ll see how that applies to podcasting too. So, some anti-patterns that get in the way of scaling Scrum and specifically Scrum in this case, not general agility.

Sam Falco: [02:17] I think specifically Scrum since that was what we talked about before. Um, although some of these may apply on a more broad arena.

Dan Neumann: [02:26]  Fair enough. Fair enough. Well, let’s get started.

Sam Falco: [02:29] Sure. So I think the first thing that comes to mind is not having a Sprint goal, not having one clear goal for the Sprint that is, uh, understood by everybody. Um, that can be either not stating a Sprint goal or having multiple Sprint goals. So our Sprint goal for this Sprint is to do this thing and also our Sprint goal is to do this other thing and if we get lucky and have time, we’ll do this other thing. So it becomes very unclear as to what the, what the focus is.

Dan Neumann: [03:04]  Now I recall having been at the Scrum thing for a while, it’s still not perfect at it, but having been at it a while the Sprint goal wasn’t always a thing in the Scrum guide. And I’m sure as a young Scrum Master I was guilty of using the term like commitment for the product backlog items or user stories in the Sprint and really kind of probably misusing that. So there was no unifying theme to the Sprint.

Sam Falco: [03:31] Yeah, it’s interesting, um, I don’t know. I have, I actually have copies of all of the Scrum guides and the draft that was circulated in like 2010 but I, I don’t have them handy. But I did look, I was recently looking back through my stuff and I still have the uh, CSM student workbook that I used in the class I took with Mike Kone way back when and there was a section where he talks about having a unified Sprint goal and that it is not a laundry list of things. So that has been around for a while. But you’re right, it seems as though previously before they changed commitment to forecast, there was at least a perception that what you did is select a bunch of product backlog items and say we’re going to do all these things and somewhere along the line and, and I was under that misunderstanding for a long time. Somewhere along the line that that focus to know you are, you are creating something specific became more evident.

Dan Neumann: [04:35]  Yeah. And I like having the Sprint goal as a focus because that gives you a lever to negotiate with the Product Owner when things are either moving faster or more slowly than the team would anticipate in the Sprint. And by the way, it always moves faster or slower or never on exactly the pace. And so it gives us some opportunity to negotiate some extra scope in or out or different ways of satisfying that Sprint goal and not disappointing people when you don’t deliver all the product backlog items that you asked forecast.

Sam Falco: [05:09] Absolutely. I remember my first Scrum team would just drive, we would drive ourselves to distraction trying to figure out why we weren’t getting all of the PBIs done. And so then we, you know, leave space or uh, you know, all the, the various ways of trying to make that happen. And, um, the problem in a scaling environment of course is if that is your approach, then it becomes a huge, big deal if you don’t deliver all of the PBIs you’ve committed to. Whereas if you have a unifying Sprint goal for the increment, for the integrated increment, and that’s important. It’s not just my Scrum team’s Sprint goal, it should be a Sprint goal for, for the integrated increment that you’re trying to create together. Everybody is working towards that. They’re collaborating towards that. As you said, there can be some negotiation, uh, there can be some trade offs made and you get a much more flexible approach.

Dan Neumann: [06:07]  Yeah. And I think that’s a really important key and thank you for amplifying that is you, other teams are expecting you to deliver on the Sprint goal and it’s a disruption to the entire system. If that Sprint goal isn’t met now, it could be met to different degrees or different levels of sophistication or speed or whatever, but delivering on that Sprint goal helps keep everything in sync. And, and then what’s wrong with two Sprint goals? I got, I’ve got a general theory that if we have two Sprint goals, the Sprint may be too long and we should be doing shorter Sprints, possibly.

Sam Falco: [06:41] Yeah. Uh, it, it causes that lack of focus. Part of the reason to have a Sprint goal is to have a common focus. Well, if you have two goals, well what are you doing? Which one is more important? Um, well this one’s too difficult, so I’m going to do the other one. It just causes a problem with the ability to live that Scrum value of focus.

Dan Neumann: [07:06]  Fair enough. Yeah. Something about if you aim at two goals, he’ll hit neither of them or something like that comes to mind for sure. All right, so having a Sprint goal, a single Sprint goal and achieving that helps with the scaling effort. For sure. Yeah.

Sam Falco: [07:21] Yeah. And uh, I want to circle back on that again. The idea is, at least in professional Scrum as you and I coach it, it is that integrated increment among all the teams. So there are some scaling Frameworks that say, Oh, well you integrate all your work after a few Sprints, or everything doesn’t have to be integrated every Sprint. And I think that’s a bad practice. And that is maybe a side effect of not having a clear Sprint goal. Everybody is working together towards one thing.

Dan Neumann: [07:54]  Yeah. And Scrum does things well with pulling all the risk forward. And guess what, if you’re working on code with a bunch of other teams and you are not integrating it, you are just letting risk pile up in the system. So to recap, one of the anti-patterns is really all tied into the lack of a Sprint goal. So that creates misbehavior, like having just a laundry list of items to deliver that aren’t tied together, which can easily lead to unrealistic expectations about delivery. We can end up not delivering, especially in a scaled environment where we’re failing to integrate the increment because at the end of the Sprint, if we’re not tying it all together, when are you going to tie it together? And that just lets risk build up in the system. That Sprint goal really is pretty critical.

Sam Falco: [08:44] Yeah. Yeah. And what could also be a factor is technical debt. So technical debt is bad enough on a single team. Technical debt means that you have to spend more time and energy shoring up weaknesses, then creating new software. When you bring it to a program level where you have multiple teams or scaled effort, it will bring you to a grinding halt very quickly, regardless of who quote unquote owns the technical debt, whether, you know, set aside the finger-pointing that could occur, that’s your team’s problem. Regardless, someone’s got to solve it and it becomes much harder to get that solved. Especially if you have multiple teams creating technical debt. Now you’ve got this mountain of undone work that needs to be handled and it can lead to a loss of transparency into the state of that integrated increment. And whether or not you’re actually releasable.

Dan Neumann: [09:45]  Somebody used a nice metaphor, uh, recently when I was talking to them and they said, Hey, you know, if we’re playing football and we’re out there in sneakers we’ll be slipping and sliding around and you know, if you’re playing a team that has cleats, they’re going to have a much better advantage. Um, you know, so even if they’ve got the same plays and skilled players and so we talk about people and interactions over processes and tools, but this technical debt piece is a nice place where tools can compliment those people in interactions, you know? The equivalent of giving them cleats and so tools that can inspect the code. Uh, my SonarCube is one example, so you can expect the inspect the code and give you pointers that where you’ve got technical debt accumulating in the system.

Sam Falco: [10:31] Sure. Just something like a good automated test suite so that you don’t spend an enormous amount of time on regression testing. You can have that happen every time there’s a check in or you know, run it over night if you have a, a massive amount of regression testing to be done etc. You don’t have one person that’s responsible for just tediously going through a bunch of stuff.

Dan Neumann: [10:53]  The lack of automated testing that you were mentioning to me seems like it might be it’s own class of dysfunction in scaling this expectation that we can have 5, 12, 15, 20 teams all working on the same large program of work and expect that to be manually validated when we’re integrating frequently. It’s just you can’t scale effectively without a level of automation that gives you the confidence and the assurance that we haven’t broken something very badly. It’s different teams. It’s just not humanly possible.

Sam Falco: [11:30] Yeah. Just even on a single team, my first Scrum team, I was joint Scrum Master and QA lead and as we added material and capabilities to the software, it became harder and harder to get all the regression testing done. Uh, just because, and it was just one team. And so yeah, you multiply that by multiple teams and you’ve got yourself a big problem.

Dan Neumann: [11:57]  Yeah. And the related dysfunction I think is, we’ll put it on later. So we will build out the unit tests later. We’ll build the automated functional tests later. Well, you know, later might never happen.

Sam Falco: [12:08] Or by the time it does, the effort is so enormous that it puts you behind quite a bit. So that team, we eventually did build an automated test suite, but by then it was um, I believe my test engineers and I kind of did a rough sketch of what it would take to get all of our tests automated and it was like a year’s worth of work. and of course the product wasn’t going to sit still for a year while we did that.

Dan Neumann: [12:49]  So getting visibility to where the technical debt’s accumulating and applying some level of capacity to addressing that technical debt so that you don’t end up needing to replatform in a few years, which is kind of the, the most common pattern I’ve seen. Oh, the old pattern that the old code’s too difficult to maintain anymore. We need to replatform. And those projects are notoriously difficult to deliver.

Sam Falco: [13:13] And ridiculously expensive.

Dan Neumann: [13:17]  Yes. Maybe you should spend some of that money on automation and regression suite and maintaining the technical debt. Cool. So let’s talk about the people. You know, people in interactions over processes and tools to deliver solutions. I don’t know, some people seem to do okay with this thing. This agile thing seems like it’s catching on. So team dysfunctions can also affect scaling. One anti-pattern that comes to mind specifically was the team that was impeded by somebody in their very large program of work and when I inquired, well, where is this team that is impeding you? And they said, well, they’re down the hall. We sent them an email. But I thought, did you go down and talk to them by chance? Do they know? You know, and uh, little sneaker net. So they started walking down the hall more. That helped. And then making the impediments visible on the outside of the cube. So they actually created a little chart with what team and what impediment they had with them. And it was amazing how fast they got resolved because leadership would walk by and go, Oh, why are you impeded? What? Tell me more about that. And um, I think in an appropriate way could help make those go away.

Sam Falco: [14:32] Sure. Making the impediments visible. Also making dependencies visible. You’ve, you’ve got dependencies in your backlog, undoubtedly make it visible that one team is going to be dependent on another. Try to mitigate those dependencies by bringing the work to a different team, so, you know, team A is dependent on team B, maybe team A can do both things that uh, so that they remove that dependency or where that’s not possible. Just make it visible so that we know that team A can’t start on something until team B delivers its thing. And so that needs to be a higher priority for that. For team B.

Dan Neumann: [15:12]  I love that. And even in a large scaled environment, you can make a physical representation of the work and the teams and the dependencies that yarn is amazing for physically tying together two sticky notes. On a very large visible port.

Sam Falco: [15:28] Yeah. Although it can get out of hand. I have seen a some yard walls that looked like Joanne fabrics threw up on it.

Dan Neumann: [15:38]  But does the code look like it also was a seasickness victim? Maybe that’s an opportunity.

Sam Falco: [15:45] Well it is. It’s an opportunity if you see a dependency wall that is that complicated, uh, rather than throwing up your hands and saying, yeah, we can never solve this or that’s just the way it is. Alright, look at that. What can you do to mitigate that dependency or your code will look like that.

Dan Neumann: [16:04]  Yeah, and eliminate is my favorite. Yes. Yes, for sure. Alright, so one team dysfunction is largely related to communication. Emails are the worst. Um, finding ways to be more like two people at a whiteboard is a great way to work around that.

Sam Falco: [16:21] Absolutely.

Dan Neumann: [16:22]  Should we talk about siloed work next?

Sam Falco: [16:25] Yes. So this is a common dysfunction I see in beginning Scrum teams, but some teams never, well, I hate to say never solve it, but don’t solve it or don’t think it’s necessary to solve it and this is the idea that individuals own the product backlog items. So the team, even if they have a Sprint goal, it’s a, you know, Raj owns this, uh, particular backlog item while, um, you know, Selena owns this one and they’re not working together, they’re working on their own little things and maybe they get them all done and maybe they get them all incremented, but it’s not a team effort. And that can lead to well, well it leads eventually to not getting things done because the team will eventually take on more than it can really handle and not know how to coordinate. Now again, scale that. Well now you’ve got instead of one team of say six people who are all siloed, you’ve got say 10 teams of six people who are all doing individual work. So you get, you get 60 PBIs in flight at any given time and no ability for people to coordinate with each other or problem solve together. And um, that also can slow things down.

Dan Neumann: [17:40]  It absolutely will slow things down. One notion that could help there, in Scrum sometimes limiting WIP isn’t explicitly done as it would be in a Kanban environment, but you can still limit WIP in Scrum, it’s a heck of an idea. And one way to kind of force or encourage, which is a nicer way or create an environment in which people collaborate with each other, is to have your WIP limit less than the number of, let’s say, development specialists. So if you’ve got four developers and three of your PBIs can be in development at any time. Gosh, I would expect there should be some collaboration. So there’s some ways to try and get the team to buy into that type of approach.

Sam Falco: [18:23] Absolutely. I would even go so far as to say, set your WIP limit to one PBI in flight at any given time. That is going to force everybody to collaborate. It’s also going to encourage you to write stories and slice them in such a way that an entire team can work on them.

Dan Neumann: [18:40]  Yes, I like that and that’s a good reminder. The last episode or the prior episode of this one is about getting things to done within a Sprint too and so there may be some other ideas for folks in there. Something that we’ve also done at times is, you know with some Scrum teams they say, you know, let’s say Sam, let’s pretend Sam, you and I are still developing and I would take one of the stories and assign it to myself in whatever tool du jour we’re using and you would do the same and now it’s a little bit like a dog marking his territory. It’s like this is my story. That’s your story, and we’ve now clearly staked out our turf and what I’ve seen be more effective than that is leaving the the PBI assigned to the Product Owner or the BA or the person who’s going to answer questions about what the acceptance criteria might be and then as we’re identifying tasks, maybe those are picked up by individual developers or not, but kind of leaving that PBI clearly owned by the business function.

Sam Falco: [19:40] I like that idea. I usually just say leave them on assigned unless there is some reason like the tool just won’t, won’t show you the PBI if it doesn’t have somebody’s name on it. But yeah, the tasks should be owned by individuals or could be owned by an individual. I would hate to say should because there’s pairing and there’s mobbing and, and all those nifty little things that have, uh, arisen in the years since I was developing. Um, I won’t tell you which version of visual basic that was.

Dan Neumann: [20:10]  I had, I had to laugh. My son sent me a video from his college class today and they were running it on a Texas instruments machines circa 83. And it was like line 110, you know, play the sound. And it was, ah, it was a blast from the past. Uh, so, Hey, reminiscing aside. Yeah. The example I was thinking of works really well in a scenario where you have multiple business people to talk to about the PBIs, which I think is a nice segue into one dysfunction is multiple product owners for an individual Scrum.

Sam Falco: [20:47] Yeah, of course. And we talked about this in the Product Owner deep dive that you and I did a few episodes back. Um, you want one Product Owner, one single source of truth. Now in a scaled situation, depending on what scaling Framework using that might not, you might have multiple Product Owners for the product. Uh, Nexus says no, one Product Owner for three to nine teams. Uh, that’s, that’s all you get a, that Product Owner may need help, may, uh, have of helpers or whatnot. But if there’s one Product Owner, um, things like Scrum at scale uses the chief Product Owner with Product Owners, then collaborating with the chief Product Owner who’s setting the central vision. And that’s not necessarily a dysfunction. It becomes a dysfunction when people aren’t clear on the direction of the product, they’re not clear on who they need to go to for answers. So that could be perhaps a dysfunction within your Product Owner organization where they’re not aligned. So certainly if there are multiple Product Owners in a scaled environment like that, you want to make sure they’re aligned.

Dan Neumann: [21:59]  Yeah, it’s a real hindrance to teams if your stakeholders aren’t aligned or the Product Owners in this example. But I, I think of a scenario where you have multiple stakeholders, some of which who may not be excited about their thing isn’t getting attention right now. And, and really being keen to look out for that kind of dysfunction. And if they’re not aligned, you need to create alignment. And not everybody has to agree, but they have to at least support the decisions that are being made and not undermine the teams and the Product Owners in the process.

Sam Falco: [22:34] Right. Stakeholders stepping in and trying to overrule a single Product Owner on a single team scale is bad enough. But once again, any of those dysfunctions or problems in single team Scrum at scale are magnified exponentially. So if you have a stakeholder that goes to a team and says, Hey, could you work on this thing for me? That could collapse your entire integrated increment because now the thing that really needed to happen isn’t happening for the other teams to get their work done. So that is crucial.

Dan Neumann: [23:07]  And I think that’s a great opportunity to just point out this is a thing that fits squarely into the responsibilities of the Scrum Master coaching, the organization, coaching the Product Owner. Bringing in techniques for building alignment amongst those folks. It’s an extremely valuable skill set for a Scrum Master to have and to teach to those involved. So four of the anti-patterns that can impact scaling and need to be addressed are around having a Sprint goal that can be delivered each Sprint. Having technical debt that’s accumulating and slowing down teams and grinding the system to a halt. We talked about some team dysfunction, some of the interpersonal stuff and then challenges around the Product Ownership side of the Scrum Framework as well. So kind of four general classes of dysfunction.

Sam Falco: [23:59] Right. Which of course are you know, not the only types of dysfunctions that can cause you problems with scaling. I’m sure our listeners have encountered some other ones that we didn’t cover here, so I encourage you, if you have something you’d like us to talk about, let us know.

Dan Neumann: [24:14]  Look forward to hearing yes and podcast@agilethought.com or they can tweet it with the #AgileThoughtpodcast. And so I read short form. So I read the email and I was inspired by that, the scenario that was posed to us. And I, I’m laughing about my own inability to read long form at times. And so Sam, what has you inspired these days that you’re reading?

Sam Falco: [24:41] So my latest read is a new book called Mastering Professional Scrum by Stephanie Ockerman and Simon Reindle. They are Professional Scrum Trainers with Scrum.org and have written this book not specifically for the Scrum Master but for anyone working on a Scrum team. And I’m not very far into it. Like I said, it just came out so I haven’t gotten into it very deeply, but it’s very insightful on ways to continually improve your Scrum practice. Um, team dynamics and uh, all of the things that go into making a Scrum team be able to deliver done increments. So highly recommend that to any of our listeners who want to know how to make their Scrum practice shine.

Dan Neumann: [25:30]  Very cool. Yeah, just Sprinting is not enough. Well, good. We’ll look forward to incorporating some of those ideas and sharing those and other PST Professional Scrum Trainer insights in the future. Until next time, thanks for joining, Sam. You’re welcome.

Sam Falco: [25:46] Thanks for having me.

Outro: [25:49] 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 host and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.

Stay Up-To-Date