#6 - Exploring The Dev Sprint
Dev sprint is a dedicated time for the engineering team to come up with a technical plan, better prepare for the execution of the goals, address technical debt, and more. John and Alex are discussing how they work with their teams and some ideas for dev sprint and how it went for them.
Welcome to PragmaticLead podcast, your hosts are Alex puke and john Masse. We have conversations with folks throughout the tech industry to get real world perspective on how people make things happen for their careers and businesses check out pragmatically.com for more content, just like this.
Hey, john, how's it going?
Good. Alex, what's up, man? How you doing?
Doing? Well, a lot going on this week? I've been pretty busy. What about you?
Yep. Yeah, a lot of the same. A lot of the same, you know, like, whenever we're coming through, you know, any, whenever we're starting a new quarter, or we work in quarters, there's, uh, you know, we have reviews, a lot of paperwork to get through. So. But yeah, feeling good about, you know, what we got set up next. So let's good. So, I've been hearing a lot about Dev, Sprint, or sprint zero, you've been talking about that a lot. So I have, yep. really curious to learn what it is, how it works? And what's the what's the benefits? Like why we should do it? Yeah. So Deb spring. And yeah, and I've I've had been very excited about it, because I've been mostly excited about the effect it's had on culture of my team. And if I take a step back, the first thing, I learned this actually, I got the idea of running a dev sprint for my team from actually another manager, and a long time ago, and I think you got the same advice was to look outside of your organization, like another company for someone who has like a similar job as you and learn from them, or take them as a coach or a mentor. And I discovered that, or I had the opportunity to meet another manager or technical manager and another company, that happened by accident. So yes, I I had the an open mind to connect with another person, but I didn't really no, or have the social tools to go and seek that person out. So it was a happy accident that I met this individual, I was really interested in developing good working cultures, like how do I keep people motivated? How do we get people like to have ownership in like a sprint or, or in Scrum. And the company that we're meeting with or on site for partner company, they were using what was called scaled agile, or safe, it's sa f e, and it's like a little e when you see it in writing, and a part of safe, they had what's called a dead sprint, I didn't realize it was part of their framework, the manager I was talking to, they said that, they'll run through an iteration. And then at the end of an iteration, or a time duration, let's say it was a quarter, there's a different term that they use for it and safe. But at the very end, they do what's called a dev sprint, where they allow the developers time to clean up their processes, pay down tech debt and those kinds of things. But it was also described to me from this, this person that I met with as a time where the team can set up to be successful for the quarter. And so what they did was they pasted or taped up the big projects that the teams were setting out to accomplish. So the product owners had to create the product requirement docs, they had to describe what the benefits were going to be what they were setting out to accomplish, how was going to affect the business. And then developers would look at those things. And then they would introspect, they would say, what is it that we need to do to be successful for this next big increment or big shipment, and they would spend a full sprint, dedicated to doing that work. And so every sprint afterwards should be a little bit easier to help them realize the goals for the for the quarter. And I just love that idea. So it's a sprint dedicated to engineering discovering, investigating technical issues or project that's coming up in the quarter like it starts with the dev sprint, almost like, hey, let's get ready. Let's prepare for the next quarter, upcoming quarter, let's gonna get all our stuff together, clean it up, and I can understand what we're going to do and the with all the projects that's coming up. Is that is that right? Yeah, exactly. So an example of that would be automation. Let's say for instance, I'm a new company. I have a team of four engineers. We've been manually locally building our application and then just dropping it onto a server somewhere for customers to enjoy. The top a dead sprint might be well, let's add some automation. Let's bring Jenkins onboard. Let's do something interesting here. This is going to help us a lot because last increment, we only did six releases. We'd like to do six releases a week.
And in order to do that we can spend that time here. And that's where the value added is. It's hard at least just speaking from my own experience, like the quarter starts. You bombard it with like goals and projects, there's like, no time, like, everyone's like, has to go, go go like right away, because we add the, as soon as the quarter starts, we're already behind. So how do you get that time? It sounds awesome. Sounds nice. Like, hey, let's take a pause. Let's gonna sit down, take a deep breath, look at our projects, maybe do a little bit of technical Debt, work, preparation. Sounds all great. But where do you get that time?
Actually, what I found is agile doesn't have actually prescribe a sprint zero or a debt sprint. It's not in the manifest at all.
Actually, yeah, agile is actually a pretty vague term, maybe we can talk about that there's so many flavors of, of agile. So it's, I guess it's just one of them.
That there is, but there's actually a very good reason for it is that in the actual Agile Manifesto, one of the first things they say is that this is not a process. This isn't a thing or a routine to follow. But it's a set of tools that you can use to iterate on your process. And so that's that it's supposed to be different for everyone. And if you're if you look at, I've started to talk to you about complex systems. Agile is actually the first framework that invites iteration on a working process. That's also why I've been really hesitant and really not sure how to ground because, you know, we're working on an article on the dev sprint to share with people and I start writing like I'm coming from this position. I'm so excited about the dev sprint, because I'm so excited about how my team has been responding. And our demos are amazing. And we're really ramping up our productivity for the rest of the quarter. But the problem is with agile, and with any complex system is I can't take my success or the success that I've had with my team in this experiment. And actually, just try and give that to you. It's not your the results may vary, it's not going to be the same thing. So that's why it's important that when we we look at something like Scrum or at an agile, and the dev sprint, or sprint zero, we look at these as experimental artifacts. We look at these things as we're going to try it. And that's actually what I did with my team with the with the developer sprint. It's always the developer sprint always was in my mind for over probably two years, I'd say I never ran one. But it was something I always thought about doing. And to answer your question, specifically, the safe or variation, or the scaled agile actually bakes in the dev sprints part of the process. And that is easier to sell to stakeholders, when you're talking about a framework, you say, Hey, this is just part of the framework. This is about how we work. And so it's much easier for if you have product and technology teams, or business teams and technology teams arguing for time, or how to spend that time, if it's part of the guarantee. And in this case, for safe, there's actually consultants that will come in and say this is how you should behave. And so it's in that framework by default, carve that time out for your engineering staff to spend that to spend doing the things that they need to do.
Okay, so so I want to cover two things, in our conversation, just just learning for myself, like what it is and why I should even consider that. Right, you already do that. So I think it's been pretty successful for you and your team, that that's why I wanted to learn that how to do it from you. So two things I want to cover. One is, how does your team adapted like your engineering team? Like, what's the benefit? Are they excited about those? Any, like positive effects that you have? Like after just looking back? Like, what are the wins doing those? And the second is, how do you get going to convince your stakeholders product your leadership going to give you this time because it's time, right? And agile is just a I guess it's just a word that companies use to say, oh, we're doing agile, it's just a process. But in reality, we just everything is the same people have have tasks to do they have to deliver. There's some expectations in terms of the timelines, we just saying we're doing agile, but not not everyone is actually doing agile, right? So do things I want to cover.
So let's talk about how do you get the time to do it. Is that talking to stakeholders and leadership? Right? Okay, right. So in order to have it a little bit easier, because I am also technically a product owner of my my organization, but if you have a strong relationship with your product owner, then this is definitely a collaboration exercise. But here's what's interesting about the dev about the dev sprint and how I came into it. There are a couple of And so when you talk to the product partner, and that was that's actually a lot of what I thought about before running the dev sprint, was how do I give the team my sense of accountability of what we're working on? And so I baked in a couple of things. I said, First, I need to make sure we I know what we're setting we're going to work on for the quarter. Absolutely. And that's an easy exercise you can do with your product person, you could sit down and say, What are the things because now from technology, depending on how strong your product person is, and tech, and how well they understand it, they might have, there's gonna be a lot of fear there. So you have to have to trust you. Okay, so if you don't have that, then that's something you have to work on first. And if you have that trust, and you have some wins with that person, then they'll say they'll be willing to take more risks with you and embark on experiments like a dead sprint, or sprint zero. Okay, so then what's what's next. So you agree with your product person, this is what we have to get done this quarter. And you make guarantees that you're both setting out to accomplish this together, it's not one or the others responsibility, it's both both co ownership. That's important. Because if either one of you become just too, too accountable for the outcomes, then it becomes blaming, and you're not a team. And then that's when one person might prioritize their effort over another. It's very complicated, but it's very important. So then the next thing is, once you have you agree on what you're going to set out to do in the quarter, you have to be very clear of objectively what you expect the outcomes to be. Right. So if it's a new piece of software, a new feature for a customer, it's a new process for continuous integration, it's a new style of deployment, you want to I wouldn't get specifics and like, oh, we're gonna use rust or we're going to use go Lang, like, those things are too specific. Because that's up to the team to make that determination. The technology person, you want to make sure that it's done like decisions are made in a responsible manner. But not too controlling. You don't want you don't have to do that. There's we spent a lot of time and money on hiring very intelligent people, highly educated folks to do that for us. Okay, so you agree on the list of things now, how do you then give the accountability off to the engineering staff because it's not a hackathon. It's not a free for all. It's not a Hey, let's just go do whatever we feel like doing or I, I wanted to learn something or just like as an experiment, which is still has a place but sparingly. The team then we say we we add a ceremony, we actually add a pitch, we added a pitch day. We said okay, here's what's on track for the quarter what we're going to work on. Now come up with something, what do you propose? How would you like to spend the next two weeks or we actually started with one week we started with one weekend increment, reducing risk. That's that's the the whole how you run an experiment, you you create a mountain amount of a place for you a cost failure, so I can afford to lose this much. So if I lose anything, I lose one week of productivity. That's that was what I was willing to commit to losing. And then I established a little bit of a framework. So here are the goals. And now let's pitch to each other amongst the entire team. And then people can join up with each other. So I stole a little bit from hackathon, the hackathon framework where you can, you can have a pitch day and people can join your idea and learn things. I would also like behind the scenes be encouraging people to collaborate with each other, oh, there's a learning opportunity over here, so and so's working on X, you can go join them. And that'll give you good exposure to the subject that you're working on developing. And so then the pitches would occur. And then it gives us also an opportunity to see how people are thinking, like, how is this related to that project? Okay, that makes sense. And so and how will this help us be successful throughout the rest of this increment, or this, this series of events that we're embarking on, or number of projects that we're doing. And then the last part is holding ourselves to the results. So that's why the demo day is super important, because Demo Day whole is all of the stakeholders, which is the product person, the technical manager, your peers on the team, we all meet together, and we show off the progress that we've made. And then I actually added this little fun detail at the very end, where I wrote a survey, so then you get to vote, and there's prizes, and it's just for fun, and I make sure that that's important. It's not about the prizes aren't about winning anything everyone actually gets something for participating. But participation medal. That's right. It's actually participation caramels They get a bags of salted caramels they got to choose, they choose the rewards, but they measure each other based on characteristics that we identify and what we call a competency framework. And you know what the competency framework loosely for folks that might be listening. It's a framework where we literally wrote down the qualities and developmental characteristics of of a professional, an engineer and engineering manager that we appreciate too, as a developmental track, for instance, leadership, communication skills, your ability to move around different types of personalities to help communicate objectives or progress on a specific initiative. And so I baked those actually into a voting tear, and I waited each of them. So how well did they communicate their idea? What was the craftsmanship? Or what could you measure the craftsmanship by and then at the So at the very end, they all they present, and then they vote on each other. And then we distribute gifts to everyone for participating. And I'll tell you, man, like these demo days, like we'll do a demo a demo day will be probably an hour hour and a half on an regular sprint. These demo days after this these dev Sprint's are like, full on day long events. Like if it wasn't COVID right now, this would be like the team activity. So what I'm hearing is engineers get excited, almost like competitive to get what they propose in the beginning to get it done, deliver demos, and actually get some upvotes to Windows cam. Yeah, well, this time there, it's a, I think it was like a board game and some toy that they thought was cool. Okay. It's like a small competition. It's like a game, it's a gamified. Sprint. Yeah, what I think people get drawn to is that they're feel like they get to attack the things that have been getting in their way. For instance, we have, we're actually, we're building what we hope to eventually open source is tool for writing are maybe a library for creating graph qL services with Java, the ergonomics with the with the Java language and graph qL are a little bit clunky. And it's a little ambiguous, but we've been attacking that internally. And the engineer that's been leading that effort, they wanted to modularize it a lot more and make make that increment, but it's hard to it's hard to do that and make those decisions. While we're like tackling security issues, pushing services to the cloud, and moving other types of object objectives that come up.
Okay, that's, that's really good to hear. So let me let me clarify something maybe that was my misunderstanding of what the dev sprint is. So sounds like I was gonna getting that wrong. So sounds like from from what you described, is that the dev sprint is actually aligned with your goals for the quarter. It's not like you said, it's not a hackathon. It's not just Hey, let's go and do something really, completely different, because we wanted to address some technical debt or play with rust or something like that. So it's actually you, you're looking at the goals for the quarter. And as a team, you decided, Okay, what technically? What do we need to do to get ready for this quarter? So we're better prepared to execute our goals. So we're not scrambling later, and figuring out Hey, how do we do that? So that makes it easier to or maybe even unnecessary to negotiate the time, because it's actually time spent towards the goals that you already committed to to execute, right? It's just taking that time carve out that time for engineers to think, and and do better preparation. Right? Okay. But from their perspective, not from the perspective of the manager or the product person. Right? So you've given them freedom and autonomy to think, how do we execute how that i think that's that's the emphasis, how do we execute the goals? How do we do that with frameworks with languages we use? And sounds like, the team gets more excited, because autonomy is part of the motivation, right? So they get that autonomy, freedom of to think and experiment, and that gets them going. And that's really important in the beginning of the quarter, because that sets the tone for the rest of the quarter, right?
Absolutely, man. Yes. That's all it absolutely does. It's, it's, I wonder if that's actually what I'm most excited about. It's that I've come to the beginning of a quarter and the top of the of the quarter, it feels like okay, here's the next mountain we're going to climb. And that's what it feels like at the beginning, just a ton of effort. But if you set up a good base camp, if you have the time to do that, and prep, and you had your granola bar, and you've got your water You got your backpack on your gears looking good. You got the best stuff, it's light to fishing. You're like, I'm ready to go, I got all this new stuff, you have a lot of novelty, right? A lot of things feel new. And you just you can start that adventure. And that's what it feels like. Like, right? As we close that sprint, we close that demo day. We do we actually retro. I forgot to mention that too. We do retro, literally we retro the event, because it is possible that someday we don't need it anymore. It's now Mac starting ask myself the question, well, what's the special sauce about the dead sprint that we want to capture for all of our sprints? How do we get more of our sprints like feeling this way?
So thinking back on just thinking about my teams and projects that I've done in the past past years, I don't think once friends would be enough to address everything that we need to be like really ready, like you're saying, like at the base camp, have all the gear and get granola bars, I don't think they would be enough. I think I'll need like the full quarter to get ready for the next quarter. There's a lot of refactoring, there's a lot of technical depth, a lot of unit tests are missing. You know, there's a lot of work to do. So how do you pick and choose? Like, what's the most important and actually get it done in the sprint? Because honestly, there's not much you can do in one sprint, there's always something comes up. You know, people take vacations, and you know, you have meetings, you have a lot of stuff going on. So maybe one sprint is not is not enough. But in your case, it has to be enough, right? Because you you're dedicated only one sprint. So how do you how do you prioritize that.
So for the dev sprint, what's interesting about the dev sprint is it's after we've run it twice, now we did a we call it a dev half sprint was the first one. So it was one week, we do two week increments. And then we did a full on sprint. This it came from the retro, they just wish they had more time and that the previous sprint actually rolled into the dev sprint. And that bummed him out a little bit because look, we got to deliver what we commit to. And what's actually started to happen is that the team is starting to look at the dev sprint as a sacred ceremony. It's a time that they actually want to make sure that is honored, and that they can take full advantage of it. So for example, something that I heard a lot of times and you know, you do this a lot to Alex is getting the team to focus on complete like that burndown chart for their sprint, close those points, get as close to zero as you possibly can. And that those crazy. Most sprint charts look like the cliff, right? It's just the straight line that goes all the way across and then that sharp downturn angle,
or color, or it goes up, and then a little bit down, right and then
right like that's the process or at least it's maybe it's not, we don't find value in it. So we don't honor it as much we still we're still making progress, but like, okay, the ceremony will take care of the ceremony. But the thing that I found interesting with the with introducing the dev sprint is now the team is starting to look at how ways to make sure that things like rollover, or or commitment rollover doesn't come into the dev sprint. So naturally, they're starting to talk themselves about how do we get better at closing our sprints, and completing all of our commitments. So they're naturally starting to figure out how to plan better. And to understand what they're committing to better for the sake of keeping the dev sprint hole or to take full advantage of what they can what they think they can accomplish in a developer sprint. But then to speak directly to what you're saying with how do you deal with all of the complexity. That's why the goals are so important, because of your goals and where you're working. So So let's say for instance, hey, we want to build this new type of feature on this on this product. And this is what we'd like it to look like. And the engineers, your leaders, most engineers should have a sense of if they've been in that part of the software before. Like, Oh, you know what, there's not a lot of tests in there. It's actually quite risky. And for this dev sprint, it would benefit us to spend time refactoring that area or migrating over to something else. And they can that that gives them that time to do that. So we say Okay, that makes a lot of sense. What is good for like, what is the target outcome? What is something that what is what do you want it to look? What should it look like? so that it can actually be incremented on in a safe way that we can meet our goals and objectives for the quarter and still have good quality software at the same time. And they have to describe that because like, you can't just say I'm going to refactor this thing. You have to say refactor it How? Okay, so so let's say the feature is pretty big, right? So you have the entire quarter to write a feature. And then turns out there are not a lot of unit tests. And I know some engineers probably know
Now that really well, and maybe part of the code base has to be refactored just what you said. But the refactor the code base would take, let's say, third of the quarter, month, not two weeks, it's gonna it's not gonna be one sprint, it's gonna be two sprints. Right? So how do you? And you know, you have to do that? So how do you actually do it in the sprint? I have an idea. But I want to hear your thoughts. And maybe I can go, I can go next.
Oh, yeah. So okay, so strategically, I wouldn't, I wouldn't say continue the sprint for a month, I wouldn't say that. What I would say instead, then is that we have a lot of discovery that hasn't yet been realized. And we expect that this is going to be pretty expensive timewise, it's going to take us we need about a month to spend to spend on this thing. So for the dev sprint, it was the task to the leaders, they might not actually even spend time on that. Because if it's part of your daily, if it's business as usual refactoring. And if you have that hygiene, most teams don't, then you can, you can leverage that as just like business as usual. But a part of if I was participating in the dev sprint, and I was responsible for leading that part of the initiative of refactoring or getting this thing over the line, part of what I would set up for the dev sprint would be to really roadmap out the big parts and try to break it down into increments. So step one, will get it this far, or will change will introduce these new objects, or will create a facade or something. And then that'll set us up for long term or more pro long term duration refactoring. So at least you have the pattern established, that's something I think you could do in a couple of weeks, you can make decisions on how you want it to transform. And by the end of the increment, you can say that this is how we will continue to change it over the next month, two months and beyond. That would be my answer to that.
Yeah, I had similar idea. So what I would do take these this sprint and work on RFCs, design documents, diagrams proposal, how do we address it? How do we refactor it? Right, that's the time to think, investigate plan roadmap, because you're not going to have that time later. So that will set you up for success in the future. So if you have like, take time and go into code and start investigating, and coming up with proposals, I think that's time well spent. And at the end of the sprint, you can present here's, here's my proposal how to address it, maybe part of it is that every story, every ticket will have to have, let's say acceptance criteria shouldn't be a unit test, or part of the code is refactor or a certain like convert to a certain pattern or upgrade to a certain framework, right. So you break that work down into smaller chunks, and the quarter. So yeah, similar idea.
Yeah, it's digestible. They're things that the other thing actually that I do in I've done for the dev sprint, is I've, I strip away most of the ceremony, you said the word ticket. And we actually don't write tickets. We don't create tickets during the Dutch sprint, it's highly iterative. It's highly experimental. We might create some tickets, but that's up to the that's up to the team to do that. We also remove a lot of the we still have stand ups, we still talk about, you know, we still use those ceremonies to keep each other accountable and informed.
But we don't we remove some of the rigor of of the process. In the meeting of the stakeholders knows Yeah,
agile is very flexible. There's no one Scrum or agile that you know, you there's no one rule. So as I said, it's pretty vague. And every team should have their own flavor of agile, what works for them for that specific, you know, team, and people and that setup.
You said, you said something interesting, too, about planning. That gets into sprint zero. And that's also where I started to hesitate about writing about this subject. And from a giving advice perspective, is because there's this sprint zero artifact that's floating around, it's not written by me about a lot. And it's people are actually confused by it. And what I find very interesting is that people set these rules about sprint zero is sprint zero is a discovery sprint. It's the time where you spend doing research. But you also have the spike artifact. Are you familiar with spikes. And the spike is, hey, we don't know enough. Right now we have to do some discovery. We're going to time box. And that's an important thing to do. And in any wallet and agile specifically, we're going to timebox how our investment And on discovering something about this situation. Yeah,
a lot of go in there. And we're going to know a lot of people use investigation. Like there's like, let's let's investigate it. We don't know what it's gonna be. So it's like a spike. It's a it's a work that you have to do research investigation type of work, there's no like real work is happening you cannot estimate it. It just you have to go and look around and see what you find and then come back with your conclusion and only then you can come up with some work that actually has to happen.
What's interesting, is it still timebox? The same way now still ticket? Oh, no,
it's a spike. Right? invest, you have to go and see what's going on and then come back with with my conclusion, and then we can talk about timeboxing. And, and actual work.
So how long does an investigation go on for just until the people participating are satisfied? Yeah. Or
Yeah, yeah. Okay. Usually, it's a, it's a type of a question, hey, is it possible? Is it possible to do that? Is it possible to build this feature? Why this issue is happening? I need to go and investigate. And then I can come back to you. And we can figure out how do we fix it? Because we don't know how to fix it? Because we don't know what's going on. So I need to go and investigate it.
And what would spend have? How many investigations? Have you scheduled? Or have? Have you gone through it? Like a handful?
Well, there's a lot a lot how long? They happen. They happen frequently?
Yeah. Are they so they're ad hoc or and they're not planned? We just say we have to investigate and we go
ad hoc. Yeah, mostly investigations happen on support. So, people have like feature requests, and they have bugs report bugs. So we have to go and investigate a lot.
Interesting. And so do you track? Do you track them on a time spent in with investigation?
It's hard to track that. Because you can't really estimate either story points or time. So there's no, no, you know, no scope investigation, you just have to go and investigate. But usually they don't don't take a lot of time. Because all you have to do is go into code base or go into going to dig into your logs and see what's going on and then come back with an answer that will give us some more specifics to come up with, with the work required.
Okay, so I see that it's like a real-time activity.
So yeah, backlog, real time reactive,
okay. Okay, yeah, that makes sense. We do those, we do those too. But I frame that as we do that as part of our on call rotation, or I call it just general, like application support. And we timebox that actually. And so if we, if I steal your term investigation, we would say I say that you have 20 minutes. And if it goes beyond 20 minutes, then it becomes a ticket. And if it if that's not good enough, then escalate it to me. And then we'll figure it out from there. Because then we're going into sprint disruption, and sprint disruption, we want to hold that it's my job to hold that as sacred as possible with the team. And so I try to protect that. And that's why the spike is very important. But going back to what sprint zero is, is it sounds like a lot of folks are core pigeonholing sprint zero into this like it has to be it's, it has no value, right? That's one thing that that I've heard it characterized as zero value, which blew my mind. absolutely blew my mind. How can you say any work that anyone ever does ever? It has no value? I mean, you might not understand it.
Well, hopefully people change their minds after they hear this episode.
Hopefully, there. So there is the possibility of zeros zero value. And I would say that you'd have zero value if you ran an experiment, and you didn't analyze the results, and made a determination like making a decision from there. If you just , for instance, oh, I tried Russ to during this sprint, whoop dee doo. And off we go. But like, Well, what about it? Like, is there something we can learn from it? Should we do more with it? Should we build tools with it? Like, how does it? How does it change our environment? If you don't have that conversation? Absolutely, you've completely did that you just straight up discarded, I mean, the individual that went through the exercise will carry and hold all of that value, and they get a little bit of experience. And maybe they'll apply it later to decision making. But you've you've you haven't really set the team and your organization up for success by just giving that away. And so sprint zero, it's, I hear things like it has to be one week only. It's only one week, it can't be longer than a week because you have to get to giving back to building value and building code. So Who says that? Ah, well, so that's actually a great question. Because I was trying to find out who said that you made this decision. Because it's just, it's just people like us, you know, going out there writing stuff about it.
My question is back to point one stakeholders how to convince stakeholders and your your answer was If you have trust, if you have good relationship, and it, it's a part of the goals anyway. So we shouldn't even be concerned about asking for this time. So now I'm asking who says dad, because back to this point, we should we shouldn't have this even this conversation, it's like it's a, it's it's work done towards the goals anyway, who says
it has no value? Yeah, so those are the folks that cannot don't understand the actual value. That's, that's coming out of that work. So value for a graphics person is probably different than the value of a software person, a graphics person is, is optimizing value based on how people use something, their perception of a brand, the ergonomics, a software person is looking at algorithmic performance features, they're looking at data structures they're looking at, so their, their view of the world is, is very different. And that's why the relationship between, let's say a business product, business and product people are in a similar boat. And the technology people, you see this even just technology and graphics or UI UX, they have to come together to build empathy between the characteristics that each other are looking for to produce a holistic product or holistic result. And that's when it becomes problematic is when the your the organization around you lacks the empathy of other organizations, developers and operations is another one. It's another good one, developers want absolute freedom, I want to, I want to pull whatever I want out of the money out of this awesome tool set you've provided me and that is the cloud. And operations are saying wait a minute, that's costing us a ton of money. So value between those two organizations is drastically different. So it's, DevOps actually literally means that the developers have that empathy and appreciation for the challenges the operation side of the house is facing. But at the same time operations is trying to, like firm up in pattern, absolutely everything. developers want a little more chaos than that. So operations is working against the chaos and trying to firm everything up at the same time. And that's where value becomes confusing, because value if I'm an operations person, and I'm looking at somebody looking to add a new language to our suite, I'm looking at that as risk. That's a detractor for me as an operations person. Because I don't know what rust is. I don't know how to scan security vulnerabilities from it. You know, I mean, and then Matt, that is actually the that's why the relationships between the people that are that are responsible for creating an organization have to have empathy for each other, they have to be willing to walk into each other's realms, understand the challenges that each other face in order to appreciate and understand the value that's coming later. Disaster Recovery is another good example. Right? If I'm, if I'm a CEO of a company, and I don't understand data center resilience, or data center evacuation, those are terms that are just are just look, what the heck, you know, like, that's not what I did I, I did graphics, or I did 3d animation, like I don't, I don't prove, what is that going to give me? It's up to the tech, right? It's up to the technology organization to say, look, this is important to you. Because if this goes down, you're gonna, you're putting millions of dollars at risk, you're gonna have people up, you know, multiple days during the week. And that's why this exercise is strategically important. It's up to those two people to realize that together.
So how do you sell this sprint zero? to those people who don't understand the value? Maybe there's some education has to happen. So how do you present? How do you package it up at the end, and after the demos, how to package it up and actually show here's here are the results. And that's why we need to continue doing that. That's why other teams need to want to want to consider doing that as well. And that's what we're going to talking about now. I'm considering doing that for my team in future quarters, or at least have a conversation if we should do it. So how do you how do we package it up at the end? And talk about the value?
The absolutely the sprint is a critically important artifact.
As a matter of fact, I will go out of my way to invite people from other parts of the company to join the demo, and to ask questions about what it is that we did or the decisions that we make. That's feedback. So the first thing I'll say about anyone considering doing a dev sprint, or sprint zero is find your own way. We are writing about the dev sprint, we're going to shoot and we are sharing, or I'm sharing at least to the things that I'm excited about that I've seen work. That doesn't actually mean like in complex systems, doesn't mean the the results I got will be the same that you get. But that doesn't mean you can't do One experiment. So what I would do if I was getting started is I would partner with if I have stakeholders, I partner with immediate stakeholders and develop what's called a shadow system. Shadow systems are systems that are developed on the ground by the teams that are working within an organization that has a framework that doesn't necessarily work for them in regards to their productivity, so for instance, if broadly, the company doesn't support a dev sprint, then it will become a shadow process, a process that that team does on their own, on the side of any other team that's different than everyone else, for the sake of their own productivity, okay, so you're establishing and just go in knowing you're establishing a shadow system, if you use that term, then your stakeholders internally becomes internal to your team, and you and your partnership with so you've now drastically reduced the overhead of being interrogated by outside forces. So you create a little bit of a safe zone for yourself, okay, and prepare for an experiment. Now, the next decision you make with your product person or your stakeholder is how much risk are we willing to take? Let's say, what's the worst case scenario, we spend a week and nothing happens? Right? Okay. That's the worst case scenario, what's the best case scenario, the best case scenario is we're set up even stronger than we would have been initially, to get the rest of this this quarter completed. We've motivated people, we have new ideas and new energy that we're embarking on. So we actually stand to benefit quite a lot culturally, and productivity wise. And so one week is a fair first start. The next thing is, make sure that everyone is comfortable with the process and talk about accountability, you talk about accountability, right? quite a bit. And that has to be a part of it. You set those things up, I described the way I did that by handing off the my responsibility, not only the prioritization, but also the accountability portion of it to the team, and let the team act and behave within within a limited duration, then you have to retro. So say at the end of the thing, that we're not just going to do this blindly going forward, we're actually going to analyze the results, that is the important part of the experiment. And then we'll begin to harden the things or look for the things that we really like, and will will push away the things or move away from the things that have either been a detractor, or things that don't seem to be working.
Okay. So that's the conversation that has to happen with the stakeholders, right? So you consider pros and cons. So there's always trade offs, you consider how much risk you're willing to take, compared that to potential upside, and all the benefits that you can get at the end. Great. So they agree with you, let's do it, then. What's the conversation with your engineers? How does that happen? How do you set them up? How do you get them? Here's the scope, right? Here's the two weeks How do you define this sprint zero to your engineering team. So at the end, they have something to present something to , again, to show the value at the end. Again, it's just for, for those. So for
the one thing that I've learned about anything new that I want to try to do with the team is that the team is needs to be part of the planning process. So when I first started talking about spring zero, I presented the as just a generic idea to the team, hey, team, and we meet, we actually meet weekly, some folks hold a staff meeting, I call it a strategy meeting. Because staff meetings I think are just boring. We're just sitting around looking at each other talking about the stuff we're up to strategy meetings, like we do stuff like tech talks, we attack like technical issues, we have a dedicated hour every week where we sit together and we do those Actually, this week, we invited someone from another team to present their understanding of graph qL to us, and give them give them feedback and nurture their development.
So how do you talk to engineers about the how do you set them I lost my train of zero? How do you convince them to, you know, to think about or Oh, yeah, buy into this, this idea and set some expectation what should be delivered at the end?
Right. So during those times, so then since I have the meeting artifact that we're already accustomed to talking about strategic things and new ideas. That's where I introduce the concept of, of the dev sprint. And I described it, just as I described it to you, I met with another manager, we had this nice discussion, he shared this dead sprint with me. And that was something that I was thinking about trying. I ran it by the team. Hey, team, here's what we're thinking, here's this possible ceremony or dev sprint artifact that we can try out What do you think? I'm thinking let's reduce risk? Let's try it for a week. And then they agree with that. And I hey, we need to hold each other accountable. What do you think of these few features? What if we did a vote afterwards? Would that be fun? Or what do you think would pit us against each other can our culture support this thing and then invite them to have Feedback too hard in the process. But then as the manager of the team, I'm accountable to make sure that they have all the information they need to make the decisions that they need to make about what they're going to commit to.
Okay, make sense. And so you set them up for here's, we have two weeks, and here are the goals for the rest of the quarter. And hey, let's you have all the freedom, please go and look, based on these goals and requirements, go gonna investigate and propose what we need to do before we even start working on the goals. And that's going to go and then what, two, three days from now present your ideas like how to build those specifics? Yeah,
I try to get all that information to the team at least two weeks in advance of the dev sprint even sooner if I can, even sooner, that gets into roadmapping. Like, my goal is to get a six month roadmap, it's but it's when I say roadmap, I mean, as a very flexible artifact, I'm it's just even a year is way too far in advance. Six months is really hard to achieve accurately. Because factors change the shape of business changes, the market changes, you have to be able to respond to those things. But yeah, absolutely have to have all that stuff up front, so that they can start thinking about it. Now, here's a lot of interesting things happen in a dev sprint, sometimes it's just, you know, we want to partner with a new vendor, and we need to understand where their docks are, we need to know like, what their system how their systems work with our surveys are. And that's what people someone will spend two weeks just doing, and they'll build demos and sample integrations. And then we have a lot of information we can use to start putting our either a plan or an application together.
Another thing could be there's definitely value in that.
Yeah, another thing I've seen is we'll actually scaffold out a new application like net new. And we'll look at what do we need this application to do. So for our team, we build a lot of a lot of platform type of tools, and continuous integration as part of that. So our team, this dev sprint, developed a, what's it called what Pizza Hut does, it's the pizza delivery, pizza tracker, that's what it is. They wanted to have a pizza tracker for to help someone understand like what stage their deployment was in. Right? Simple, simple feature. But as a side effect of that it also automated a bunch of operational procedures, they baked all that in and they set up custom GitHub actions, they had all the plumbing and work done, ready to actually start building so basically spent the time building a platform that they would continue to evolve through the rest of the quarter. But it also gave us something we can put in front of engineers right now to start getting feedback on as to whether or not they thought it would be useful. So then we can actually understand other we need to pivot, throw it out. But we also had a lot of good work already done to set us up.
Okay, so back to specifics. So they one of the sprint zero, everyone presents their idea, like one by one. So there's no like squats within the team. It's just everyone presents their own ideas.
So the way we do, um, the way we do pitch day, so it's a pitch day. It happens before dev sprint has to happen. It's usually an hour-long ceremony. And we have basically a signup sheet. So write down your ideas. Here's the we have a grid here all the objectives with descriptions and what the outcomes are we're hoping to achieve. And then you put in a grid of what projects you want to work on and who's going to be on your team. And then that becomes pitch day. So everyone has like five or 10 minutes. And they talk about what it is that they're going to pitch but they there are requirements, you have to say how its associated with the goals, and what what you expect to achieve and what the margin of error will might become.
Okay, so based on the signup sheet, everyone presents, or whatever present those ideas you have an hour. And then how do you decide which ideas actually get worked on? Well, let's say you have, let's say you have six ideas, but actually there's the time to work on them. And maybe there's some conflicting ideas, and people want to be part of other ideas. So the you know, there's gonna be a little bit of a conflict. So how do you decide within those ideas, what actually been included in sprint zero.
So most times before they're written down, they've already been talked about in some capacity. I mean, in one on ones constantly with folks, I use the one on one as an opportunity or even our weekly meetings. I use them as an opportunity to remind people of the outcomes we're trying to achieve. And that really seeds an environment for people to make those make decisions that are more closely aligned. But it's absolutely possible to have an environment where you have people just planning out just going nowhere with something or they're going somewhere but they're not going in the general direction that you're you hope they would For those cases, I'll actually provide feedback, even most of the time will, I'll get it cleaned up before the pitch day. But there are times where, you know, actually hasn't really come up too much. But if I was in that situation, I would ask, you know, engage coach coaching, I would say, Well, how does this relate to? Or which goal does this relate to? would be the first question I would ask? It's like, Oh, well, you know, I'm working on and maybe there's something personal they're doing. So for instance, something that's not necessarily exactly a quarterly goal might be learning a language. And sometimes you have someone on the team that you're hoping will become a subject matter expert in another part of your, your software suite. But in order for them to do that, they need to learn that language, or they need to understand the patterns of that system. And so that could be something that they pitch, and I've seen that as well, like, Hey, I'm gonna spend this time reading this book and building a small demo application that shows my competency in this technology. Like, okay, cool. So I see that I can tell my product person or technical program manager, what value we're going to get out of this time spent, but it doesn't always necessarily look exactly like the thing that we're we're setting out to get done for the quarter. Okay,
so did you have any, any cases were like, based on the spring zero, the outcome of the spring zero, the quarterly goals change, let's say an example. And of the spring zero, there was an investigation refactoring this piece of code, and turns out, oh, it's a big mess. And we have to do like a lot of work to actually get this feature done. Or someone else's like, oh, turns out, it's actually impossible to build this feature, because we have like these dependencies, and this is not ready. And we have to do you know, a certain amount of prep work to get this done? any examples?
Yes. Awesome. Question. So one, actually, the first step sprint, we were we ran actually taught me something our couple engineers on on the team saw that there was this, a new program that was being rolled out broadly, all teams were engaged in this in some capacity. And we didn't have any thing in our goals drafted to participate in that. We're, again, we're a platform or support team. And we build a lot of tools, we manage the mono repo, like the complexity that we're we tolerate. And one of the engineers on the team decided like, well, we actually want to build the base componentry of this feature for all because we know all the teams are going to need this. And we're already working with the team that's designing a lot of these things. We think if we get this done, it's going to help all the other teams be more productive, and get achieving our goal to get this big program out in front of the customers. And I heard the pitch. And I actually said, You know what, yeah, let's shift. To do that. Let's make room in our goals this quarter to support this, because I know we're gonna have to support this long term, I think there's a lot of value here. And we should absolutely do it. And not only did it change my thinking and change the goals for for that quarter, it had all of the great effects that we were hoping it would have, by having one development team actually spend the effort to build those components. And then all the teams got to take advantage of that work. But then we also went fishing for more of those opportunities, we discovered this new type of work, because of the way this engineer was thinking and finding these opportunities. I then asked my program manager, hey, let's do more stuff like that. Let's find more of these opportunities each quarter and see how we can fit them in. So absolutely, yes. can really have and also your question around feasibility. I see teams struggle with this all the time, they'll say we want to do this quarter. And then we're say, okay, we're ready to go. But then that team says, well, we're not sure yet what, what it is we need from you, we're not sure you know what change actually looks like. And so in those in those, you can't, you can't commit to that. You just can't not at least without saying. We're not sure when that where the end is going to be or you can't even make any guarantees that you're going to get anywhere, anywhere near close to being done with something or having value or delivered value against that objective. Because you're not even sure what done means at that point.
Right? It's like in construction like you can't really estimate any work before you open up the wall and see what behind that wall. Right? It's impossible to say. So first thing in construction, you have to open up the wall and then only then you can start talking about estimating and the damage that has been done maybe there is a water and maybe there's you know something else going on. You never know. So that the same thing you don't know what you're dealing with until you open up the wall. Yeah,
and you should absolutely have. I mean, I think at least it's important to Bake in the discipline and the honesty in your planning process, to know when it's time to pull the plug on something. If you can't commit to it you're in if your clients can't, or your dependencies can't commit to the thing, pull the plug, take it away from your team, don't let it confuse them. You take it as the leader, the managers, or the product person, go disambiguate the scenario, figure out what's going on, get a firm commitment, and then come back to the team later. But don't keep mixing up the environment like that, or adding and removing things. It just confuses people. And especially, it speaks against all the progress you might have made in a dead sprint.
So okay, so as the last thing to cover, any other side effects positive or negative side effects coming out of sprint zero. So we talked about, you know, the effect on the scope of the quarterly goals. You talked about engineers get excited about closing sprints, which is great, they see the value in closing sprints, so they don't think of Sprint's as just a meaningless ceremony that managers obsess about. So they see some value, right? So they're gonna have a little bit more investment in that. Anything else that you see coming out of this sprint zero, not obvious, like other than just just what, what the demos, demos are?
Yeah, aside from the cosmetics, the things you can naturally observe, yeah, the general sense of ownership that the team isn't, and really shouldn't be that the your relationship with your team isn't about what you can get out of your team, but it's what you can accomplish together. And togetherness requires that you share the functions that drive the outcomes. And the thing about the dead sprint is we're saying I'm giving you control, I'm giving you complete control of where we're going next. But I'm going to seed you with information. And then they get to go through the process of making their own decisions. Not only is there this new sense of, of ownership of the objectives, because it's not like, Hey, I'm asking you to do something, but also have participate in the ownership of that something that becomes a more natural. So the progress along the way is celebrated more broadly. So the by sharing with people what it means to plan to be accountable for the decisions we're making, much like a product person does, you know, like, Hey, I have to sort all of the things and put a priority order here. giving that to the to the team of engineers has been very rewarding from from a culture perspective. Okay, care more about the work
makes total sense. And also for those who've never done it included me, I think it's a great change of pace, it's like you said it's a it's a novelty piece, I think you have to change things up once in a while to, to get people excited, again, because it can feel like just a constant work and no fun. So doing something different at least for a week or a sprint. I think that's that's a great contribution or positive effect on a culture in general,
that actually came up as during our retro on the done our last sprint, that was something that almost everyone unanimously said that it was just a nice change of pace. See too often agile and Scrum, as used, seemingly used against the team to squeeze product at what we understand, is value out of a group of people. And we just too, we think it's our tool to tune in tune in tune. But that's actually not what it's supposed to be. It's supposed to be fun. It's supposed to be iterative. It's supposed to be a shared process that everyone contributes to, for the betterment of our productivity as a complex system. But too often, though, I think that engineers and developers and product people and people or even entire organizations that think of agile, they look at it as a means to control or means a control lever on the team. And if your team is feeling like that, if they're feeling like I need a break from this process, it's because it's being used, the process is being used against them in some way. And they're not being invited to use it as a tool to to improve their daily lives and the work that they do.
Yeah, makes sense. All right. So with that, thanks. I know you're working on the article, written piece about this. So everyone, please check out pragmatic lead.com by the time we released this episode, I think we're gonna have this posted on on the website. Definitely. All right. Anything else?
That's it, Alex. All
right. That was great. Thank you.
Thanks, man. See you later. Thanks for tuning in to the pragmatically podcast if you found this conversation and Interesting or helpful, we would appreciate your feedback. If you want even more content like what you just heard, check out pragmatic lead comm if you have a story to tell send an email to firstname.lastname@example.org and someone will be in touch. Thanks again.