Coding Blocks - How to Scrum

Episode Date: April 12, 2021

We discuss the parts of the scrum process that we're supposed to pay attention to while Allen pronounces the m, Michael doesn't, and Joe skips the word altogether.

You're listening to Coding Blocks, episode 156. Subscribe to us on Spotify, iTunes, Stitcher, wherever you like to find your podcast app. And yeah, if you find one that we're not there, let us know. And you can go to our website at codingblocks.net, where you can find show notes, examples, discussion, and a whole lot more. And you can send your feedback, questions, and rants to an email address, comments at codingblocks.net. Yes, and you can follow

us on Twitter at CodingBlocks, or head to www.codingblocks.net. What is this voice, man? I can't take it. All our social links there at the top of the page. I'm Alan Underwood. I'm on vacation.

I can't, I can't take it. I feel like I'm listening to like a, an advertisement for sweaty on a, like NPR or something. Yes. And, uh,

I am Mike Wadlow and thank you for listening. This episode is sponsored by Datadog, the monitoring and security platform for end-to-end visibility into your Java applications. All right, so we covered the stuff that you didn't need to know in the previous episode on Scrum. So in this episode, now that we've gotten past the overview biz we're going to dive into some of the the actual nitty-gritty details and how you might implement this this is the one that we have to pay attention to this one this one you should pay attention to and that makes sense this should be interesting because i believe we have some fresh new recruits that have just been through a lot of these things. So I think we'll have some thoughts on this. Okay.

Okay. Wake me when they get here. All right. So with that, typically in our news, we go over the reviews and stuff, but we were kind of recording this one pretty close to our last one. So we don't have any new reviews, but we did get called out on twitter about having the resources page out of date um we said that we have an sla of two plus or minus two years and we updated it within a couple weeks so um we got a thumbs up for that and and i love it we actually

got called out on the scrimmage did you see this on twitter no no not on twitter i'm just like laughing at ourselves for like patting ourselves on the back for updating the page like two years later yeah we're pretty bad about it like hey guys pat on the back we did good right but calling it two weeks we did it within two weeks we got it within a week of being asked to do it that's that's impressive um but so we mentioned on the last episode that scrum comes from the term scrummage in rugby games and we mentioned that it happens after a foul but i think that we or i i should say i portrayed it a little bit wrong because i said that's where people get together and kind of figure out how they're going to go down the field. If you watch,

so I'm going to have a link to the, to the tweet from, I think it was, yeah, David Stevenson. And he said, look, I want to show you a proper scrum and rugby after watching it.

I still don't really know. Nobody understands rugby, right? Oh, is there audio? Oh, cause this is on YouTube if i click play you're gonna hear it yeah oh no you probably won't hear it but i'll hear it but so here's the gist of it right it's a reset after a foul so it's not necessarily everybody gets together and tries to figure out what they're going to do going down the field they're just going to try and run people over like they do on every other play. But they have to get in these little huddles and try and shove the other team out of the way and kick the ball. The first person, I guess, that touches the ball with their foot or something

gets to that team. You pick it up and run with it. But at any rate, it's a resetting of play. And I've got a Wikipedia article link here that kind of gives you the gist of it but i guess that's why they took this term is at the end of every sprint you're sort of resetting play right like hey what are what are we doing now right like we finished that one all right start over let's let's go again with the most important thing so it's like the hoopoe and football american football a huffle my bad huffle oh it's like uh there was something football, American football. Hupple, my bad, Hupple. It's like there was something that we used to joke around about, like we still don't understand something.

I can't remember what it was now. Oh, open source. Open source. Oh, yeah, licensing. There you go. We still don't understand open source licensing, and we apparently don't understand sports that don't occur here in the U.S. That's right. That's right. So at any rate, that was great. Thank you, David, for sharing that.

So now that's it for the news and we're going to dive into the details. So I think where we left off last time was we were talking about the themes, right? And they don't actually show up in something like JIRA or anything like that. And then we talked about epics sort of go up underneath those themes. The next level down from that are user stories. And these are supposed to be a detailed valuable chunk of work that can be completed in a single sprint. So remember in the last one, we said a sprint could be anywhere from one to four weeks. Probably a good place to land is two, maybe three, but that means that you need to write these stories in a way that you can knock them out in whatever sprint duration you have. Um, and in the video that I watched that I mentioned the LinkedIn course,

they had a really good breakdown of like the things that happen when, when you write a story and it's the invest, um, mnemonic and it's, I is independent. The story should be able to be completed without any dependencies on another story. Anybody want to take a couple of these?

Yeah. All right. Uh, so sorry, I was, um, I was finding something very important. I'll show,

I'll share it here in a minute. I'm still, I'm still tripping on the way you pronounced that word. Mnemonic. I thought it was Johnny mnemonic. I thought it was mnemonic. No, I think it's mnemonic with a silent N.

See, we don't even know how to pronounce words. I'm going to have to go look it up now. Okay, so we're on the N in invest there. Forget it. We're done. Let's start all over. So starting over again, we're spelling invest. I was independent.

And N is negotiable. The story isn't set in stone. It's important to know that you should have the ability to modify that. So if you get it and it doesn't make sense or you think you can make it better or you think there's something about that that should be mal. What's the action of malleable in something? Hey, so we both said it wrong, Outlaw. It was a mixture between what I said and you said.

It's not pneumonic. It's actually pneumonic. The M is silent. The M is silent, but it's pneumonic. So, yeah, we were both a little bit off. We're there, though. Pneumonic. And that's the important thing.

We don't know how to pronounce this word with this weird M that's silent. Like, when is the M ever silent? Right. I should have just stuck with it. Yeah. Acronym is what I should have done because I know how to say that. We're going to substitute everything with the words we know how to pronounce. That's right.

So we're talking about user stories. We we know how to pronounce. That's right. So we're talking about user stories. We're spelling invest for the Melmont acronym. I was independent and was negotiable. V is valuable. The story must deliver value to the stakeholder. And remember who the stakeholder is, right? It's the person. Wait, stakeholder.

Isn't that the business owner? Yes. Whoever you're actually delivering the product to. Okay. So if I say I'm a, as a customer, the stakeholder is the customer. Is that,

is that right? I thought the stakeholder was always like the person who had a, it could be the all the chickens or whatever. It could be the product owner, right? It could be, but it's yeah. Whoever you deliver in the software to.

Okay. Anyone with a vested interest in the product who is not part of the scrum team. Right. Okay. All right. So outlaw, you want to take a couple of these?

Yeah, sure. Why not? We passed the V. Yeah. Oh, I know that Mark. Well,

Joe, Joe doesn't keep up. So I was looking up something very important on Twitter. I'll help you know. All right. So the next is the three. No, I'm sorry. It's an E.

So it's estimatable. You must be able to estimate the story. And I guess we'll go into the details of why some of these are important later. Or can I go ahead and say now that if you can't estimate the story, then that probably means that you don't have uh you know the details that you need it's too vague if you can't even estimate it agree which means that you're probably you might not be able to even fit it into your sprint right uh s is small you should be able to estimate within a reasonable amount of accuracy and completed within a single sprint.

And T is testable. The story must have criteria that allow it to be testable, which I think another way that you could say that to the testable portion is like the success criteria, right? Because depending on what, like to say it's testable kind of makes it sound like you need to be able to write a unit test or an integration test. And that might not always be applicable. Agreed to, to the thing.

I think, I think Joe has us a new mnemonic. Do I? I don't, I was just saving a note for later, but I did want to ask a question about, uh, estimable estimable.

Uh, so what's something that you can't estimate? Is that like an open ended research? Like what, like what is, what is a non estimable ticket? Just like that. What you just said,

if it's too vague, like outlaw said, I think, I think research is a perfect one. Um, if somebody is like, uh, need tolaw said, I think, I think research is a perfect one. Um, if somebody is like, uh, need to find out,

I don't know. I can't even think of anything off the top of my head. Experimenting like, Hey, you know, would flank work better for this situation than beam would, or would we be better off with Kafka Kafka streams app? And in those cases,

like those are three different technologies that you like, I don't know. I just need to like figure it out and go experiment, but you don't know how much, how long either one of those might take you. It's literally like a research thing, a research project. It may be better off to like,

say instead of trying to take on all three at one time, maybe you're like just go a one after one in a given sprint. Right. As a, as a developer, I would like to implement a flink pipeline to do real time streaming on event data, right?

Something like that is, is easier to lock down. So I say, I just don't know how long that's going to take. You'd say, we'll break it down into smaller pieces and let's find an early one that you do know how to estimate. And I,

and I think in some cases the unknowns are hard to do, right? So it might be that after you do your first story and you find out that you just didn't break it down far enough, when you create your next story, you'll know the bits and pieces that you need to call out. But it also might be like way too open-ended. Like it doesn't have to be a research thing. It could be like a real thing, but it could just be way too vague and open-ended. Like I want to build a Twitter competitor for this sprint.

Right. Really? Yes. So, so yeah. All right. So I think I actually, wait, Joe, did you have something you want to share now or were you going to hit us with it later?

I think we'll do it later. I'm putting it in the, the notes now. Can't say that one. Okay, got it. I'm still figuring out how to talk about it. All right, so as he figures out how he's going to mention this in a way that is good. Good luck. I kind of just said it a second ago.

Stories should be written in a particular format. There's actually a way that they suggest you do this because it defines a few things. So one is as a user role, like the user role being who it is as an administrator, as a customer, as a developer, I want, and then you fill in their requirement so that you get the desired benefit. So one of the things that I think I saw somewhere is as a developer, I want to upgrade to the latest version of Kubernetes so that we get better metrics on our nodes and our pods, right? Like that would be a good story for a developer. It's not a functional thing that any end user is going to care about, but it's something you care about for your end user is going to care about,

but it's something you care about for your team. So you can monitor and observe your system. Maybe you just have crappy users. Then if they don't care about your Kubernetes version, it's possible. They say it's always a user. It's always a user error, right?

It's like written right there in the footwork, you know, the footer of the webpage, you know, like copyright, blah, blah, blah, Kubernetes version, blah, blah, blah blah uh that's all every decent website has it oh oh by the way though so i just mentioned that was a non-functional it's worth calling out because i so the three of us actually had an issue with this recently in that it seemed like

every user story we're coming across was like a web page component or something, right? Like something tangible that people could go feel, touch, look at. User stories don't have to be that. So there's functional user stories like, yeah, I want a page that does, you know, X, Y, and Z. But there's the non-functionals, which are, I need to set up some database tables. I need to set up indexing. I need to, you some database tables. I need to set up indexing. I need to, you know, make connections. I need to create a connection library for, for talking to these

various different data stores. Right. So just know that every story doesn't have to be something that someone interacts with. I love these by the way. And here, here's the reason why, do you remember? Um, I think we talked about it in regards to like cucumber and spec flow, but it's not necessarily specific to those technologies, but the given when then syntax. Yep. syntax and you know shame on me like i never uh it never became habit but i did i have done it a lot over the years but you know i guess it depends on like how much time i feel like writing the ticket as to whether or not i do it you know but it makes it super clear like what the expectation is right and to me this is basically that it's just, you know, semantically you use different words, but you still accomplish the same thing.

Given that I'm an administrator, when I blah, blah, blah, then I can blah, blah, blah, right? You know, given I'm an administrator, when I look at the Kubernetes version, it's upgraded. It's like that. It'd probably be better than that, but yeah. Yeah, just look at the version, right?'s upgraded it's like that it'd probably be better than that but yeah yeah just look at the version right i want to see the higher numbers um yeah i mean it takes you back to just sort of your elementary grammar type stuff right like cause and effect type things right like i want this so that i can do that and and that's a really good way of telling the story

and it is a story so it's perfect so would you want to, what's a valid reason for wanting to upgrade, uh, for the benefit you get from upgrading something like Kubernetes? Well, like I said, one of the ones that we actually ran into this on our own team was, um, in, in an older version of Kubernetes, you couldn't see like some of the system metrics unless you upgraded the thing. And then you could see IO performance and that kind of stuff. Right. So there's that, but there's another,

there's another great story for these kinds of things is, Hey, I need to upgrade my SQL server from version 2012 to 2018 because it's no longer going to be supported in a month. Right. So there's all kinds of legit reasons to do upgrades. Yeah, so I was thinking like, so we have better, it's like, I don't like the word have,

but because it's not action oriented, but you know, it's not like your English professor is sitting there grading your user stories. So I was just trying to think if there, you know, it's very easy to write bad user stories if you want to get kind of tricky with it. And so there's a Twitter account that I follow that's got a dirty word in it. So you're going to have to go to the show notes and click the link.

Would you say it's a crappy word? It's a crappy word. Yeah. Say crappy user stories except it's not crappy. Something user story and actually no IES, it's just one. And every tweet is just a user story.

And some are just like bad because they're like written poorly, kind of in the sense that like, this is how a developer might write a story when they are just trying to get the job done and check it in and get to work. But sometimes there's other ones that are pretty funny. Like as a website visitor,

I want to enable notifications on my web browser so that the daily mail can let me know that Kim Kardashian can't stop smiling as she heads into a meeting about a divorce. So it's kind of funny stuff like that where it's like no website visitor ever wanted to enable notifications, right? They only do it on accident. So obviously that's a joke there that's pretty good they only have 130 of these that's it they got 58 000 followers apparently they're worth it i'm sorry i was thinking about

about your upgrade examples though so uh because you know joe was asking about like why why you would write the story like that or how you would write the story like that. And I was thinking, as a Kafka Connect developer, I want to use the Strimsy operator version blah, blah, blah, so that I can take advantage of horizontal auto-scaling. Right? That might be an example of where you name the goal is to upgrade, but why do you want to do the upgrade? Right? And it's not that you're necessarily doing the coding as part of

that ticket. That ticket is just about the upgrading. You're just saying why. The justification for it. Yeah, and I like that better so I can have something because they have something it kind of the reason that they want you to phrase things like this is because they want to set you up to be able to have uh be able to break the stick down in all the different ways things it defines the stakeholder so you know who to talk to or who you're supposed

to be dealing with it defines the action you're going to take so this is what you are going to do and it defines the result that you're going to get. And so if you just say, so I can have something and then it's kind of like, it makes it wishy-washy on your acceptance criteria. And so it kind of sets you up for vagary. So I wanted to point out another one of my favorites. This is actually probably my favorite of these user stories. And this is the reason I follow this account. So this is an example of a bad user story as a user. I want to sign up for an account so that I have an account. And there's something about that have word.

I think that almost like kind of leads you to writing about user stories. If you use the word, have any user story, then maybe a sign that you're being vague there. I don't know that I've ever thought about it at that layer. Yeah. Well, I mean, even though still, like, instead of given when that, this is as a I want so that. Right.

But I think given when that just, like, flows better. Yeah, when that, so that. Yeah, I like that. All right. So I see what. All right. So I see what you did there. That's pretty good. Bazinga.

We have new toys. So let's, let's go to the next part here, which is want to remind you of what we said in the previous episode. That wasn't that important. The whole episode wasn't important. just this one part, right? But in the previous episode, we talked about the fact that teams are supposed to have team norms, and there's supposed to be these definition of dones. And there's certain things that the definition of done applies to everything.

You should not have to write this in your user story, right? I need this thing deployed to my QA environment before it's considered done. That's, that's a rule for everything. So now let's talk about these things called acceptance criteria. So every story is supposed to have acceptance criteria that is unique to that story, right? It shouldn't be you need to deploy this out somewhere, you need to test it.

That's complete garbage. You know that that's supposed to happen. Is it? I forget. I say no. It's supposed to happen. I think I had somewhere in the notes that, oh, one of the stories I put up there that I didn't even read off was like, as a user, I want multi-factor authentication in the user profile so I can securely log into my account. Right.

So if we if we stayed with that notion, then some of your acceptance criteria might be the token is captured and saved, like you can verify it in the database. The verification of the code completed successfully. So if you've ever done MFAs, typically you have to punch in a code twice after it refreshes. And the login works with the new MFA, right? Like those are some pretty good acceptance criteria to make sure that if you implemented this feature properly, these three things have to be testable. You know, basically like what Outlaw said, maybe you can't unit test it, but you should be able to verify that those three things are happening. Who writes the acceptance criteria in a perfect world? I believe it's so most of the stories are supposed to come from the project manager. So there's the product owner who was probably your stakeholder, right?

Then your project manager is going to be whoever is, you know, breaking out these stories. And then it's your teams that are working on these things. So it's supposed to be the project manager, but that doesn't mean that you don't have developers and people on the teams that help fill out some of these details, right? I was thinking when you asked about like, who does this in an ideal world? And I was immediately, my mind went, not it. Yeah. Yeah. For real. Yeah. I was just thinking, you know, MFA, like I look at these things. It's like, yeah, that all makes sense. Oh, but wait, I, uh, as a developer, I want a way to turn this off in development. And Ooh, if that service is down, we should probably have a backup plan.

And Ooh, if they forget their MFA, we probably need a, you know, so it's like, this is a big story, right? Right. It is. And man, that's really good stuff too, because if you keep those in mind, we'll get into some of where that comes into play here in a minute, because that's really important. That might be an example of a story that we ended up kicking back or breaking up into multiple stories and kind of rolling out more slowly.

Totally. Totally. Totally. And these acceptance criterias define what done means for that story, right? So you can't mark that thing finished until you've checked all the boxes that have been put as acceptance criteria on the story. And it's important to know that depending on the tools you use, like if you're using Atlassian Jira, um, they will have, they actually have a feature for acceptance criteria, like a box that you can put check boxes in to where people actually have to tick them off to mark.

The thing is done, right? Oh my God. I just click all those myself. It's so frustrating. Like, come on, man,

you're not clicking those things. Like you didn't do all this. You just clicked them. I didn't feel like the first two and now I just leave them blank. But you know, the problem, you're not clicking those things. Like you didn't do all this. You just clicked them. I didn't feel like the first two. And now I just leave them blank. But you know, the problem, you know,

the problem is the acceptance criteria that we're talking about, that these guys are like, yeah, I just checked them all. Those aren't true acceptance criteria. Totally. Those are supposed to be the definition of done that is supposed to apply to everything that you should have already known.

The acceptance criteria should be specific for that story, which in the situation we're talking about here, it's not. Yeah. It's like, you know, sometimes the committee gets together and like, well, these are the things that define done. And it's like maybe that this person signed off on that person signed on, it has been deployed. You come up with this list of like 13 things that constitute done.

And then somebody has a ticket that's like, you know, check on backups or something you know something very minor and none of that stuff applies and because you went out and you were specific and kind of wrote down exactly what you wanted for 80% use case maybe it doesn't fit for the other 20% which is awkward and

I'm not saying it's bad to have that stuff written you know it's great to have that in there but it's just funny when you like whatever you're doing doesn't make sense. And that's kind of weird, too. Ticketing systems, there's kind of this hard line between help desk items and just kind of different types of tasks.

And the ticketing system doesn't always fit well for those other things. You can put it in there, and it helps you budget and allocate time and all that other stuff that you get, but it's really awkward for user stories. Yeah, it can be. Or to write user stories for those things.

Right. All right. Like, check on backups so I don't get fired. That's a good one. As an employee, I want to check on the backups so I don't get fired. That's awesome. So the next part was you're supposed to set up team boundaries, and we already mentioned the definition of done and how it's supposed to be part of everything.

There's another one that the backlog prioritization or grooming is what they call it. Grooming the backlog. You are supposed to constantly, or I say you, the project manager should constantly be ordering this thing by value, right? So they are going to the product owner and talking to them and saying, Hey, what is the most important to the business or to the success of whatever this thing is? And let me reorder it.

It doesn't matter that you've had stories in there for three months. The same story might keep getting kicked to the bottom of the list because it's just not as important as other stuff that comes up. Right. And that's the whole purpose of agile. Nowadays, you'll see this referred to as refinement a lot of times. Right.

I still really liked the way that we've talked about John, our friend John that was on episode 100 had mentioned this idea that we've talked about where like the, the prioritization be based on – like typically we would do this based on like this is priority because this customer wants it or whatever. Or I just think like this is the amount of time i'm willing to have spent on this thing and if it can be done in that amount of time great if it can't then i don't need it that bad right like if it can be done in three weeks then i want it but if it's going to take three months yeah i guess not i don't care and user stories might help that right right? Like if you have,

if you create a net pick or something and then you break it down into user stories, you might be able to say, uh, we story pointed these things and based off our velocity over time. Yeah, this is, this is going to take us three months, right? Like you might be able to do that as you build up some of that, um, past history of how quickly you're able to move through your backlog items. And then the other thing that they said about the team boundaries is, you know, you have set up the sprint cadence, which we mentioned that, and the cadence is just how long your sprints are. They say two to three weeks are probably best. Oh, and here was an interesting thing. So I think I mentioned it on the last episode, but they said that two weeks is really good because it sort of gives everybody

a sense of urgency, but it doesn't throw people into a sense of panic. Right? So the whole point of a sprint is to really try and push to get things done, but as at a sustainable rate. And they found that two weeks is a pretty good timeframe for that, right? Like, you know, you got to get things done, but as at a sustainable rate. And they've found that two weeks is a pretty good timeframe for that, right? Like, you know, you got to get things done. So you're not slacking off and you've got enough time to get something meaningful done. If you go down to one week, you may not be able to get anything meaningful done, but

the pressure is really hard, right? The problem. You get under a day, right? The problem. You go to the bathroom. Blah, blah, blah, blah, blah, blah, blah. Okay. the problem you get under a day right the problem you go to the bathroom okay that's uh uh the problem i think with both the one week and the two week though is they are not forgiving no if you have one or more members of your team that take a week off for vacation which is quite common right then? Then it throws, you know, either, either you lost the entire sprint or you've lost half the sprint. And, you know, so that's why I like

the three week one, at least you've only lost like a third, right? So it's kind of like, okay, I guess, I mean, I have historically liked the two weeks better, you know, but I can see why I can see the value in the, in the three week, four weeks just seems crazy talk. Can we, can we agree? Yeah. Four weeks is too long. And it is one week also was crazy talk by the way. I agree. Yeah. Two, two to three is definitely it. Um, I do like the point of people taking time off. And when you consider what we said, the ideal team size was, which was seven plus or minus two. So you're talking about five to nine people. If you're on a five person team, you lose 20% of

your, of your coding or, or development capability for, for a week of that sprint. Right. So that's, that's a pretty decent chunk out of it. So yeah. All right. So this is where you've probably heard us hate and lament on anything that has this word in it over the past eight years since we've been doing this podcast, right? This one's crappy. Can we even talk about it? Are we allowed to say this word? I'd like to skip it. Okay. Do you want to try and say it out loud?

No, I'm good. We can just go on. All right. So I'm going to say it out loud? No, I'm good. We can just go on. All right, so I'm going to put it out there. I guess this is like saying Voldemort. Whoa. You can't just throw that out there. Estimates, man. Estimates.

So there are some important things here that actually made this come into focus for me. Because I've always hated estimates like straight up hate them you're saying that in past tense so i i'm not saying that i love them anymore i'm not saying that i've completely flipped but there there's a big difference and we'll get into it here in a second joe but there's i think he's become one of them i think that's what we're about to hear yeah this is where alan's moved into like management material or something like that i love my estimates so i can i can plan out everything you know what's so funny about that you know what i love to do and the reason why i like being a software developer is i love to

solve problems right like that is that I love to solve puzzles, problems, whatever. And what we're going to describe here in a second, it sort of clicked in my mind, like that solves a problem, a problem that I've always been frustrated with. So the first one is, and we've talked about this in the past and actually outlaw brought it up to me the other night in chat. I had totally forgotten about is actual estimation. There's that means how many hours or days will this take? Right. Somebody gives you something and you say, I think it'll take five days.

When you do that, you're locked in. And we've talked about this. This is why we hate estimations because it stinks. Specifically, we talked about it in episode 109, the pragmatic programmer, how to estimate. He didn't look that up. It was just sitting in the back of his index and his head somewhere. He had it. But then the other worst, the bigger it is, the bigger it is, the worse it is too. You know, it's just hard to be accurate on. So try to keep it small.

And that was, if I remember right, so going back to that episode, Outlaw, and you reminded me of this the other night, it was that whole point of the smaller it is, the more they want to hold you to it. And the bigger it is, the more nebulous it is, but they still. Well, not exactly. Let's finish this section because I was definitely going to bring it up, especially with one of the bullet points coming up.

Okay, cool. All right. So the next one is not actual estimation. It's relative estimation. And this one's interesting because, and I wrote in here actually wrong. I put the wrong notes in here. I need to redo it. I think this task is two times bigger than this other one.

Not necessarily. It's going to take more time. I just think it's a lot more effort, right? Or it's, this one's at least more than double the effort. It's probably more like three times the effort or something like that, right? It is a relative estimation, a ratio of what your gut feel is just looking at it. And Scrum uses both actual and relative estimations, which was a light bulb moment for me. And this is why I didn't hate it as much. So if you've ever heard story pointing, I actually, when we first started talking about

going back into Scrum, I was actually so irritated by it. Because I remember in the past, people would be like, well, how many story points do you think this is? And I'm like, I don't know. Five? They're like, well, why'd you make it five? I was like, I don't know. That's for an arbitrary number. I gave you an arbitrary number.

You told me we have 20 points in our spread and our spreads two weeks so i'm gonna guess that that's about you know however many hours per point so i'm gonna guess it's this right and and then when you'd say it they're like well you can't equate it towers and i'm like well but you told me we only have so many points in the spread how you want me asked me this thing right right and then you throw out a number. They're like, no, you can't do that. That doesn't sound right. And I'm like, I don't understand what you're trying to get me to do. It's so frustrating. It was so painful. It was. And you were there with me when we were going through this whole thing. And I was like, I, I, dude, I can't do this. I don't know what they're trying to get us to do, but I can't do it.

So you're not supposed to do it that way. You know, I think, did we lose Joe? No, he said he'd be back in a second. Okay. All right. So you're supposed to do it relative. And what we've seen and what seems to be sort of standard practice is using Fibonacci sequence, right? We just talked about that on the Recion, recursion, recursion show.

So you should be familiar with it's one or zero, one, two, three, zero, one, one, two, three, five. You're adding that the previous two numbers to get to the next and then by eight, 13, 21. Right. Yeah. you're adding that the previous two numbers to get to the next and then by 8 13 21 right yeah so here's the interesting part about this what you're supposed to do is take a story that that you're pretty comfortable thinking about the effort level of it right like if it's small if it's a medium-sized one whatever and then you give it story points you might look at one and say i think that's about five story points.

Then the next story you look at in the backlog, you look at that in relation to the previous one that you just story pointed. And you say, is this one a bigger effort or a smaller effort? If it's smaller, then you might say, well, this one's a two. If it's a bigger one, you might say, oh, well, it's not twice as hard as the other one. So I'll make that an eight and by the way that's why they do the fibonacci they don't want it to be like multiples of two like oh that's twice as hard and that's four times as hard they want it to be like a exponential oh yeah i've got i've got to wiggle this in somewhere right like it's somewhere between two times as

hard and not not quite two times as hard right so that's how you do the story pointing. And now I'm curious what you guys thought about it because I've only ever done this one time doing Scrum Poker and I thought it actually played out pretty well, minus the fact some of the stories weren't well defined. But throw that away. I thought it was pretty good. Well, we might want to define Scrum Poker for those who have never played scrum poker yeah so you basically kind of you flash the ticket up in front of everybody in scrum and then uh everyone kind of silently picks what they want you can use the app there's websites uh we can get a link for you well hold on back up first

you have to read the story so people know what the story is. And then everybody has the ability to pick one of these scrum cards. All right, go ahead. Yeah. And once everybody's kind of picked what they're going to do, everyone shows what they got. And you look at the results and say, hey, everyone said five except for Patricia. And Patricia said 13. Patricia, why did you say 13?

And they may say, oh, I misunderstood the story or y'all aren't thinking about this or maybe you see something that said it was a one. Like, why? They're upgrading it for some reason. And so the idea is that you get the group to do it because you get a better result than if you just ask one person. Sometimes people in the group will realize something or will have some kind of hint as to get a better result. And so the idea is that the group mind is better. Multiple brains are better than one, so you get better results. And also, I kind of like the door times.

When you're estimating, you feel kind of pressure to give a low estimate, right? Because if you're giving high estimates, then it means you're slow. You're not good. So it's kind of relieving when you are looking at a story that you're probably going to end up with, and you say you voted a five, and everyone else picks a five or an eight or something. It gives you even more room, and then makes you feel like you're not grossly off.

It kind of takes off some of that individual pressure, and it leads to better results. So I was really happy with it. I think another point that should be made regarding the Patricia example that you gave there is that whatever the majority of the people, uh, people pick, there's going to be the outliers, right? And those outliers on both sides, you, you give them each an opportunity to speak, to say like why they were lower than everybody else or why they were higher than everybody else. Because, um, you know, similar to like what you said, like, you know, somebody might vote a really low number cause they've already done something, you know, almost they've maybe

almost done exactly what you're asking for. And they're like, Oh no, you just tweaked this one configuration variable and it's done and nobody else knew about it or something, you know, like there, there could be reasons like that. And that's why you have, um, you know, this, this group vote, but also you let the outliers speak. Right. And that that's really important when you just let the outliers speak, then you don't have an entire group debating all the finer details of something, right? It's really just, why did you think that? Oh, okay. And, and in our experience, what we saw

was if somebody made a really good point on either end of it, then you'd hear a bunch of people say, oh, yeah, you know, I could be talked down to a five, right? Or, you know what? That makes a lot of sense. You could talk me up to an eight because I wanted to hold specifically for the scrum poker part. So in like Alan said, you would typically do the story points in using Fibonacci numbers so that they are they aren't just a multiple of, you know, five or two or something like that. And, but a lot of the, the, um, apps and websites out there, they'll, when they get to past 13, they go 20. So they, they suddenly break out of the Fibonacci sequence and instead of 21, it's 20. And then maybe from there it's, you know, 20, 40, a hundred or 20, 50, a hundred, you know, what the point is, is like, you're no longer in the Fibonacci sequence. And so Alan got curious because when we were going through this in our own team, all the engineers on the team were like,

hey, wait a minute. This isn't, we can't, no, this isn't right. This is broken. Start twitching. Yeah, we were all like, but seven minute abs. Like I forgot to take my medication today. And so Alan, being Alan, went and researched this and figured out, why? Why is this?

And so then he and I got into a debate about it because we had actually discussed this already. And the short of it is that if you pick 21, then like various – the particular app owner, he had said like the product owner would see that you picked 21. And because it was such a large and specific number, then they assumed that you, you picked that number for a reason that it wasn't an estimate because if it was an estimate, it would have been something like 20 or 25, but because it was 21, it was like, man,

that's so specific, such a specific number. Then you must know that that's exactly what it's going to take. And so I'm going to hold you to that. And we had talked about this before in regards to episode one and nine, the pragmatic program or how to estimate, because in that book, the authors had said that when you're doing your estimating, that the level of specificity that you provide to your estimate conveys how sure you are of your estimate. And so if I told you that something's going to take three weeks, then you're probably going to think like, oh, it's probably just an estimate. But if I said it's going to take 120 hours,

because I went to that extra level of granularity, then you are going to assume, oh, it's 120 hours. And so that's why in these scrum poker apps and websites out there, once they get past 13, then they break, they more often than not, most of them break out of the Fibonacci sequence and instead go to, you know, just rounded numbers so that it kind of conveys that back to the product owner that this number is not specific. This number is an estimate. It's not really Fibonacci anyway,

so it's close. It's pretty close. Yeah. Getting rid of the, it's distinct Fibonacci, right? It's Fibonacci. There's no zero.

Sometimes there's a coffee option depending on the app you're looking at, which is kind of cool and debatable. But yeah, I just couldn't let the guy have to mention that. But I did want to say two other things that you got me thinking about regarding poker real quick. One thing is you might think that there's a lot of pressure since you typically ask the outliers why. And based on what I saw, it was not really pressure at all. It was like there's people on the team that just knew nothing about that story, and it's totally fine.

And so these people, it's expected that you just take a guess. And sometimes, you know, you might say, hey, Patricia, why did you say 13? Maybe Patricia will say, I just, I don't know. I've never heard of this before. So I just, you know, whatever. So hi. But sometimes Patricia might say, well, I don't know. I heard you all, you know, talking about it a lot.

So I figured it was something bad because, you know, people had problems last week. And they might say, oh crap, we did have problems last week. Good call, we're going to bump it up. And so there could be valuable feedback even for people who just know nothing about it. And there's no harm in saying, I don't know, I just took a guess because you're just being honest. It goes by so fast too. And what I thought was cool about it being fast and being okay to being wrong and being safe and just kind of interesting is it kept everybody engaged, which is really hard to do, especially with a lot of people on a call. So I thought that was kind of interesting to be able to go through. I will say I'm sure it's really

painful the first time you do this. If you've got your stuff mostly kind of shaken out, if you're in a brownfield project, you know, you're jumping in the middle of something and you're trying to do this, it can feel pretty overwhelming. And so, um, I liked how we kind of took a slab of, you know, what was kind of most current and what we cared about and just kind of went for that and didn't try to do everything. But I can't imagine when this be with like a greenfield, like brand new project, like seems kind of, uh,

exciting to do that with something just net new. Yeah. I mean, I'll say like, we just went through it with a decent number of people on a call, right? So it's basically three sub teams with like 17 people or something. And after we got the ball rolling, it was pretty efficient. And I feel like, like what Joe said, it took the pressure off everybody and everybody was engaged. So people weren't afraid to throw out the numbers that they were truly thinking.

And, and like I said, typically when the outlier spoke, one of them would make a pretty good point and then it would sway. Basically everybody would be like, you know what? You're right. We'll round up.

And then basically people would just say that, Hey, we'll round up or we'll round down. We'd like that. Right. So, um, it worked well.

Here's the thing with the story points, though, and this is the beautiful part. And Outlaw just hit on it based off our pragmatic programmer series back in the day was when you do story points like this, it's an estimate. It's a known estimate. Story points are, are weighed, um, you know, against each other. And so it's not a commitment and that's huge because the people that are looking at these things know that. Um, and it's supposed to be lightweight and fast, which like I said, us getting into it, it like, I think our group took 30 minutes talking about how it was going to happen before we actually started anything. Hopefully we'll never do that again. Yeah, yeah.

Let's hope not. But once we got rolling, it really seemed like it went well. We kind of burned through some things pretty quick. Now, this is where we go off the notes for a second. So Joe just pointed out that on a brownfield project, this might be difficult, right? Which is what we have. And part of the difficult thing was if you decide to go into Scrum, Scrum is all about having a backlog of stories that you can work on, right? And what this means is if you're going to start up the Scrum process, somebody's got to go create all these stories. And guess what? Creating a ton of stories is not exactly fun work. And it's

not something that somebody's going to put a ton of time trying to break down in the way that you would if you're creating these stories as they come up. Right. And so I at least want to throw out there and I want you guys to talk about it too, is like one of the frustrations we ran into is I mentioned earlier, like all the stories that we have were basically functional stories. I have a webpage that I want to show this. I have components on a page that I want to show this. And it ignored a lot of the work that has to happen behind the scenes to move data around, to update data, to get data into the system, to hook up to external systems, right? Like all that stuff that as software engineers, we deal with all the time. And you'd have, you'd have two stories that looked identical and just, you'd have to

magically know that one of them had all this, this stuff buried deep in it. Right. And, and so just know that if you do want to transition into Scrum, it might be worth, and I think this would have helped us, it might be worth having a backlog grooming session before you have your first sprint planning so that people can call out those things and say, hey, you got a page here, but you're kind of ignoring a lot of work to even hook that page up to any data, right? So we probably need to have a story for that. So that'd be my opinion is set it up to where you do this. I don't know, a few times before you have your first sprint planning. And then that way you're kind of in a better state for people to be able to vote and feel comfortable with those, with those poker numbers. We like to lie to ourselves and tell us that we're all proactive and we lead we

lead these proactive lives where we're gonna like no we're gonna switch to scrum so you know a couple weeks before that we're gonna do these grooming sessions twice so that we can be ready and have a backlog of you know all these beautiful stories no man it's always reactive always yeah what's this fantasy land we're all thinking about what's going on tomorrow wait hold on y'all think about tomorrow today and nobody got time for that right oh man but but do you guys agree like do you think that if if we had taken the time to do something like that beforehand, the initial sprint planning would have been, I don't want to say perfect, but I think there would have been a lot less contention on some of the

stories. I definitely agree. We would have had the stories prioritized better. Having gone through that grooming, it would have made things easier. We would have understood them better. But it also seems like such a utopia in this. Like, it's, I don't know, is that really a thing? Is that possible? Right.

Like, I can see us iterating to the point where eventually we will, you know, live in that world. Because we will have iterated on it, you know, through the course of multiple sprints. Right. But I can't see, like it just seems so unfathomable that we would have like ever done all that grooming before we decided to start doing scrum and then be like, okay, well guess what? We're already prepared for this meeting. It seems unfathomable that we're even doing scrum again. So the fact that we would have planned and done things properly before we got in there. Yeah, it seems unreasonable. Cool.

All right. So the next bits of information are the roadmap and the release plan. And these are important from not necessarily just the team, but it's really important for the, for the project manager, as well as the product owner to be able to see this stuff. Right. And this is where I think that some of this stuff gets enabled through scrum. Um, so the roadmap is supposed to show when the themes will be worked on during the timeframe. So we talked in the previous episode that themes are supposed to be like a grouping of like or similar type items that you can work on. So a profile, a user profile page or an ordering system.

Those are logical themes that you can put together. And it makes sense to work on those roughly at the same time because you're in it. You understand it. You know what's going on. And so if you break those down into stories and stuff, and you start seeing what the velocity of the team is, then you can start saying, Hey, it looks like we have stories that'll fill up three months worth of work here. Right. And if we put that on a calendar, we can see if we do this story here, you know, January to March, we can also start another story from February to whatever,

you know, and so you can start laying these things out. Well, wait a minute. The story wouldn't go January to March. Oh no, you're right. The themes, the themes would, but the stories that comprise those themes, you'd be able to sort of aggregate. Got really confused there for a second. Sorry about that. Sorry about that. Um, and, and that's having the calendar, right? Like, so it doesn't necessarily have to be days. It could just be like, Hey, you know, week one, two, three, four of, of calendars, or it just might be months that you have on there and you draw, draw some bars across it. Right. Um, if you think about the old Microsoft project, you know, the Gantt charts or whatever they were called that you could probably

do something like that. I mean, let's face it though. Everybody loves to see a roadmap. Like how many times have you ever looked at like one of your favorite brands or products or whatever, and you, and you happen to find a roadmap, whether they, they purposely published it or you found it otherwise. And you're like, Oh, I can see what they plan to do for this thing. Like you, you love that right now. Imagine if that was also available for your job. It's not. You improved. Here you go. Here's what you're going to be working on. You scared me. You scared all the managers.

When we talked about Agile first coming on the scene in the manifesto and we were going away from big upfront planning waterfall, we were saying, oh, man, people were scared. Managers were scared. They were saying, what do you mean no planning? And here we are, just a few hours later, next episode, talking about roadmaps and release plans and measurable velocity and two different tiers of estimates. It sounds like a manager paradise, right? But it is

pretty far from what we kind of started talking about people over process and all that stuff. But we're talking about Scrum and that's what it is. But what manager doesn't want to have immediately, you know, be able to pull out on demand, oh, here's our roadmap. Oh, here's our release plan. Here's what we're going to have done in the next three weeks. Here's why I'm confident in saying that, because we have, you know, this much history and this much velocity.

And then this looks like it's tracking really well. You know, so it seems like it's really great for reliability, and the business should like this. Plus, every three weeks, they get to reprioritize and kind of take a look at that stuff. And they have a backlog that's prioritized and roughly estimates that they can think about it. It seems like a win all around to me. Yeah, I think so. And that's kind of why we wanted to do this episode is because as we're living it, it makes sense to go through it. Because I think we're sort of seeing the light a little bit.

I don't know that it's perfect yet, but, you know, it's going to be interesting to see where this experiment goes. So roadmap, if I was a single-person shop and I was making a new product, I quit my job, I was going to just focus on a new job full-time. Roadmap and release plan? Yeah, sure. Scrums? That doesn't really make a lot of sense. There's only one person. If there's two people on the team, that seems a little weird too to have a two week plan and then we go turn our backs in the same

office and get working. So I'm just wondering is Scrum more valuable for large teams than it is for tiny ones? Well, not large. Remember, we don't want big ones. Large organizations. So is Scrum more valuable for a thousand people companies than it is for three people companies? I don't think so. I think it helps. I think it helps those larger companies maybe more because it can be chaotic trying to communicate stuff on projects.

It's easier to do that communication on smaller teams, but I do think the value that you add by seeing what you're trying to get done in a short period of time is helpful for anybody, right? I mean, knowing that you've got in a lot of block of time to try and get feature A, B, and C out the door is a whole lot easier than what a lot of small businesses do where they're just constantly scrambling, you know? I mean, I kind of think of it as like, depending on how small the company is, you know like your your one and two person company example that where you started with that you know maybe you're just purely kanban and you know you don't think think about anything else like these are the list of tasks and just pull one off the board and let's just move on about our day so next game jam should i start with user

stories yeah i'm just wondering like is that the theme of the game if i would yeah well no i mean if i've got four days i'm just wondering like it seems like there is some sort of limit like if i'm gonna be working on something for four days probably not worth writing right you know tickets and user stories for right it's not even the size of sprint so it does seem like there is kind of like a sweet spot where it starts to become valuable and if you're just working on something on the weekends like maybe it's you know maybe it's not worth doing i'm just kind of interested in exploring that line i'm just telling you man if that's going to be the theme of

the game tram i can easily tweak my uh my app so that instead of uh you know closing tickets you're like closing stories i don't think that would actually be difficult i think i can get that out pretty quick right yeah i i think that if it's if. I think I can get that out pretty quick. Right? Yeah. I think that if it's weekend projects or something like that, I don't think I'd mess with it. Right? I think it's more for teams that are going to be dedicating a block of time doing things. Otherwise, Kanban seems like the way to go. Just pull it off the stack.

Well, if you're going to be that organized in your personal life, then I don't think it don't think it matters. Like, you know, Kanban sprint, scrum, whatever. Like you're pretty organized person. You're probably going to be all right. Uh, you know, so whatever, whatever, whatever you feel more comfortable with. But you know, I think to Joe's point though, there is probably a sweet spot in terms of like the team size and dynamics and like how long something is supposed to take. Right. Yeah, it's a hard one. I think the long term projects definitely will benefit more from it than than anything that you're trying to do in a month. Right.

I mean, going back to Joe's four day example, does that mean that you have hourly stand ups? Yeah. And it's also really catered towards um long evolving projects like it's this is something that you knew that you were going to be done in a year and delivered and so you know if you have a military contract and it's like hard hard day due on you know april 1st of 2015 or whatever you know 2025 then uh maybe it doesn't make sense to keep doing this thing where you're reprioritizing stuff. Cause you probably spec'd out that stuff pretty, pretty fine, you know, at a pretty

fine detailed level just to get the contract. So, uh, you know, we're not saying, um, it's, uh, we're definitely not saying that, um, scrum is for everybody, but, uh, it's got its place. Yeah. And it's definitely for you. There it is. All right. So here's another part that was really interesting.

So they talk about having these, these components that you can demo at the end of every sprint, right? That doesn't mean that you're necessarily shipping them. So there's a, they wanted to really call out that there's, there's a line, right?

Like just because you finish something, that means it might be a quarter of the product that it's important, but it's not ready to give to a customer in that form, right? It might take another sprint to get there. So don't think that, that having something complete means it's actually ready to go. It could be an example of like a webpage, like let's go back to your user profile, right? You have a webpage that shows the user profile. It doesn't necessarily mean that it's styled pretty. Maybe styling is part of something else. Like the first effort was just to get the data on a page and functional.

Right. Right. We have text boxes. Right. There it is. Yeah. Have you seen my application, my game?

I mean, like I'm really good with like making things pretty. The UI is there. Yeah. Yeah. It's on point. It's a game recognizing game. Thank you.

I appreciate that. You got it. So here's the other thing. And this is probably the part that's going to be difficult for the project managers and even the teams to deal with at first is you're going to get stacked with a number of stories, right? And it's going to add up to so many story points. It's going to take a few sprints, at least three to four sprints to get your initial velocity. Meaning how many stories were you actually able to knock out, right? You story pointed them. Now you did it. How much did your team finish? So it's going

to take you three, four sprints to get there. And per the course that I took, it said that it takes you six months to get a pretty good read on it, right? So it's not something you're going to have immediately. It's going to be something that evolves over time. Did you say six months or six sprints? Six months. Wow. Yeah. They said, they said it takes some time and that makes sense, right? Because you're going to over story point some things and you're going to under story point some things. And so as you get better at identifying stories and what you think they're going to take, because you've story pointed a few in previous sprints, you're going to get better at that too, right?

So you're going to see it start to average out and you're going to get to see what your real velocity is over time. All right. And then this last bit here, um, there's more notes than, than what it really means, but here's the thing. So I'm going to use some fake numbers here just because numbers are really easy to follow when you're driving. She's a graph. Right.

We'll chart this too. But let's say that you have, what did I do? So let's say that you have 10 points that you can fill up in a sprint, right? You said that the most you can do is 10 story points in a sprint. So we talked about you're supposed to prioritize and order the backlog, but you want to be efficient with your time creating components, right? So if you only have 10 points available, and let's say that you have four stories. So I have story is three points. Story B is five points. C is eight points and D is two points. Not important that you memorize those,

but what is important is you can see that if you have 10 points, well, you can't do B and C because that's 13 points. You're overcommitted. Something's going to slip. But you also don't want to do A and B together because that's three and five points. So now you have two points left. So now you got to figure out, okay, well, I know that A is the most important thing I got. So I really want to get that out there. So that's three points. How can I fill up the rest of my sprint with the most important things, right? So it may not be an exact order, but you're trying to optimize the efficiency of your sprint. So it might be that something that's in the second or third place gets bumped back to the next sprint and something in the fourth place moves up into the previous sprint just because you can fill up the sprint better.

Started from the bottom. Now I'm here. Keeping it real. Oh, so yeah, that's, that's really what it is, right? Like, um, you want to work on the most important stuff, but you also want to make sure that you're not just leaving, you know, 10, you know, 20% of your sprint open without filling it in. Right. It makes more sense to optimize. Um, And then what do I have here? Oh, the roadmap is supposed to be an estimate of when the team will complete the stories and that should be updated every sprint. So that's the important part. Like the difference between

the roadmap and waterfall where you have this big thing that got printed out at Kinko's and they threw up on the wall and can't change. Now you have this living, breathing roadmap, which is more effective for everybody that can see it. I promise you, you give me a Sharpie, I can change it. Just saying, just throwing out my, just throwing out my offer there. My skills are available. If you need to change that. Very nice. And Kinko's doesn't even exist anymore, does it? Now it's FedEx or something? They got merged into some stuff, so you can still kind of Google it and

find it, like FedEx Kinko's. Okay, there we go. So yeah, that's the first part. Dang it. This episode of Coding Blocks is sponsored by Datadog, the monitoring and security

platform for end-to-end visibility into your Java applications. Datadog provides out-of-the-box customizable dashboards, actionable alerts, distributed tracing, and always-on low-overhead Java code profiler for your production environment, all in one spot. Yeah, and they have, of course, in typical Datadog fashion, this is one of my favorite aspects of this company. I so admire this company. Not only do they have

just a bazillion integrations into whatever your tech stack is, I guarantee you they've probably got it covered like 14 times over, but even better than that, they also have the blog articles to, to go along with it. So you can follow along and understand the reasoning and rationale about why you should care about this thing. And so of course, you know, we're talking about being able to monitor your Java application. Guess what? They've got like a half dozen different articles dozen different articles on like here's what you should look for in your java application here's why this would matter here's why you should pay attention to this it's just amazing absolutely and i got an idea for you so uh i we talked a couple weeks back about some of the security

stuff they're doing log rehydration um all the integrations. I have an idea. If you go to Solutions and then Security up in the menu and look at all the beautiful graphs, and they've got these cool GIFs on the page that show you exactly how it works. You take this to your CISO, and you show them all the great benefits they get from Datadog, and then the CISO signs up for it, comes out of their budget, bam, and you get to use Datadog for all the stuff that you want to use. In addition to security, you know, security is great, but you get all the container stuff, serverless stuff, cloud stuff, on-prem, all the great integrations and application performance monitoring stuff that, you know, feels really great for developers.

And so everybody wins. And I mean, there you go. Everybody wins. And it really isn't a lot of effort on your part either to set up any of their agents. Like literally, you can go look at it. They'll have you like, here's the command line you need to enter to install this particular agent onto your system. And maybe a few extra steps of configuration and done. Now suddenly you have that thing.

So with support for over 400 different technologies, I thought it was a babillion. I was pretty close though. With support for over 400 and automatic instrumentation for popular frameworks, you can start monitoring your Java applications alongside the rest of your stack within minutes. And I mean literally minutes. So you can start your free data trial today to start monitoring in real time. And listeners of this podcast will receive a free super cute t-shirt once you install the agent and create just one dashboard. Yeah, so to get that, go visit datadoghq.com slash codingblocks. Again, that's datadoghq.com slash codingblocks to get started today. All right. Again, that's Datadog HQ dot com slash coding blocks to get started

today. Alright, hey. How's it going? Yeah, I'm talking to you. Hey, how you doing? Doing that. And we got the coding blocks folks all here in your ear talking to you about reviews because we love them. We need them. Sometimes we get really great ones

and sometimes we just get kind of small like you know five star whatever little dabbles both are fantastic of course we prefer to get you know awesome feedback with it constructive feedback but you know just the five stars is great

so if you go to codingbox.net slash review we try to make it easy got some links there and you can just do do do do do do do and uh looks up slash review. We try to make it easy. We've got some links there. You can just do-do-do-do-do-do do-do-do-do-do-do and it hooks up. Were you trying to do this? Is this what you were trying to do, Joe? Yeah, but five times. We're good.

That feels too much, man. You're asking for too much. Okay. Well, with that, we will head into my favorite portion of the show. Survey says. All right. Here we go. All right.

So a few episodes back, we asked, what is your favorite lesson from game jam and you know this was very uh sumptuous on our part that you participated in game jam because maybe i don't know maybe you did maybe you had things to do that weekend you know but uh that was rude so whatever we asked it anyways. And your choices were less is more or focus on playability or need more graphics or don't worry about the graphics or think like a player or, oh, my God, I need to theme the submission page or include instructions, video and or screenshots with your submission. Some of those submissions, man. Oh, my God. They're so good. So good.

All right. So this is what? Episode 156. It is, according to Tatako's Rules of Engagement, Jay-Z's turn. Okay, well, I think the answer has got to be less is more with 47%. Less is more, 47%, okay? Dig it. Man, that's what I was going to go with.

But in being a good sport here, we're going to scrum, and I'm going to try and push you across the line here. Uh, I want to say focus on playability and I'll go with 35%. All right. So we have Joe saying less is more 47% of the vote. And Alan called it. Obable was called.

Obable. You know what it's called? Abable? And Alan called Focus on Playability at 35% of the vote, right? Yep. So, well, Joe, I'm sorry. That's so excellent. Can you see that I'm having so much fun with my new toy? Great. It's a little thing in life.

Yeah, Joe, I'm sorry. That did not work out for you. You lost, sir. Another way you could say that is... Mission failed. We'll get them next time. Yeah, you failed. I feel like I failed.

So, yeah. Focus on Playability was the number one. failed. So yeah, focus on playability was the number one answer at 43% of the vote. Oh, nice. Now, if it makes you feel any better, less is more was second. Okay.

I thought less is more was going to win, but I thought he overshot the percentage. So yeah, that's, that's pretty cool. I was really hoping that you're both going to be wrong. Cause then that, that sound clip would have made, would have been even better. So, yeah, that's pretty cool. I was really hoping that you were both going to be wrong, because then that sound clip would have been even better.

So, yeah, whatever. Less is more. Yeah, that sounds like Lance. I don't know. Do you know, because it's not a very common name today, but in medieval times, people were named lance a lot i saw it coming man i saw the gleam in his eye from across the the county here whatever no you didn't liar liar you know i got you buzzing that's like lids you know it was a good segue it worked it was good it was good it really worked whatever whatever um all right fine let's talk about for

some reason uh i think we are in the mood to buy a car because for we got curious we're like hey for your next car you plan to buy and your choices are an electric car i can tell people it's because it's green but we all know it's about the acceleration or a hybrid just in case these evs don't work out or a gasoline car. There's other kinds or a diesel, a turbo diesel at that, or a fuel cell car like the Hindenburg, but on a smaller scale or Uber, the Uber mode of transportation or anything with more than two wheels is too many.

I love these choices. I love them. Yeah. I thought they were pretty well done. Yeah. The love these choices. I love them. Yeah. I thought they were pretty good. Very well done. Yeah. The Hindenburg. You're right.

Yeah. So there's all your shopping. Speaking of shopping, I went to go buy a dozen beasts from the farmer. However, instead of a dozen, I got 13. The farmer said, oh, that's a freebie. Oh, my gosh. Wow. Wow. Yeah, I see. I thought you were going to go with the beats of me

kind of thing. I should have known better. Is that a micro G? No. Okay. So in fairness, I did forget to credit, you know, in my references here, my bibliography. Micro G was the Lancelot and that one was from Niklaus.

Awesome. All right. Wait, Nick loss or class Nick loss. Oh, all right. So yeah, let's talk about sprint planning. Let's for a second. I thought we were at work, but I got scared. I know. Is this a nightmare that's some ptsd oh man okay so uh yeah go ahead i can think a little about sprint planning i can talk about sprint planning all right let's hear what you got yeah so y'all thought we weren't doing planning anymore we do lots of planning now uh so sprint planning planning is planning that, uh, at the beginning of each sprint.

And sometimes, um, uh, people will actually, uh, kind of keep that day out of the sprint just to do kind of stuff like this. And so, you know, we say every weeks, but really it's a 14 days or whatever. Um, and that's, you know, your miles, but very, we'll probably get there, but I want to hit some of the highlights here. Attendees, all developers, the, uh the scrum master, the product owner, and that's really important. So all the developers in the team, obviously the person leading the thing,

and the product owner. Just getting the product owner in the same room as the developers is really powerful, and just to be there to kind of hear and kind of get that interaction, because sometimes developers are really far away, so I thought that is really powerful. And just to be there to kind of hear and kind of get that interaction because sometimes developers are really far away. So I thought that was really cool. Product owners should have already prioritized the stories in the backlog.

And that makes sense. And it kind of keeps them in touch with like your ticketing system too, wherever you're keeping the stories, which is also really nice. Sometimes you have product owners that are completely divorced from the development process and this kind of brings them in.

And the goal of this planning means to ensure that all involved understand the stories and the acceptance criteria. So this is the time to ask questions, to clarify. I mean, you can do that anytime, but this is the best time to do it because it could infect things that happen kind of downstream of there. But this is not dive into technical details and try to architect the story during this session. Right.

Acceptance criteria. Yeah. If that starts happening, then that story needs to be redone. Yep. Scrum Master is responsible for keeping the people in line here too. So they're responsible for saying, whoa, whoa, hey, we're getting an implementation deal, so it's can't air. We need to be discussing the acceptance criteria and making sure you understand the story,

not the details, the story. You understand who the stakeholder is. You understand what you're supposed to be doing and you understand what the result is and that you understand what the're supposed to be doing and you extend your what the result is and that you understand what the deliverable is so don't get in details um it's not really the time to just get any details what if it's a bad story that would be a good time to say hey can we revise this let's split it so not not then necessarily i think that you you sort of say hey we need we need to discuss this because the very next thing that we have here is you need to plan for a q a session and so

that's probably where you would bring that stuff up again okay and i also need to make sure that overarching definition of done is uh posted as a reminder because that's uh kind of assuming you're in the same room. But it is nice to kind of have some document somewhere whether it's on a share or something that it's kind of reminded about. And then for kind of the acceptance criteria, it should tie back to that definition there.

That's a pretty... And the definition of done according to the DevOps handbook, that's a pretty big one then. Because that would mean it's deployed to a production-like environment. And tested. Oh, yeah, yeah, yeah. Sorry.

And observable. Yeah. There was a whole bunch of ands on that. Yeah. Okay, yeah. I thought you were, like, waiting to go into all the ands. There's too many. We thought you were about to. Yeah. all the ants. There's too many. We thought you were about to.

Yeah. No, I don't remember any of that stuff now. Oh, that was Christmas. Yeah. Last year. Three weeks last year. So I do want to reread it, read it on audio book anyway. So about that Q and a session.

So it's crucial to make sure that any misunderstandings, the stories are cleared there. I didn't realize there was a separate Q and a session. I thought that was part of the planning. So I'm glad that I read this. It is part of the sprint planning. It's just supposed to be towards the end of it, right?

Like after you've done your story pointing and all that kind of stuff. Okay. Yeah. So yeah, you don't want to hold it to me and you say like, Hey, let's get together later or we'll do this towards the end of it right like after you've done your story pointing and all that kind of stuff okay yeah so yeah you don't want to hold up the meeting you say like hey let's get together later or we'll do this at the end yes you ever notice how like sometimes your brain will just like latch on to something and no matter how many times you look at it you're like no that's just not oh that's wrong that's what it is and so the whole time i'm thinking like man we got a plan for a quality assurance session during the sprint plan that feels wrong and i was going to ask something about it and then i'm like oh wait a minute it's question and answer yeah q a yeah that makes a lot more sense we should definitely plan one of those i've had a vacation brain right just keep doing

that or i'll i'll be in a meeting or something i'll say something like uh they'll say q a session i'll say oh yeah let's get the uh q a people uh qa people on the meeting like no quality assurance i'm like yes you're right i told you i was paying attention and five minutes later i'll do the same thing and i'll even know it's wrong but i got vacation brain y'all yeah it happens that's right i mean it's part of the process it is so next uh stories are broken down into specific tasks these tasks are given actual estimates in time we're not we're not talking poker uh actual estimates in time like hours you're going to estimate these tickets and these tasks in hours and it's

important here to emphasize the tasks too so we take that story as a user i need to whatever and we're going to break that into like okay well someone needs to uh you know dockerize the thing someone needs to write the change someone needs to add the configs from there someone needs to set up a dashboard and it may not be the same person you know but the idea is to just list out all those tasks make sure that they solve uh the you know meet the acceptance criteria and that you can put estimates on each of those if something's too big break it up and at the end of that you add them all up and there you go you got an estimate for the story but i want to be clear though that like because we're we're talking about this in this, in the context of the sprint planning,

but breaking the story down into tasks and estimating it is not part of the sprint planning session. It actually is. Oh, it is. Yeah. So here's the thing. Here's the thing.

We're going to give you some background into the world that we live in right now to let you know. Prepare. Yeah. Here we go. So in a typical sprint planning thing, remember there's, there's seven people in there. And so you will do your story pointing. Then you'll do your Q and a to clear up anything. And then you'll go straight into creating the tasks. Wait, so sprint planning, you said there's seven people. Like I thought the sprint planning was like the whole developer team.

And then each individual team might be seven plus or minus two. No, that's what I'm saying. Like in a typical scrum thing, you have seven people is your team, right? You're going to have a scrum master, the product,

uh, the project manager, and then your team of seven people. Okay, plus or minus two. We just live in a world where we're more than that. Right. But so we have a sort of unique situation to where we have three teams of five to seven people. And so we did all the story pointing in one meeting because all the developers, all the people that sort of know

what would be going on are there. What we did afterwards, well, we kind of had our Q&A session at the end. It was more of a gripe session of things being buried in stories. But after that, the individual teams, the three teams broke out and did these tasks on their own. And it was because it doesn't make sense for teams that aren't going to be dealing with these stories to be sitting there twiddling their thumbs while you come up with tasks. Right. So I see. Yeah. What we're talking about is if you just had one team that you were working with. Right. But we had three. And so and that's the thing about Scrum that just to be clear, and we said it in the last episode is when you do the Scrum process, it's supposed to be about agile, which means focusing

on what the customer needs, right? But there are guardrails here. It's not set in stone. And for our particular use case, we were like, you know what? We got three teams. Let's let them go off and do those tasks, things on their own. So we're not wasting anybody's time. And then we're going to get back into this next part here that I think Joe's going to continue on. And then we'll talk about how we did that as well. All right. So at this point, we have prioritized things. We've asked our clarifying questions about, first, the actual acceptance criteria. And then we went through a Q&A session and kind of ironed out any kind of higher-level details. And then we went and broke down things in tasks, and we got our estimates. And so now, once that's completed, we have to verify that we have enough capacity to complete the tasks.

It's possible by the time that you finish listing up those tasks, you realize, hey, maybe we're a little wrong on poker. Maybe it's someone realized something we didn't think of that we have to do, or maybe we realized something that we didn't have to do that we thought we did. And so it's possible for those numbers to not match up so well. And so maybe what you thought you were aiming for this sprint isn't feasible once you see those numbers. Or maybe you need to go grab some more stuff. And so basically at this point, you're supposed to kind of look at this and say, okay, we can take this. And we've got some general guidance here that each team member can only complete about six hours of actual work per day on average. There's meetings, there's discussions, there's

you know... Lunch. Wait. I don't know. I think people in Europe include lunch break in their eight hours. This is a theory that I've had that I've never tried to verify. But I kind of feel like that's something that I'm very jealous about. So let me know if that's not the case so I can stop being jealous about it. But if it is the case, I don't want to hear about it. Yeah, don't tell me.

Let me know if it's not. But if it is, don't think. Let me go on in life being naive about it. Listen, the song is 9 to 5, and you know there was some lunch in there. Yeah, you know somebody ate. Yeah, that's right. Somebody's eating in there. Dolly Parton ate lunch.

Hey, don't think that didn't cross my mind, just like the 21 versus the 20 when we were talking about the Fibonacci party poker stuff here. Hey, but real quick, what's important. And I think we said it, but we might've glossed over it a little bit. When you're adding these tasks, you're putting those actual hours on there. And the reason you're doing it is at the end of it, you're going to look and say, Hey, the story that we, that we gave five points is, I don't know, 85 hours of work, right? Like that's your estimate based off the task that you added. And so now you look at that and you say, Hey, do we have enough capacity to complete this 85 hours of work knowing that we have X number of resources and all that kind of thing. Yeah, we got 86 hours. The person's out

one day. And so we've got a two week sprints, nine times six. Uh, who, no one knows what that is without a calculator. So, uh, if you've an 86-hour ticket, it's probably less than that. I don't know. I'm not a chicken. I mean, I'm not going to say it was 54, but it's like me. The math of a chicken just throwing random numbers out in the world. Definitely. So I had a lot of fun with that.

Then you're 54. Yeah, probably. I don't know. I'd have to see a number line to verify, but I'm pretty sure that one of those is bigger than the other. I would need to see stacks of M&Ms in order to verify it. Specifically the peanut butter M&Ms. Cause Oh,

those are, those are the best M&Ms. No, no, no, no, no, no,

no, My wife doesn't like them. No, no, I don't like them either. She's wrong. Peanut M&Ms. That's what she says.

She says, why not just to get the whole peanut? Yeah, man. Peanut butter. No, peanut butter is what she says. She says, why not just get the whole peanut? Yeah, man. Peanut butter. Peanut butter is way better than peanuts. We got to redo this survey. That's it. That's it.

These are fighting words. We could end this show. Coding box could come to an end right now. This is coming from the guy who would put a tub of peanut butter on top of some ice cream. I can't get behind this. Peanut butter ice cream is the best. You can even put just peanut butter in the ice cream. Just like scoop a –

Literally vanilla and just like scoops of peanut butter. That's good. But if you make peanut butter ice cream, it's like it's even better. It's infinitely better. It's true. Peanut butter makes everything better. I'm going to have to say – I'm going to have to request that we move on though because we should have really ironed this out in a previous phase.

We should have discovered Alan's deficiency here before we started recording, and now we don't have time. It's not part of the plan. That phase is over. As the Scrum Master, he's telling us to move on. I didn't realize his bias towards peanut butter before we started this show. Who would have guessed? It has no place in my M&m nor in my ice cream see see this is what i'm talking about yeah i can't go on what do you do if something just you just can't

complete it you just can't get it yeah i know it's a problem and that's why you got to make these estimates come up with this stuff and figure out ahead of time is this something that we think we can actually do based on these numbers? Are these estimates accurate? Yes. If not, then let's refine that. Let's bring it up. Let's make it smaller.

And in the end, we asked the person, can you commit to this work? They're going to say, you know, yes or no. If it's a no, hopefully there's a why. Talk about it. And they'll say, i disagree with this estimate or i do too much support work and so my capacity isn't what you think it is or you know something and so you know it comes to some sort of agreement there or else maybe hr gets involved i don't know how that works so i'm like i'm a good worker well hold up hold up in all honesty if somebody says

they can't commit then then that's when. So in the regular planning, like what we were talking about where we didn't have three teams that split out to do this, you do these task things and then everybody's basically asked, hey, can you commit to this? You say yes or no. And if everybody says yes, cool, fine. Whatever the story goes in the sprint, life is good. If your team says no, then, then you have to work it out with the project manager at that point and say, if you want this one done in this sprint, we've either got to break this story up or we're going to have to kick another one out. We're going to have to, or we're going to have to refine those acceptance criteria. You're going to have to move some of those things out to next sprint or other items. Or maybe we say this person can't commit. We're going to have to, or we're going to have to refine those acceptance criteria. You're going to have to move some of those things out to next spring or next other items.

Or maybe we say this person can't commit. We're going to have to take some stories from them and move it to somebody else and something like that. And so, yeah, I mean, if the person says no, they're not taking it,

you know, that's a deal. And commit is a strong word to when I hear the word commit, I think it's like, you know, locked in sign of blood and it's not the case. I mean, stuff happens, stuff comes up, things get reprioritized.

You know, this is the real world. Things get reprioritized or whatever I just said. Come on. You think of git. Come on. Don't lie. Oh, totally. Totally.

When I commit something in there, it's in there unless it isn't. Sometimes that happens. Yeah. Then you call outlaw and he bails you out. Yeah. So anyway. Yeah. So the important part of the know is you break things into tasks to get those hours and people say, yes, I got it. Yes, I got it. Yes, I got it.

Everyone says, yes, we're done. Until stakeholder feedback. I don't know anything about this. All right. So if I can speak now, I don't know what happened there. I'll cover come before you. Yes. So they have what are called the feedback that people are supposed to provide out to the stakeholders. So they have these things called information radiators.

We call those rats. There's a mole in your organization. So you're supposed to post out there whatever will help the stakeholders understand the progress of what's happening, right? That could be. So typically the way you used to see this is they'd have a whiteboard up with some swim lanes that is like, um, to do in progress and done. Right. And you would actually move stickies out of one swim lane into another. So you can do something just like that. It's called a task board or a burndown chart, and you can have a digital one that people have access to whatever. Right. But the whole

notion is people can look and see how things are going during the sprint. On the task board, these are the stories that were committed to the sprint, right? And that's, that's really good. And then you'll actually see the status of any current tasks, um, which tasks have been completed. Like I said, moving through the swim lanes. And it's a pretty good way for everybody to see, not just stakeholders, but the project manager, your scrum leader, and the team itself. And then the burndown chart, if you think about it, it's pretty easy, right? You just have a a line going, like you started it at 80 star, or let's go with what we had earlier. You had 10 story points is what you started with.

And by the end of the sprint at two weeks, you want to be at zero story points, meaning you've completed them, right? So what you want to see is the story points being completed sort of along that same line, right? Like you want to sort of be around where that line is, meaning that you're completing it as the sprint goes on. And that reminds me, I totally forgot about this when we were talking about breaking the stories out into tasks. And I didn't even mention this when we were doing it for real in our job is one school of thought is every task should be no more than a day's worth of work. And there was a really good reason for this. Is you constantly moving tasks from one lane to another. And if there is a task that stays in one swim lane, like if it's in the progress swim lane for more than a day, then it gives the scrum master a chance to say, hey, are we blocked on anything?

Is there anything we need to do? Hey, Joe, can you help Alan? Because, you know, he's not able to get this thing done quickly. So if you know that these tasks are supposed to go into in progress and then the next day during your daily stand up, it should be moving to done. And it isn't, it's a good spot for people to be able to say, Hey, I can help. Or what's the problem. Um, okay. That's news.

I didn't realize that we were supposed to, uh, estimate these things at no more than a day, which we're saying is six hours. Now you don't have to, it's a school of thought. Like I said, it's a way to make sure that things are moving through the, the process or the, through the swim lanes. It's interesting, right?

I mean, it means that it, okay, so here's the reason why I say I like it is it means that you've made the things granular enough to where you can do that, where I personally have problems with this and and like this is my own uh you know deficiency is that like i'll just see the story and be like okay i'm gonna start iterating i'm just gonna start right working on it and making it happen

like i don't care right i don't even need a task right yeah user profile you wanted to use a profile i'm giving you a user profile. Right. Getting there. Exactly. But so it's interesting. Like I said, it's a school of thought. It doesn't mean you have to do it again. Again, Scrum is guardrails. It's not hard, fast rules.

But it is an interesting thing to where if you did that, then you know when people are stuck. Because you know if they're not moving that thing that next day that they got stuck. So it's interesting um so at any rate yeah that that burn down thing is just so people can see how the sprint is progressing right and and you really want to see things burning down as time goes by um so when we say uh if we don't question do we estimate tickets in hours? You estimate tasks. Yeah. Sorry.

Tasks. So tasks will always be in hours because they're not really supposed to go over a day. So of course you're always doing it in hours or maybe half hours or something. Uh, yeah. And each, you're not supposed to go over six in a day. So yeah, uh, that's, that's interesting. And, uh, also like, uh, if you're in a lot of meetings, like four hours of meetings a day, and then throw in some support and stuff there in a day, it's like your day is really only two hours.

Does that mean it's the only right tasks that are two hours long? It's definitely hard. So, man, here's the thing. I think we should probably give some more insight into what we've been doing. I mean, how many hours of meetings have you been on each day this week yeah this week's weird but i mean hours are in the week plenty i mean it's it is i'll say there's definitely times when i spend more than four hours a day on the phone right um that's not i wish it was uncommon man i only spent four hours on the on the phone then it's like woohoo I got the whole afternoon to do what I want to do.

I mean, it's difficult, especially when you're starting out a process like this. Expect to be going through some rough times just because people are going to have questions. Everybody's trying to figure it out. I'd say after we did the first day of sprint planning, the next day was nothing but people trying to figure out, how do we break this down are we doing this right like there's just a ton of questions so the first two days were completely shot and then day three was a little bit more of it and so you know i mean we talked about this in the last episode too that like you know there you'll have some people on your team there will be a consultants you know that might get hit with questions from other teams and whatnot.

So that's going to happen. And so I think that's where we kind of field some of those questions that end up taking up some of our time. And that's just part of the job. We all are in principal positions. And so a lot of our time is like, it's supposed to be, um, you know, and in doing these kinds of things, we bounce around, we kind of advise on stuff. Uh,

we ended up being in more meetings in that. Yeah. We're, we're, we're the rising tide lifting all the ships, right? People think, except for the evergreen doing,

I don't think anyone ever described me that way, but I'll take it. Yeah. Well, except for, yeah, like I said, I was trying to make the joke about the evergreen,

but you guys ruined it. So whatever, I'm tired of all the jokes about the evergreen, but you guys ruined it. So whatever. I'm tired of all the jokes about the evergreen. Anyways, that ship has sailed. Yeah, it's you're right when you start looking at the six hours. But that's also why you got to look at the capacity whenever it's time to do it and say realistically yeah i am going to be able to do this or not right and and you have to try and be that way yeah and i immediately like sprint planning like immediately was like i'm out for a week this week is a mess because it's been planning like realistically my you know

my capacity is extremely low this sprint and so that that's what it is. Got to call it out and plan accordingly as best you can. Hey, so that brings up another thing that's not in this document anywhere, because this is all based off stuff we've learned about Scrum through other resources. But just own experience. Like one of the things that I'll call out to you that you need to think about if you do go into this is are all the resources on the team developer resources? Because that wasn't something we had considered when we first got in there. And a lot of the tasks that were built or stories that were built were based off creating this thing that was going to make this work. Right. And, and so if you have a team that is, I don't know, three full stack developers, a database person, and a QA person, you have to think about the tasks that you're

assigning out to all those different types of people, because just saying, Hey, I have five people and you know, five times 40 is 200. And then times three weeks is 600 hours worth of work and then multiply it and then, you know, automatically kill off two hours of each one of those. That's not necessarily your pool of working hours for development, right? You have a database specialist and you also have a QA person. So you need to be careful not to count all those towards the same task that you've set up. And that's something that is a little bit challenging, especially when you first started out, because you didn't think about that gap, right? Like you're just looking at, oh, here's the total hours of work we got,

and here's the total people we have. And that doesn't necessarily work out perfectly. Well, I think the real thing that you're highlighting there, though, is regardless of what the speciality is or the technology is, is that you're saying you have three generalists and two specialists. Right. And, you know, in that example that you're, you're describing, it's like, well, my generalist, I can easily just, you know, apply them anywhere. But those specialists, it's like only if there's this bucket of work that falls in this one vertical. And if I don't have anything in that vertical, then how do I utilize them? But also at the same time, I don't want to penalize the rest of the team by counting their hours as stuff that could be done.

So, yeah, that's tough, right? It is hard. I guess the right answer, I don't know. But maybe it's to try to like blend all of that knowledge. You know, you make your, your generalists more specialists and your specialists more generalist. Well,

that and the individuals have a chance to weigh in. So they can say, well, we thought we had this bush capacity by doing a little bit of math, but we, as we all know, math doesn't really work. And so when you ask the people,

do you commit this? He's saying, no, you're crazy because I've got this, that, and the other, I do this. There's no way I can commit to that work. And so when you ask the people, do you commit this? He's saying, no, you're crazy because I've got this, that, and the other, I do this. There's no way I can commit to that work.

And you say, well, what the heck went wrong here? And you realize that your, uh, the capacity that you started with was a, a faulty number because yeah, again,

math just doesn't add up. It doesn't add up. Yeah. See what you did there. And can we just say like, of course the math of my chicken would say that math doesn't add up and doesn't make it. I tried it before. It doesn't work. I get it. Yeah. say, like, of course the math of a chicken would say that math doesn't add up and doesn't make sense? Yeah, I tried it before.

It just doesn't work. I get it, yeah. It's like singing in the shower, right? It's like it's all fun and games until you get shampoo in your mouth, and then it's a soap opera. And that one is from Tristan. Thank you. Thank you, Tristan. That was very nice.

Oh, I will say the one thing that at least I've noticed is even when you have the specialist, when you have a team that's that closely tied towards getting things done, people seem because everybody has a vested interest in finishing that one story. Right. As opposed to, hey, I've got five tasks to work on. He's got five tasks to work on. She's got three. You know, it's instead of everybody being off in silos working on individual things, you're all working towards a common goal. So it seems like there is better collaboration. So definitely a good thing. All right. So now let's move on to one of the, probably the most key pieces of scrum in terms of, of making sure everybody's constantly in the know. And it's called the daily standup.

We've talked about this in the past. It's called standup for a reason. It's because you should not have this meeting longer than you're comfortable standing. And the max is universally said to be 15 minutes. And there's supposed to be three things that are supposed to happen in these things. There's collaboration, communication, and cadence. So here's the interesting thing about this one. The entire team is supposed to join. That's all your developers, your product owner, the QA person, and the scrum master. So everybody outside of the stakeholder should be in this meeting. Why the stakeholder? Huh? Why the stakeholder? I think because the stakeholder is usually there when they're being demoed or when they want to give feedback to things that are going on.

And once you've added things to a sprint, you're really not supposed to be trying to change things at that point, right? I think that's why. So there might be, yeah, it might be tempting to negotiate or whatever at that point. And it's not supposed to be happening. Right. And also, like, this is supposed to, I think, tell me if I'm wrong, but my understanding is this is supposed to be like a safe room, and you can get technical in the discussions. A little, but not much.

A little, but not much. Sure. It's fast, right? Yes, it's fast, and that's the thing. I can talk really fast if you'd give me a minute. So these are supposed to happen at the same time every day. Whatever. Do what works best for you. But, you know, try and keep it consistent so people aren't skipping out on it. Right. Like if it is the same time every day, then people are aware of it. It's supposed to be an overview, meaning it's light on the details.

That's key because as soon as people start diving into details, us as developers, it tends to go long. Now, this is where things are supposed to visibly happen. You're supposed to take a task and move it across the board, right? If you're doing things virtually like what we do, then you could have a Jira swim lane board up and just drag tasks along the way, right? Through the swim lanes. And you're sharing that so everybody sees it. Stakeholders, so this is what they say. Stakeholders can come to the scrum, but they have to hold their questions to the end. So they're not allowed to interject and start trying to change things and all that, Right. They can ask some clarifying stuff at the end. Um,

so there's supposed to be three questions per person. What did you do yesterday? What are you doing today? And is there anything blocking you? They should be short, sweet and to the point. That's really what it is. Um,

what's a blocker. This is a blocker mean I can not progress? Does a blocker mean I cannot progress, or does a blocker mean something is slowing me down? Oh, that's an interesting way of putting it. I would assume that it would be you can't progress, because something that's slowing you down could mean that maybe it just wasn't estimated properly or or yeah or maybe you know maybe it was estimated for assuming somebody else who might

have already had experience with that technology or that area you know but and you don't have that so you're trying to get caught up to speed right is one way you might interpret slowing you down yeah so i was just thinking like maybe if you're struggling with the ticket, maybe it should be kind of mentioned as a blocker because maybe someone else on the call can say, Oh, you know what, here, let me communicate and collaborate with you on, you know, something that might clear up some, whatever. Have you seen this? And then you don't want to talk about that in the meeting. This is not a place for discussion, but half maybe it can happen afterwards. I was just kind of wondering about that. Like if I say, well, okay, you know,

things aren't going as well as I'd hope because blah, blah, blah, blah. Am I wasting everyone's time? You know, is that relevant? I think it's definitely important to like call it out to say like, you know, Hey, this is what I'm working on. It is taking me longer. Or maybe even like if you started on it yesterday, like, yeah, I expected to have this done, but I'm having some, uh, some difficulties or whatever. Uh, you know, I hope to get it done today, you know, kind of situation. Then I think that would be appropriate to like, you know, at least express, you know, that there

is something slowing you down. And, and by the way, this is a good time for somebody else on your team to be like, Hey, I know what to do here. I can help. We can jump on after this and, and, and go do it. Right. So that's actually a really important thing that came up because when we were talking about this entire scrum process with our team, one of the things that did come up is like one of the jobs of the scrum master is anytime a blocker is brought up during one of these, these daily standups, it's the scrum master's job to go and try and remove that blocker after the meeting. And what one of the concerns was from our project manager was, hey, I don't want to wait until the next daily standup to raise a blocker. That's not the point. If you're working on something

and you're blocked, it's your due diligence to go try and unblock it, right? Like you don't sit on it until tomorrow. If you're blocked at 12 noon today, you don't wait until your call or until your stand up tomorrow at 11 a.m. to do something about it. You try and get it taken care of. Contact. I can contact Outline, contact Jay-Z. I can contact any number of people and be like, hey, can you help me here? If it's still not resolved the next day, then the Scrum Master kind of goes and tries to take it up to the next level, right?

Like, hey, I'm going to talk to the project owner or the project manager and be like, hey, can you try and get something done? Because we've tried to and we can't, right? So this is not a, an excuse to sit back and do nothing. It's just a nice way to escalate things if you're not able to get them done. Okay. So I, so I think my answer,

so the answer there that I was wanting to hear is, is maybe it's not listed as a blocker, but it's, you are supposed to highlight the important things in your yesterday and today story. And so that's a good place for it. But the blockers is really an escalation channel. So unless you need that escalated, it's, you know, I don't want to hear your excuses. Yeah, basically.

I mean, yeah, if you can't take care of it on your own and you need some assistance, sure. That's when you bring it up and like, hey, you know, we've been trying to get Team X over here to do something and they're not able to get to it. And it's, and it's stopping us from being successful. Then, then maybe they do something. Um, so it's, it's interesting. Again, these aren't hard, fast rules, but they're, they're a framework to work within that can be helpful. And yes, this is also an opportunity to where, you know, I'm stuck on something for two days. Scrum master is going to be like, Hey, you haven't made any progress on, on two days on this. Um, do we need to get you some help? Right. So it's kind of on them to sort of hold you accountable to a certain degree and also try and help you along so that

you're not flailing around. Right. Like, so the process is there to try and help you along so that you're not flailing around, right? Like, so the process is there to try and make sure everybody's succeeding, really. So that's pretty much it for the daily standup. And again, they're supposed to be short, short, sweet and to the point, no more than 15 minutes. It can be shorter if you want it to, if it finishes in six minutes, cool, but it cannot go longer than 15 and you it to if it finishes in in six minutes cool but it cannot go longer than 15 and you have any shut it down if you have any long-winded people that try to uh get too verbose in their descriptions you should shut that down yeah it's actually scrum master's job yes it's

the scrum master's job saying hey um we kind of need to stick to the format here because you know we got to get through this pretty quick yeah joe um somebody else want to take the backlog refinement so okay the backlog refinement this is part of that grooming process that we talked about before but this should be constantly changing as your business requirements are going to change over time. So like what you thought was important today, tomorrow might not matter anymore. It'll fluctuate with the price of Bitcoin. It is the jobs of the product owner to be in constant communication with the stakeholders to ensure that the backlog represents the most important needs of the business and making sure that the stories are prioritized in value order.

So real quick, I made this mistake too. It's project owner. So it's basically the project manager essentially, but go ahead. Okay. But this goes back to our like utopian, you know, world of, you know, you have this perfect backlog and you this perfect backlog and where we didn't get to start out in that world because we didn't do that process first. But these stories are constantly being modified and added or removed. So maybe you thought you wanted multi-factor and then you decide part of your upcoming user profile story doesn't need multifactor authentication. So, you know, you might remove that or maybe you decide that you want to change, you know, the support for that multifactor to be a meeting, maybe a 30 to 60 minute meeting that will be this backlog refinement session where the team will come together or dial in on the same virtual call to understand these new stories, um, and, you know, try to,

you know, get a feel for them. And these stories can only be added to future sprints. And I think that's something, I don't know that we've described that so far, but once you're in a sprint, uh, the goal is, you know, you can't change the current sprint. Oh, in fact, we said the sprint commitment cannot be changed once the sprint begins. So, yeah, hey, we were getting to it. Hey, and in our real world, it's locked down. Nobody's even allowed to touch them, right? Like once the person who has the ability in Atlassian Jira to set the sprint, nobody else can touch them. So it's kind of forced on us.

Well, I mean, if you have something come up that's high priority and production's down, it's on fire, you go handle it, right? This is the real world. But you don't change the sprint. You don't move stuff out because then that's going to mess with your forecast. And you need to see when things break down

and figure out why and adjust your things accordingly. Because if you see that three of seven of your sprints went off the rails because of production support issues, you either need to fix production or adjust your capacity or velocity. You know, it is your it already affects your velocity. Yeah. The importance of this mid-sprint session is that the team can ask clarifying questions and be better prepared for the upcoming sprint planning session. So this is why we were talking about that utopian world of if we had had a couple of these, we would have probably been better off by the time we did get to that first sprint planning session because instead we were all looking at these stories for the first time. So the whole point of this is to not get that. And you don't want the surprises, right? Yeah. And this helps the project owner know when there are gaps in their requirements and helps to improve the stories. So that by the time you do get to that sprint planning session, then, you know, maybe they've been able to add that refinement. And just a thought on this too, these midpoint things, I don't think that you want the entire

team there. It's probably some of your team leads or something like that, that you want in these that are going to do enough critical thinking to think about what's missing or what gaps are in the stories, because you're not trying to make them perfect. You just don't want there to be any surprises like what we were talking about in our first go around. So then there's – Okay. I was going to talk about marking a story done.

Is that what you wanted to talk about? Yeah, I did. All right. You can go ahead. You want the same things. Okay. So the product owner has the final say in making sure that all acceptance criteria has been met. That sounds a little bit much, though, right?

Like, I mean, can we be honest? Like, they're going to delegate that. They're not going to go and click around and everything. Yep, multi-factor. Yep, see it. Well, the story should be pretty high level. It should be like, you know, they show it to you in the demo and they say, well, what about this? What about that?

And then you say, you know, either I messed up or we didn't talk about that for the acceptance criteria. And over time, the idea is that, you know, both sides will kind of help train each other and get to where the communication is. And you're communicating all the time, right? So eventually over time, you get to a spot where you're pretty good. So your first sprint is probably gonna be pretty rough, but your 40th sprint working with the same people, hopefully that should be, y'all should be a well-oiled machine.

And again, that product owner is, or the project owner, I even do it. The project owner is in those daily standups. And so they're seeing the progress of this thing. So it shouldn't be hard for them to tell you, yeah, I'm not going to be able to sign off on this, or yeah, this is looking good, right? Like, great job, everybody. No surprises, right? No surprises.

Exactly. Yeah, so you could have another meeting called a sprint review where the entire team meets to get sign-off on the completed stories. And then anything that's not accepted as done gets reviewed, prioritized, and moved out to another sprint. So maybe you thought you were done, but in the case that you mentioned where some other criteria comes up or, hey, what about this, or did you think about this, then that's how you can address that.

And this can happen when a team discovers new information about a story while working during this sprint. It's kind of weird to be out a little bit. Cause you, it does say you move the story out and that story has tasks, tasks have estimates. And so you're kind of dropping this half done thing into the next sprint,

which is a little bit awkward. Um, but it doesn't really offend me as long as you're tracking it appropriately. I guess the important thing is the story points, whatever it is, is going to affect your velocity. So it's going to show you only finished 36 of what you thought would be 66 points or whatever. And so I guess it makes sense from that point,

but it is kind of weird in that by dragging over, you're kind of taking something that's potentially half done or 80% done and moving to another sprint. So I don't know. It seems like it would kind of mess with the charts to me. So hopefully this doesn't happen too often. Right.

I think what would probably be more apt to happen is you would create another story with the remaining bits and add the task to it, or maybe even transfer those tasks over that you didn't get to complete. It makes more sense to me. And you would title that story something like, Finish the First Story. Right, yeah, seriously. But you've got to phrase it as a question. You know what, though?

As a project owner, I want this first story finished. Yeah, because I told you I need this. I told you. What's funny is, honestly, when I was going through this entire learning process with all this garbage, that was the one thing that bothered me is everything seemed to be so perfect. Right? Like, oh, Scrum's going to be, you're going to be able to track your velocity. You're going to have these stories that are completable in a sprint. You're going to have this and that.

And everything just looked like, you know. And there were world peace and unicorns and rainbows. Right. You have these fields of lavender spread out everywhere. and that and everything just looked like you know world peace and unicorns right rainbows right you have these these fields of of lavender spread out everywhere and i'm like wait no there's something that stinks here and what and what happens when things go wrong and and i liked it that they called out that hey things are going to go wrong you break out a new story you move some things into the next one and then hopefully that lets you identify where you missed the gaps this time. And in future sprints, you'll be aware of those gaps and you'll plan better.

Now, here's the best part about this process, the demo. So this is going to happen towards the end of the sprint. And this is an opportunity to have direct communication between the team and the stakeholders and to receive any feedback, which that feedback may result in new stories. Right. But, you know, it's also,

it's also possible that the stakeholders might not even want the new feature that you spent the front working on, which it's okay. All right. I mean, if we're honest, it's like, it's going to the front working on, which it's okay. I mean, if we're honest, it's like, it's going to hurt a little bit,

but it's okay. It's okay. But, uh, it's better to find out early rather than sinking more time into building something that they don't want or need. Right. So, yeah,

but I mean, you know, let's face it. We're all gonna be like a little, little hurt about it. Um, you know, whatever, we'll move on. But, uh, it's mean, you know, let's face it, we're all going to be like a little hurt about it. Yeah, whatever.

We'll move on. But it's a great opportunity, though, to build the relationship between those team members and the stakeholders, though. And I think that can be really key. Now, again, in this particular case, though, the stakeholders are like your internal customers, not the external, because, you know, you're not going to have a demo with your external customers necessarily. Maybe, you know, in a big enough situation, maybe. But this demo also shows the overall progress towards the final goal. And you may not be able to demo at the end of every sprint, but you want to be able to do it as often as possible. And I really do think that this is one of the best parts

of it. The fact that this is encouraged and formally a part of the process. Showing progress is a big deal to everybody. It really is. Imagine you just join a company, right? You're a few years out of school, and you just join a company, and you get to work on something, and now you get to show it to your peers, right? That's going to be an exciting moment, right? Yeah.

So it gives everybody – everybody likes to take the spotlight for a little bit, right? No matter who you are. So, so there's nothing negative. There's no bad about it. And that's the stakeholder. So they didn't even want it. Right. If they don't want it. Hey, but then at least you didn't waste too much time. So that's true. I mean, you only wasted one sprint. Right. So the last bit of this entire framework, and this is truly, this is it right here, is the team retrospective. And this one's interesting because everything else that we've talked about so far has been about the product and how to move the product forward, you know, the task for the product, the stories for the product, all that.

This is about your team and the people on the team. That's what this entire thing is about. The scrum master is the one who facilitates it. And this is a closed door session session. This is not the project owner. This is not anybody outside the team and the scrum master. That's it. So, um, you have to observe your norms, which we talked about those. You're supposed to have how people interact, how to handle conflict, all that kind of stuff. You need that there. But the important part of this thing is you want an open dialogue. What worked? What didn't? What can we do about it? How can we make it better? What are the actual steps to actually go and improve this so we don't

run into it next time or in the future. Right. And they actually say, put items for improvement in the backlog. It should be a task type thing, right? Like, I mean, I know the three of us can give examples of just having deployment pipelines that are a pain in the butt to work with,

right? Like there are times that that slows you down. What can you do to improve that? Is there anything? It's a great way to address your technical debt. It is. It totally is. Yep.

So if there are things slowing you down, you can put actionable items back there. But they did say one of the big things that you want to do here, if you are the scrum master especially, is you want to start with the successes first, right? Like get people excited about the things that have going on. Like we,

we, we did a great job. We've got this stuff out there, you know, all this kind of stuff, but Hey, you know, we really need to work on a,

B and C. Um, and what can we do to get there? Bob's stories are always terrible. He always tries to trap us to the end and it's closing. We got to do something about Bob. Right tonight it's closing we gotta do something about bob right there's that and and it like a realistic thing would be hey um alan i saw you struggled on this thing for three or four days before you asked for help um next time let's not wait so long wait you know after the second day and not making progress um

let's let's raise that flag quicker, right? Like it can be anything. But again, the important part is this is a safe room. You're not trying to tear anybody down. You're trying to figure out how you can be more effective in future sprints and work well together. I dig it. So what do we think? It's a lot. It's a lot.

It's a lot. I definitely have kind of had a bad taste in my mouth about Agile because I was familiar with the manifesto. I kind of saw where it kind of sprang out of and saw over the years the industry spring up around it and the consultants and the trainings. And I totally see why companies send their development people to, to, uh, training meetings for like two weeks to get this stuff right. And then kind of bring it in and then have mixed results. And,

uh, I've also see, uh, you know, why some people say, uh, this is too complicated for us. Let's go,

let's kind of forge our own path using the pieces that we like, and then end up, uh, you know, kind of suffering with the some areas that they didn't take you know because maybe they're skipping retrospectives or daily stand-ups and that's uh areas that are having problems and sometimes it works out really well so i don't know i still have mixed feelings about it i'm excited to give it a shot and really try to do things kind of by the uh quote unquote book

or kind of modern standard i guess i should say say. So, you know, I'm looking forward to it. But, you know, for my little projects, my game jams, my stuff, I'm not really planning on doing too much different there. And like we said, you know, the ideal team size is seven plus or minus two. So I'm nowhere near that. And so I feel justified in kind of staying away from that for solo things. And I have no intentions on being any sort of director or anything anytime soon.

Uh, and so I don't have to worry about anything bigger than that. So it feels like a good spot for work type stuff. And, uh, for me, it'll stay at work. So if you disagree with anything,

uh, you can reach our director of communications, uh, Joe Zach on Slack. That's right. I'm going to do some tips here, but I'll have resources in the show links, including the Naughty Word Twitter account with 58,000 followers and 100 tweets.

This is just that good. I do have a couple questions that I thought I'd ask. One, I think I've already asked this one in the past, but, uh, you know, I figured I would do it justice that, uh, you know,

what's the object oriented way to wealth, to weld, well, to wealth inheritance. I know this one. Yes. Yes. Thank you,

Simon. Yeah. But that was also, uh, you know, made me think about like, what do you call a factory that makes okay products? A satisfactory.

Oh, my gosh. And with that, we head into Alan's favorite portion of the show. It's the tip of the week. All right. Looks like I'm starting off. So I want to tell you about a little tool I just found and showed Alan the other day. I thought it might be a good thing to mention.

So I was having an issue with a Genja 2 template, if you're not familiar with that. So basically a Python templating language for generating documents, HTML text, markdown, stuff like that. And in my case, I wasn't in a position where I was able to easily run the app. And so the thing I needed to do was at the very end of this kind of long process. And it was

really slow. And there were some things I wasn't sure about some functions I wasn't familiar with. I'm not really familiar with Jinja anyway. So I just Googled like Jinja template online, and I found a site that did exactly what it let me kind of do some experimentation and do some things in a cheap way that didn't involve me having to get things kind of set up. And so I was able to figure out my stuff really easy there. And so I thought I'd mention whatever templating language you're doing, you can probably find an easier way. So anytime really that you've got like a long, slow feedback cycle, it might be worth checking out some online tools and Googling for stuff like that.

So I wanted to mention that as a tip because sometimes it can really save you a lot of time and you can just figure out something quickly. And even if there wasn't an online version, you can just spin up a quick site, Django New Project, whatever it's called, and try some stuff like that. It's much easier than waiting two hours to figure it out if you got the parentheses in the right spot or whatever. So I want to mention that. than waiting two hours to figure it out if you got the parentheses in the right spot or whatever so when i mentioned that also bonus uh andromeda misspelled uh so it's like andromeda m-i-d-a at the end is a instrumental band that i've been following for a while and they just put on a new album which is uh i would say heavily influenced by the new Doom game soundtracks, which I'm also a big fan of.

And so if you like heavy instrumental music, then this is a great listen to. It's great for working to. And it's not as, we'll say, spastic as the Doom soundtrack. So it's a little bit easier to listen to while you're working. And so I think it's great. It's awesome. So I'll have a link to that on Spotify. there to listen to while you're working. And so, uh, I think it's a great, it, uh, you know, it's awesome. So, uh, I'll have a link to that and on Spotify or even just on YouTube or whatever, too. All right. Well, uh, for my tip of the week, uh, I had mentioned windows terminal, uh, I think in the last episode, not switching over to Terminal. And I thought I would share

this time that if you have made the switch to Windows Terminal, you can easily use like the keyboard shortcuts to switch to create a new, you know, open up a new prompt for whatever your favorite shell is. And, you know, it is really nice because it'll show you, you know, like, hey, it's this one's control shift three, this one's control shift four, whatever. But one of the things that was a little bit hidden, unlike Connie Mew or Commander, is that, you know, if you wanted to open up a new terminal and you wanted to split pane the screen with that new terminal in Connie Mew and Commander, it was like super easy. It was like in your face, you know, and you wanted to split pane the screen with that new terminal, in Condom Union Commander, it was like super easy. It was like in your face.

You could like, hey, do you want to split this off to the left or the right or the bottom or whatever? And in Windows Terminal, instead what you have to do is use the Alt key and click on your shell of choice and it will do that. And so once you then split it the first time, then you can select, you know, one prompt or the other, and you could do it again and again and again to keep splitting whichever one you have selected depending on, you know, your needs. So yeah, I'll click to open up a new terminal. Cool.

All right. I've got a few. I'm going to try up a new terminal. Cool. All right. I've got a few. I'm going to try and blast through them pretty quick. First. So first, if you're not a member of our Slack community and you've made it this far into the episode, you probably should be because there's a lot of awesome people that share a lot of awesome things up there. So the first one is from Ron in our tips and tips and tricks, tips and tools channel. I can't remember. Um, this one's awesome. It's a site on how to make different kinds of knots. So I know it's not program related, but man, how many times have you needed to tie a certain type of knot and you have no idea, you end up spinning things around 500 times. I'm not a boy scout. I get annoyed. And I know that knots

are really useful. This is awesome. There's like little step-by-step you can click frame one, frame two, frame three, and it'll show you exactly how to do it. Really cool. So should go do that. The next one, this is excellent. I saw this in that same channel and this is from Batterfoot. So this is, you know, that like, if you decide you're going to zoom and I have to do this all the time, cause I'm on a big monitor. And if I'm sharing my screen with people, I I'm, I'm always zooming in and out, you know, so that they can see. And so I'll do command plus, plus, plus command, minus, minus, minus, whatever. Well, the thing that stinks about that is if you're in Chrome, it does it for all your

tabs. So you go from tab one to tab two, you zoomed in 400% on tab one, tab two is also 400%. There's a, uh, an extension for Chrome that will allow you to do per tab zooming. That's really cool. So there's one. Wait a minute. Huh? I want to like throw a caveat on that though,

because that's not entirely accurate, right? Like the zoom, the per tab zooming, it does do it per tab if they aren't the same domain. Hmm. That's interesting. I don't know if I've noticed that. Maybe I'm in the same domain so much. That's interesting. I don't know if I've noticed that maybe I'm in the same domain so much that I don't. At least that's been my mileage. And I even like verified it just now.

I opened up some, you know, another tab and zoomed in, super zoomed in on that one. And it even says in the description, apply zoom to each tab independently of other tabs of the same website. So it's specific for that. Yeah. Yeah. Okay. Good call. That makes more sense.

I never even noticed it. All right. So that's pretty cool. So my last two are all about shortcuts. So I don't like using a mouse. I try to avoid it like the plague because my hands are always on the keyboard. So the first one is there is a problem of that problem is because you got like a 58 inch monitor in front of your face so it's like yeah well yeah way too much effort to drag

that boat anchor of a mouse plus you don't like to have your sensitivity turned up as high as i do so you're like oh really just dragging that thing around right it's a workout yeah i'm not trying to curl while i'm working so this though if never, if you, there's lots of people that probably have no idea about this. GitHub has tons of shortcuts. So I've got a link to all their shortcuts, but I want to share with you my favorite one, which is the T button. If you're in a get repo and you click the T button on the keyboard that puts you into a search for file type thing. And so if you know the name of a file puts you into a search for file type thing. And so if you know the name of a file, you start typing the file name and it'll pull up a list of things and say, hey, which one of these files did you want?

Right. And you click it and you're at the file. This is awesome, especially if it's repos that you're familiar with and you just need to get something really quick. And and that search, by the way, will also let you search for directories. Like if you know the name of a directory, you can type in that directory and it'll show you all the files in the directory. So love that shortcut. Is there a shortcut for GitHub that'll make it use the full screen of my monitor? Man, don't I wish.

Yeah, for real. And then, all right, so along the same vein, I work with so many people that I see using Visual Studio Code that they just don't, they've never taken the time to either read the great getting started pages or something. Yeah, whatever, right? I'm not going to say RTFM, but there are some really good things that are built into the thing vanilla out of the box that people just don't know about. My favorite one is very similar to the T thing on GitHub. And if you're on a Windows machine, it's Control-P. If you're on Mac, it's Command-P. But if you do Control or Command-P and you start typing the name of a file, it'll come up in that list and you

can just click it and it'll open it, right? If you know the name of a directory, but not necessarily the file, you can start typing the name of the directory. It'll give you the list of the files. So it's fantastic. It's a nice little quick shortcut to do. And then alternatively, there's another thing that I really like that I just don't see a lot of people use is command shift P or control shift P. That brings up the command palette. And so like all the functionality from plugins and stuff that you've installed, it's all available right there. So like an example, I see a lot of people do this. A lot of people do this.

You don't have to. If you copy and paste some JSON from somewhere and you put it in Visual Studio Code, a lot of people think they need to save that as a dot JSON file on their system to get that formatting and all that kind of stuff in there. You don't have to do that. Paste it into a blank document, command shift P, and type in the words change language. Just start typing change and you'll see change language mode come up there. Hit enter on that thing and then choose JSON. And now you've got it.

Now, there is another easy way to do that in Visual Studio Code. You can just go down to the bottom right where it says plain text, click on that and choose JSON. But again, I hate using the mouse. So my point in telling you this is there is tons of functionality built into that tool that is just absolutely amazing at making your life way easier and more efficient. So hopefully these are a couple of things to kind of wet your whistle a little bit and get you moving forward on that. I have another tip for you.

Okay. I just Googled this based on what you're saying. Cause I do this all the time. I go down in the bottom right corner. I changed Jason, just like you mentioned. The thing is, it's almost always Jason that I'm pasting almost always when I'm pasting

something and changing. I was like, you know what? I bet you can set the default for a new file because if it's text, who cares? I never, I'm not using code for text. So you can, uh, if a new file because if it's text, who cares? I never, I'm not using code for text. So you can,

uh, if you control K or command K and then, and then the letter M afterwards. So controlling K together and then M afterwards, you can actually choose the, uh, language. Wait,

not for the file. Sorry. That was just for the file. It's under click file preferences settings, and you can go change the default file. So every time you create a new file, you can just set it to be JSON. If you're using it for Python all the time, you could probably do it for Python or something too,

but I would definitely do JSON here because that's so common for me, and I don't like Googling for it every time I want to know. Yeah, I was going to say the one that Alan mentioned specifically about changing the file, the language mode, you can do it in the bottom right or you can go up to one of them. It's buried also in the menus too, like in the edit menu maybe. Or the control K and then M that you mentioned is the one to bring up that change mode and to and, um, this to select, to change the language mode of the doc, the current document you're in. And, um, when Alan mentioned, if you do the control shift P or command shift P, depending on your operating system, the, um, when it's

showing you those various commands, like it, you know, if there is a keyboard shortcut, it will show you the keyboard shortcut that you could type in otherwise to, you know, to not have to go through the command palette. Um, but you know, I hear you on that Jason thing though, because where I'm typically doing is when I do paste it in where,

when I find myself wanting to change the language mode, it's because I want to use the formatting. I want to, I want to actually do the shift mode, it's because I want to use the formatting. I want to do the... Alt-Shift-F. Yes. So I'll like, okay, shift it to change it to JSON. Okay, Alt-Shift-F. Okay, now I can read it

because that other stuff was just garbage. Right. No, it's just, man, it's such a useful tool, even for people that aren't doing regular programming, even if you're a database person or whatever, it is such a useful tool, even for people that aren't doing regular programming. Even if you're a database person or whatever, it is such a handy tool. And these little hints, just these little things, just even though they exist, can save you so much time. So, yeah, that's all I got. Yeah, Visual Studio Code is awesome.

And I'll tell you this too. Here's another bonus tip for you because we've been chatting about this one around the office. So there's WSL and WSL 2 has been out for a while. And I think I might have mentioned that in the last episode, WSL 2. It sounds familiar. But at any rate, if you haven't used WSL2, it's available, and especially it's important if you're using Docker. A lot of improvements have been made to speed up your Docker world.

And, yeah, I mean, Microsoft is only, like, improving their integration with WSL over time, and specifically WSL2. And one of the cool things that has happened is, you know, there was a Docker blog article that I shared with our team where the Docker community was saying like, hey, here's the best practices for Docker plus WSL2. And one of the recommendations that they had was to use WSL, your WSL two environment for everything as much as you possibly can, which means that if you had to, uh, you know, clone a repo and you're working with a repo, you should do all your get operations inside of your WSL two. And instead of doing it from like a command uh command

prompt or powershell prompt right and the reason there are reasons for it were like for file io simplicity but you'd also gain the ability of like these these uh you know linux tool chaining that you could do but the but the idea is that like anything that you can do in WSL two, then, um, if, if it's, if the files are in that Ubuntu or a WSL two, you know, file system, then there's no like facade that has to be gone through in order to get to the file. Right. Because if you had it in windows, yes, you can access it from your WSL two instance, but you're kind of like going through this facade to get to it. Right. And, And you definitely take a performance hit on that. Even in my own experience, I've got Git repos where if I do the Git command in PowerShell, there's like no hesitation at all.

Just boom, pops up the response. Whereas if I were to do the same Git status command in an Ubuntu instance through WSL2, then there's like a four-second delay. But where the rub is on that is that depending on your use case, maybe you're like, well, I need to use a tool like a Visual Studio. I need to use a Visual IDE. How can I access my files if they're under Ubuntu? Which Visual Studio Code we can put aside because that one makes it easy because if you were to try to open up the file system,

Visual Studio Code would automatically recognize like, oh, hey, you have a WSL instance. We can connect to that. Or if you were to launch code from your WSL instance, then it would automatically make that connection. And if it didn't already have the WSL server extension installed, then it would install it so that it could make that connection. But here's the thing that I didn't know.

When you use WSL2, Windows will automatically map a network share to WSL dollar for your WSL2 file system. So you could, you could do all of your get cloning, for example, inside of your WSL two instance. And then you're like, Oh, but I need to use visual studio code or, uh, you know, I want to open up these, these, uh, SQL files in data grip or my SQL management studio. You could open up the path files in DataGrip or SQL Management Studio. You could open up the path using a network file share path like slash slash WSL dollar sign slash home slash your username, assuming you put it in your user folder or whatever,

wherever your path may be. You could find it using that route. And in File Explorer, you'll get type ahead. Oh, one thing I forgot. I did say that a little bit wrong is that the the path would be slash slash wsl dollar slash and then the name of your wsl instance so okay so if you had a w um if you had a an ubuntu 2004 instance installed and then you know like i had a username of michael right if i wanted to get to that home directory then the path the unc path might look like slash slash wsl dollar slash ubuntu 20.04 slash home slash michael nice so a hidden chair is what it's putting in windows for

you for yes and but the thing is though is that like because it is you what it's putting in windows for you. Yes. And, but the thing is though, is that like, because it is, you know, it's kind of like a network facade, but like, you know, it's all in the same on the same box. So it's, it, you know, not really that bad. I mean, you are still giving up. There is still some give and take, right. Because you know, one, either one of those sides of the equation is going to like kind of have to go through this facade to get to it. But depending on what your needs are, maybe you can prefer to take that hit on the Windows side

rather than the WSL side. Pretty awesome. Yeah, so there's your 85 tips of the week uh sorry we we fell short on a couple there and uh if you haven't already subscribed to us uh we would greatly appreciate it you can find some helpful links links plural now at uh www.codingblocks.net slash review um you know if you find a place to you know you like to listen to podcasts and we're not there www.codingblocks.net slash review. If you find a place you like to listen to podcasts and we're not there, let us know. We will

fix that and make sure that we are listed there. Obviously, if you're listening to us because a friend might have shared a link with you or you're listening on their device, you can obviously find us on all the big platforms, iTunes, Spotify, Stitcher. Audible. Boop, bo, iTunes, Spotify, Stitcher. Audible. Boop, boop.

Oh, yeah. Boop, boop. Audible. And while you're up there, definitely check out the show notes. We spend a lot of time putting those together to help you out when you want to go back and just remember something without having to re-listen to an entire short episode. And you can send your feedback, questions, and rants to our Slack channel. And Twitter. If you're on our Slack channel. And Twitter.

If you're on Twitter, we're on Twitter. We can hang out together on Twitter at CodingBlocks, or if you go to CodingBlocks.net, you can find all our social links there at the top of the page. And don't forget about our LinkedIn Ponzi scheme. I know, at least for me, if you want to go ahead and send me a LinkedIn invite, as long as you don't look like a recruiter, I will accept it.

We can spread the Ponzi scheme on out and uh rake in all the whatever linkedin internet points so uh yeah do that at conebucks