In this episode of Agile Coaches’ Corner, Dan is joined by his fellow coach and colleague, Sam Falco, to explore the importance of doing Scrum well before scaling. Together, they answer key questions in regards to scaling Scrum, address dysfunctions in Scrum that can derail a scaling effort (and how to avoid them), discuss the importance of integrating engineering practices and technical practices in Scrum teams, and debate the estimating route vs. the #NoEstimates movement. Sam also explains some key practices you should consider bringing in, in order to fully optimize your Scrum.
Like what you heard? Check out our podcast page for more episodes full of interesting discussions, agile insights, and helpful resources.
Introduction: [00:00:03] Welcome to agile Coaches Corner by agile thoughts. 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 Newman.
Dan Neumann: [00:00:19] Welcome to this podcast episode where we are going to explore doing scrum well before scaling scrum.
Dan Neumann: [00:00:25] And with me is fellow coach and colleague Sam Falco.
Sam Falco: [00:00:30] Hello Dan. How’s it going.
Dan Neumann: [00:00:31] Fantastic. Thanks. So when let’s just dive right in. When we talk about scaling what comes to mind for you scaling is.
Sam Falco: [00:00:43] It’s more than just a bunch of scrum teams. It is multiple teams working on the same product. If you have an organization where you have multiple products and a scrum team assigned to each product that’s not really scaling that’s just a bunch of scrum scaling is when you have at least two teams. The problems really kick in at three and above. Working from the same backlog and trying to solve the same problems and they can start stepping on each other’s toes.
Dan Neumann: [00:01:12] Yeah definitely. You’ve got multiple teams coordinating efforts within the same code base trying to coordinate feature sets. Yeah I’m curious if you can expand a little bit on why you feel like three and above might be the kind of the threshold for scaling challenges right.
Sam Falco: [00:01:32] So it’s very similar to interpersonal interactions right. Two people on working together. Don’t have the same communication problems that when you add a third person into the mix and it’s one of the reasons why scrum itself says three to nine people. Once you add other person the complexities of maintaining those conversations start to become problematic. Same thing with three scrum teams. Two teams can probably work together pretty well without any additional framework necessary. They’ll figure it out once you get to three and above then those those additional complexity start to kick in. People miss each other in a conversation not because they need to just because they forget oh yeah there’s somebody else. So you start to need some more formal arrangements to make sure that everybody stays in sync and once you start getting beyond even that it starts to get really Harry.
Dan Neumann: [00:02:22] Yeah no definitely it’s just it’s point to point I guess is the picture that comes to mind and then you see kind of the the number of communication channels just goes up exponentially as you write more and more teams involved in the mix right. Very cool and so scaling multiple teams working on a single product and. I know for me I’ve seen an organization that was doing no scrub and they wanted to go from zero to scaling in a week. So they kind of did what I call the flea dip scrum training they bring in everybody they train them for a couple of days on scrum and then they’re planning you know six sprints in the second half of the week and just made my toes curl. And I saw that happening.
Sam Falco: [00:03:12] Yeah and I’m not going to say that. That’s that there’s no ever never need for that but yeah that is problematic. Just because you’ve got a bunch of people adopting a whole bunch of new behaviors that they then have to handle across teams that that could be problematic.
Dan Neumann: [00:03:30] It can be. I think what was missed the most on that was an acknowledgement that are going to be really terrible scaling for the first.
Dan Neumann: [00:03:42] X number of sprints whatever that’s going to be one two three six sprints and expecting to be able to plan something of scale right.
Sam Falco: [00:03:50] Every new scrum team I’ve ever spun up that started from scratch with people who didn’t already know scrum spent the first two to three sprints just flailing about trying to figure out what all this meant they would estimate too high or too low. They go back and forth between the extremes and maybe I’m overstating the case a little bit but now multiply that by. Three or more and. Yeah yeah.
Dan Neumann: [00:04:14] It’s like learning anything you’re going to not be very good at it at the start. Right. So that’s that’s probably first step is expect to not scale really well to start.
Sam Falco: [00:04:25] Absolutely I think the leadership in any organization has to understand you’re doing something new it’s gonna take a little bit cut people some slack. And so if you’ve got an organization that is hostile or not particularly friendly to its employees and has the attitude that oh agile makes everything go faster well maybe you need to clear jets a little
Dan Neumann: [00:04:48] yeah temper expectations.
Dan Neumann: [00:04:51] Yeah. Yeah. And it’s done well it should make things very fast but done poorly over time. Exactly. Yeah. Yeah but not right out of the gates. Right. So scrum a well before scaling.
Sam Falco: [00:05:07] Yes.
Dan Neumann: [00:05:08] Yeah. Well let’s talk about some of the dysfunctions in scrum that can really derail a scaling effort.
Dan Neumann: [00:05:18] So you and I talked about estimating earlier. I don’t want to get into the whole no estimates war. I have I happen to agree with a lot of what people are saying about the no estimates movement.
Dan Neumann: [00:05:30] But first of all the scrum team has to be able to forecast what it thinks it can do in a sprint. And if they’re really bad at that whether it’s using Fibonacci story points or just some sort of heuristic where they say that feels like enough. Well if you’ve got scrum teams that aren’t doing that well and now they’re trying to coordinate what they’re gonna do with all of the dependencies that happened in scale environment. Well now you’ve got scrum team a saying yes we’re going to deliver these things in a sprint and scrum team B you’ll be able to start working on another item in Sprint too because we’re going to finish this thing you needed Sprint one and they don’t. And then they don’t again. Well now. B is having even more problems. There’s recriminations that happen. You really need a skilled coach in there to help them navigate that.
Sam Falco: [00:06:20] Yeah. They need to be able to coordinate those dependencies. Those touch points between the different teams the impact and the disruption of it goes up as you add more and more teams and so being able to effectively plan a sprint or two sprints into the three sprints into the future. However many are trying to play on the teams have to be reliable and disciplined. Yeah.
Dan Neumann: [00:06:46] Yeah. Absolutely. Cast them and they have to be flexible understanding that. There’s gonna be miscommunications there are going to be missteps and that’s fine. But if I’m on a scrum team and I realize this thing has taken longer than I thought it was going to it might impact another scrum team or more than that needs to be raised as soon as possible. And here again is why it starts to get hairy the more scrum teams you have to teams you remember right. I need to go tell the other team that this might be late. Can you help or you know can you adjust your expectations. But if you’ve got three teams dependent on you five teams dependent on you it can become real easy. It can be easy to just drop somebody without meaning to.
Dan Neumann: [00:07:30] Yeah the communication channels is tricky one. One of the simple things people can do on their teams as they’re trying to forecast out and unfortunately it’s often neglected is just leaving some buffer in the future sprints instead of saying we’re going to do 100 percent of our velocity this sprint and the next one in the next one on the next one. It’s to leave some room in there a little bit in the next sprint a little bit more in the next sprint and more after that because stuff’s going to change if stuff didn’t change. Waterfall would work fantastic.
Sam Falco: [00:08:03] Exactly yeah. There’s all sorts of uncertainty and the farther out you go the more there is. And we know that. But it bears repeating because not everybody remembers it. Heck not even all Agilists remember at all times we get frustrated or under pressure and maybe we revert to an earlier behavior.
Sam Falco: [00:08:20] That’s pretty common. That’s a human thing. And so yeah leaving leaving that that buffer is really important. One place I was at was using safe and they. I’m not saying safe preaches this. I’m saying they have the understanding that that they could forecast an entire PI and just tweak it a little from Sprint to Sprint. And of course every sprint it was this crazy. We’re never gonna make that. Oh we forgot someone was going on vacation. And so there was this constant angst that we’re not going to make our PI increment and that’s one of the things I like about nexus that does away with that and just says plan the next sprint and have your next couple of sprints more or less outlined understand who’s going to be delivering most likely who’s gonna deliver each story and understand the dependencies between them remove your dependencies as much as possible and then you forecast based on that without the need to constantly slot things into sprints. Five six sprints down the line.
Dan Neumann: [00:09:18] One of the insights that Dean Leffingwell had shared actually in a session where I was there and he was coaching some teams on planning their increment was.
Dan Neumann: [00:09:31] We plan in such a way often that there’s very little probability of actually being on time or early. There’s a long tail after that and so building in more buffer to increase the probability of delivering earlier and at least on time was was really interesting to hear that insight. And there’s a nice visual to go along with that.
Dan Neumann: [00:09:54] And I just feel like that gets lost as well. Kind of that that notion of having some some buffer.
Dan Neumann: [00:10:00] Yeah. So we wanted to scrum well. There’s obviously this scrum events having the roles reflected. There is also then all the engineering practices that scrum teams.
Dan Neumann: [00:10:19] Should find helpful scrums obviously doesn’t prescribe a bunch of engineering practices but it’s more than just doing a sprint planning and a review and a retro. And declaring victory.
Sam Falco: [00:10:31] I see I see that a lot even in places that only have one scrum team where those engineering disciplines sort of get left by the wayside because I think scrum doesn’t prescribe any. There’s maybe a perception that they’re not necessary and. Without those engineering practices. Yeah you’ll get scrum teams that start doing really well and they’ll go faster but then things start to slow down because they’re not managing their technical debt they’re not getting to a true definition of dawn or increasing their quality over time. Maybe they’re not really talking to customers as much as they ought to. So I think again it’s important for coaches to come in no matter the number of scrum teams or the size of the program. Hey get your technical house in order make sure that that is tip top and one of the things that professional scrum advocates scrum dot org’s term for it is to make sure that you are not just going through the motions of the various sprint events but get your technical house in order and make sure that you are not just stamping out software but providing quality stuff every sprint.
Dan Neumann: [00:11:37] Yeah those those shortcuts or the the need to manually test doesn’t scale the complexity of the code base growing infinitely right. Every feature doesn’t scale.
Sam Falco: [00:11:51] Right. And I’ve seen that too where your testing effort starts off manual and it never gets automated and there’s certainly a place for manual testing. I mean there’s there’s a lot of things to be said for professional testers who know to go poke at things that aren’t necessarily going to be covered by an automated test or won’t. Right now you’ll find something and then cover it with an automated test there’s a there was a meme that was going around a couple of years ago whereas you know a Q A tester walks into a bar orders one beer orders two beers orders ninety nine beers orders negative 1 beersetc. And I thought yes because I started as a Q A person. That’s the kind of thing I would do. Oh hey I wonder what happens if I put a tilde in this field that is expecting either a number or a letter. Oh look it blew up. Nobody thought.
Dan Neumann: [00:12:30] Yes. And then when it blows up that’s a great time to automate that test and make sure that it never blows up again.
Sam Falco: [00:12:39] Right. And in that instance when I was first in we didn’t have an automation setup so that became a test case we had we had to cover and then every so often they’d say I want a full blown regression test how long is it gonna take. And I’d say a number and they’d say but last time it took less than that. Yeah but we’ve got 25 percent more test cases now and it’s just me and two people on the other side of the planet. So we had the automation suite.
Dan Neumann: [00:13:01] And the risk builds up so if there’s one person in X amount of code the code goes up. Now that person gets to decide what doesn’t get tested. So that’s risk in the system and then no more and more over time.
Sam Falco: [00:13:17] Absolutely. And then that points back to the scaling issue. So it’s bad. It’s hard enough to do that on one team. You’ve got eight. Now it’s really difficult because you’re all working in the same code base and so it may change something on one scrum team. The other scrum teams don’t really realize that is in there has been changed and affects what they’re doing. The integration from the coding side is difficult enough coordinating the testing effort becomes even crazier which is why you need to pay really good attention to your scrum practices
Dan Neumann: [00:13:51] To pair with all the test automation we talking about functional testing.
Dan Neumann: [00:13:57] There’s also then the testing at the code level and really putting in rapid feedback loops so that when developers are checking in code we know right away if they broke something.
Dan Neumann: [00:14:10] I’d love test driven development.
Dan Neumann: [00:14:13] People don’t hesitate that you don’t have to write your testers but it sure helps a ton if you know what test you expect to pass before you write some code. Because my experience has been when people say we’ll go back later and do the testing there is no later. There’s always a new feature some shiny bell and whistle somebody once and going back to put in appropriate feedback loops doesn’t have that
Sam Falco: [00:14:39] Right and that’s why the idea of a hardening Sprint appeals to so many people but you’re just delaying fixing stuff and making it more costly and more likely that you won’t get to it.
Dan Neumann: [00:14:51] Yeah if it’s important it needs to happen.
Sam Falco: [00:14:53] Exactly. So anyway the feedback loops are important and that’s another factor is when people start to have a lot of scrum teams they seem to want to slow down on the integrated product and the feedback they’re going to get on that. So they’ll they’ll lengthen their their PI their program increment if they’re doing safe which is already frequently to too long. One of the things I like about nexus again is it’s every sprint. You are expected to produce a done increment integrated increment every sprint at least once a sprint. Not not just once a sprint. If you can go faster. Great. And so the whole program’s onboard. It’s not. Well we’ll we’ll postpone that. It’s got to work because we’re going to have a sprint review that shows this integrated increment and it has to be Schiphol.
Dan Neumann: [00:15:47] Yes.
Dan Neumann: [00:15:47] And you’ve got then the the discipline of the testing you have to make sure that you can deploy your code reliably every time so that starts to require bringing in characteristics of dev ops whether you go completely down the dev ops road or not. But you have to ruthlessly identify what are those things that the teams say oh we can’t build the code together because of X will create go fix that before you try to scale because it will only get worse as you get bigger and bigger.
Sam Falco: [00:16:18] Right. And that just goes back to the technical practices good technical practice and dev ops can be a big part of that. Probably should be. But all of the other stuff that comes along with it again the testing they’re having the short feedback loops and small batch sizes is another factor. Don’t have these huge if you’re using user stories. Classic user stories and you’re doing the Fibonacci estimates make sure those are as broken down by whether you’re doing the Fibonacci estimates or not. I guess make sure those things are broken down small enough that you can reliably say yes we have a pretty good understanding of what this is we can finish it pretty quickly. So you’re not saying yeah we can take that story and get it done in the sprint. It’s sprint. It’s you know it’s the length of your sprint and that’s the end of the year and work on well you’re probably gonna miss that.
Sam Falco: [00:17:03] So again having that practice of keeping your your your backside a small and good forecasting
Dan Neumann: [00:17:11] As small batch sizes if people want to go towards kind of that no estimates thing which maybe is a a lovely topic for a future episode because that will get into the religious debates I suppose so but small batch sizes is a factor in the.
Sam Falco: [00:17:30] I’m going to I’m gonna hijack those we’re good talking about new estimates for just a couple of minutes because one of the things that you see in that if you watch the hashtag wars or you talk to someone in that space they’re not saying don’t estimate at all. They’re saying don’t spend a lot of time putting numbers on things that don’t really mean anything.
Sam Falco: [00:17:48] Take a take a backlog item and look at it and say is this small enough to do in a short amount of time. No. Once take a piece of it that is and then eventually we’ll get there because guess what. You have a something that you’ve argued over for weeks and you’ve decided it’s an eight on your Fibonacci scale. And then you do a little piece of it. You discovered there were there were you know thirteen one point sizes in it or that a good chunk of what was in that eight. You don’t actually need.
Dan Neumann: [00:18:15] But it’s it’s so hard to actually put complete thoughts into Twitter and a hashtag so much easier. So yeah oh wait no estimates as estimates Wait a minute. So maybe maybe you estimate maybe you don’t but it’s.
Dan Neumann: [00:18:29] Is it working for you. Scrum doesn’t prescribe that you’d need to estimate or not estimate. You don’t have to use major stories as your artifact. You do want to deliver a valuable product increment every sprint and so it’s interesting how many fallacies there are about what is prescribed and scrum and what is not. But really getting the team to deliver on a regular cadence valuable software and respond to changes if you can’t do those things well then you’re going to have a hard time scaling because you’re going to deliver a bunch of stuff that isn’t of value and you may get it done every sprint but a lot of times there’s carryover.
Sam Falco: [00:19:10] Right. Right. It’s sort of like if you take your Lego kits come with these really cool instructions with each piece along the way. It’s sort of like if you just divided up a Lego kit without any care to what pieces were needed where gave them to a bunch of different people and said just build your piece and we’ll talk about it later well oh I needed that little white two by three brick but I don’t have one. But you do and if you didn’t talk to each other about it you wouldn’t discover that or hey if I finished this piece before you finish yours they’re not going to go together. The right way. So maybe that should be a sequencing dependency.
Dan Neumann: [00:19:46] Definitely and I think I can find the article I read about Legos with all their specific kits and their instructions just destroying creativity and children these days. It’s kind of an interesting read because we used to get Legos and play with them and now we get Legos and instructions and yeah it’s just twelve step to step which to bring it back to scrum and scaling. I think that is also a symptom of some of the frameworks people get in the mindset is if I just follow these instructions then I’m going to be agile whereas it’s really incumbent on them to embrace an agile mindset and figure out what’s going to allow them to have those scrum. Those Agile values and agile principles reflected in the way they were right.
Sam Falco: [00:20:31] Right Jim Highsmith wrote a book back in 2002. Agile software development ecosystems. And he talked about at that point scrum had not eaten most of agile it was popular but it wasn’t the big thing wasn’t synonymous with Agile the way it seems to be so many times today he talked about all the various agile frameworks that were available at the time and in the back. There is a here’s how to roll your own. That I thought was pretty valuable and his point was these are you call them ecosystems for a reason. Their adaptive systems. So if you change one little thing it’s going to have effects and that’s fine. If you think about that and watch out for it and make sure that the effect that it has is what you wanted. If there’s an unintended side effect maybe roll back your change. So at the end of the scrum guide it says it is possible to. Not do all of the things that are prescribed this scrum guide but the result is not scrum and a lot of people take that to mean you’re not you’re doing on the scrum police are gonna show up and there’s a similar statement at the end of the nexus guide. It’s possible to implement parts of nexus. The end result is not nexus. It’s not a judgement upon you and they’re not going to say you know that scrum dot org is not going to send its paramilitary force into your organization but they’re just saying be on notice. This is a system and if you change one piece of it this is it. It’s no longer the same system. Be aware of that. Be certain of what you are changing is what you want and be willing to change things back. So I highly recommend that book by Highsmith if you could find it it’s out of print. I managed to find a copy a couple of years ago and I refer to it frequently when a client or someone on a team says well why do we have to do this can’t we just stop whatever event or behavior.
Sam Falco: [00:22:12] And I think all right let me let me think about what that would do what is the benefit we’re supposed to get out of that. And again that goes back to scrum well before you scale.
Sam Falco: [00:22:21] Think about those underlying practices
Dan Neumann: [00:22:23] Definitely. Well thanks for diving in on that topic with me Sam. I appreciate it.
Sam Falco: [00:22:29] You’re welcome. Thank you for letting me go off on tangents as I am I am prone to do.
Dan Neumann: [00:22:33] They’re always entertaining. Maybe we can fit in some Greek history next time
Sam Falco: [00:22:38] I’m more of a Roman history. But sure.
Dan Neumann: [00:22:41] OK. Well you know continuous learning so we’ve covered the scrum and agile topic.
Dan Neumann: [00:22:49] I’m also curious about what you’re reading these days since continuous learning is an important part of growing as a professional and a naturalist. So what what’s Sam Falco learning about these days in print.
Sam Falco: [00:23:01] Sure. I just finished reading thinking fast and slow by Daniel. I think it’s Conomon. I’m not sure of the pronunciation of the word pronounced. This book is fascinating to me it talks about it for people who have read it. It’s a really simplistic view of this theory is that there are two systems of processing within the brain system one is lightning fast it is he calls it a machine for jumping to conclusions it just makes associations between all of the data it takes in and it takes in pretty much everything and system 2 which is slower it is the part that we associate with. This is me. This is me thinking and it’s slower it can override system one but system one wants to offer you an easy solution and the other thing is system 2 is really lazy because taking them much thought takes a lot of energy so system 1 says I have an answer for you it may not be an answer to the question that’s been asked it maybe an adjacent question here’s an answer. You have to think about whether you want to accept that answer and the. As I was reading through this I kept finding really cool stuff that applied to agile that applied to interpersonal relationships that applied to politics and I had to stop myself a couple times literally stop reading close the book and think about what I’d read because the system one was starting to go OK we can apply this to everything and I kind of felt like a freshman who’s taking psychology and now thinks he can explain everything about everyone around him and you just want to throttle him. Yes I was that guy.
Dan Neumann: [00:24:27] That’s awesome.
Dan Neumann: [00:24:28] A lot of those a lot of biases and logical fallacies come out of that system one because you’re bright you can’t process all the signals so in order to survive you can’t. Cavemen couldn’t stand there wonder what was growing in the bushes very long. It was better to get that dose of adrenaline and run like heck. And later they could use system 2 to maybe find a better way to survive.
Dan Neumann: [00:24:51] The thing that growled in the bush
Sam Falco: [00:24:53] that was just Og making noises trying to scare me.
Sam Falco: [00:24:56] Next time I’m gonna throw a stone and Og will regret it.
Dan Neumann: [00:25:01] Outstanding. So thinking fast and slow. Good read lots of get valuable insights.
Sam Falco: [00:25:07] Next up on my on my coffee table is age of agile which I haven’t cracked yet but I’ve heard wonderful things about it. So maybe next time we talk. I will be able to talk about that intelligently.
Dan Neumann: [00:25:16] We’ll put that on the list but put it on the backlog. That was a hit. I want to be on the show again. I think we can make that happen. Thanks for joining. They say look back.
Outro: [00:25:26] This has been the agile Coach’s Corner podcast brought to you by agile thoughts. Get the show notes and other helpful tips from this episode and other episodes. Agile thought. Dot com slash podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.