Coding Blocks - What is Scrum?

Episode Date: March 29, 2021

During today's standup, we focus on learning all about Scrum as Joe is back (!!!), Allen has to dial the operator and ask to be connected to the Internet, and Michael reminds us why Blockbuster failed.

You're listening to Coding Blocks, episode 155. Subscribe to us on iTunes, Spotify, Stitcher, wherever you like to find your podcast apps. We're probably there. And you can visit us at codingblocks.net where you can find show notes, examples, discussion, and a lot more. And you can send your feedback, questions, and rants to comments at codingblocks.net. Yes. And you can also follow us on Twitter at Coding Blocks. We also have a Facebook page, which I think is facebook.com slash codingblocks. Maybe it's codingblocks.net. Yes, and you can also follow us on Twitter at Coding Blocks. We also have a Facebook page

which I think is facebook.com slash codingblocks maybe it's codingblocks.net. I have no clue. But, codingblocks.net slash Facebook. Slash Facebook. You can find all our social links there at the top of the page on www.codingblocks.net and with that I am Alan Underwood.

I'm Joe Zach. And I'm Michael Outlaw. Yes. Joe Zach. And I'm Michael Outlaw. Yes. Joe Zach is back, baby. He's dug out of the hole. This episode is sponsored by Datadog, the monitoring and security platform for end-to-end visibility into modern applications. All right. So this episode, we're going to be focusing on a topic that I think we've avoided like the plague over the years, and it's all about Scrum and the Scrum process.

And yeah. But before we get into that... Does that mean that this is going to be limited to just 10 minutes, like this whole conversation? This is the 15-minute stand-up? Yeah. But before we get into that, does that mean that this is going to be limited to just 10 minutes? Like this whole conversation? This is the 15 minute stand up. Yeah. I mean, there's only three of us, so I wasn't going to go for the full 15. This is going to be a short one, guys. Right. Nobody will believe it even if we said it. So, yeah. But before we jump into the details there, as we like to do, we want to thank those that have taken the time to go and leave us a review.

All right. So first up, huge thanks. iTunes got a ton. So thank you so much for hooking us up. Thank you to Dare, Asawa, Miggy BB, MHDave, MHDave. This is off to a great start. Here we go. Dave Hadley, Grandmaster Jr., C. Smith 49, A. Fi, and For the Horde and Tacos. Thank you very much for that.

All right. And from Audible, we have Joshua and Alex. So thank you very much for that all right and from audible we have joshua and alex so thank you both yep and the one little bit of news news we have is we got a tweet from i don't remember who it was but basically saying hey why can't i find the designing data intensive applications on your resource page and i usually keep that page, you know, up to date within a couple of years. So, you know, so I,

I guess that call out on Twitter will force my hand and I will go try and add more resources. Cause I mean, there's several books that we've covered and other things. So I'll, I'll try and get that thing updated so that people can go quickly find some, some resources. Yeah. I also said i would update it and then probably did not update it get that on there yeah our sla is what like two years plus

or minus two so i mean we're good sounds about right if someone doesn't have the same uh peer pressure that the other one does. Right. Yeah, apparently. All right. So before we jump into the meat of the thing here, right, I think it's worth giving a little bit of background on our experiences with attempts at Scrum. Is this the what we did yesterday portion of the stand-up? I think this is, yeah. This probably will take more than 15 minutes. but we're doing it wrong yeah i mean this is awkward right like he's frozen for you too correct yeah it looks pretty funny too

he looks like he looks like will Willy when I'm throwing him a treat and he's just about to get it. Alright, so this is going to be take two. We're going to try to get this again. We're talking about Scrum. I think all the squirrels are holding the string really tight so that Alan's internet connection will maintain

some ones and zeros and occasionally we're going to get a two or three in his internet connection because it's upgraded. Apparently some ones and zeros and occasionally we're going to get a two or three in his internet connection. Cause it's upgraded. It apparently when storms come through, tornadoes come through and wipe out the Southeast, it, you know, it apparently actually made a,

it had some problems. Yeah. Well, yeah. Cause the squirrels go and hide. So they can't like hold the, do you ever play the telephone game with the cans and the string? You know what I'm talking about? Oh yeah. Yeah. If you hold it tight enough, then it can't hold the... Do you ever play the telephone game with the cans and the string? You know what I'm talking about?

Oh, yeah. Yeah. Oh, my gosh, man. If you can't hold it tight enough, then it didn't go across. Right. And that's how I imagine your internet. I think the 50s just dialed you on the rotary phone. Yeah.

When you talked to the operator, did you say, like, please connect me to the internet? Well, I didn't hear any of those sounds pretty good i've upgraded a little yeah yes yeah all right so millennials are probably like what was that sound supposed to be boomer i gotta imagine my kids hearing that and be like wait what i don't get it man so many good childhood memories from that but all right so i guess into the meat of this thing what we said at the top that we're going to be talking about agile but i wanted to at least just throw in our thoughts on it initially before we even get into what it is and all that kind of stuff because the three of us have had experiences in the past with attempting to do scrum in the

agile processes and i'm just curious what you guys would think about our past experiences uh so for me i would say that uh i've definitely heard about it you know i'm kind of was working through the whole time when agile started up so i've definitely heard about it. I was working through the whole time when Agile started up. So I've definitely been around it and I've heard all the terms. I'm used to it and have worked on various flavors and incarnations of it where somebody read one article or two articles, took one or two things that they liked out of it and did it. So I think that's called fragile.

So I've only done it wrong. And I've never really like, you know, head to toe kind of read through everything about it. And of course, you know, it's the term in general is kind of contentious, right? Cause there's some people that kind of want it to be stripped down and stick

straight to the fast manifesto. And there's other people that have like a lot of kind of hard and fast rules that have kind of developed around it in an industry. Like, so I don't know, maybe I'm, I would say I'm on the outside looking in, seeing the true colors and stuff. Yeah, I would probably agree with a lot of that.

Like, I think in my experience, the environments that I've been in, you know, it's like portions of it, but never fully adhered to, you know, like, oh, let's do, oh, i heard about these stand-up things let's do the stand-ups but then the stand-ups will be like you know 40 minutes long and we'll actually sit down and i'm like it's called stand-up for a reason you know but yeah i never never like fully uh adhered to completely in any environment I've been to.

So I don't know that I have like a really strong opinion one way or the other about it. Cause you know, I don't feel like I've experienced it. Yeah. I, I would also agree with both of what you said. And I'd even say that for me, my frustration always came from the fact that it always seemed to be like where it was trying to be done is people were more interested in like hammering the process down your throat than in what Agile was supposed to be, which was trying to truly adapt to

the customer needs. And so it was always a frustrating thing, right? So that brings us into this particular episode in our somewhat dirty past with attempts at this. And really, I think the important part here is what we're trying to do. We're actually trying to do it again. We're trying to do Scrum again. But this time, we're trying to buy into the key tenets, the core concepts of it. And hopefully that's what will be conveying in this episode and the next episode, because there's actually a decent amount of content we want to cover. So rather than make this a four hour episode, we're going to try and do it to where you don't go crazy.

So with that, I guess let's go ahead and jump into it. So the first thing that was interesting, well, actually, first, let me say that there was a LinkedIn learning course that I did on this, and I think it was called Scrum the Basics. And it was the perfect amount of detail, in my opinion, we'll have it in the resources we like, but it was like the excellent balance between the overview that you need and the implementation, right? Like, okay, I get the core concepts, but how does this work in real life? And so I highly recommend that. Look at the resources on here.

But one of the things that they said is, hey, why don't we even call it Scrum? Like, does anybody even know what this means? And it comes from rugby. So in rugby, after a foul, the team huddles up real quick and they try and figure out, hey, let's adjust to what we've seen so far in play and let's come up with a new plan to try and get to the next milestone further down the field. So that is where the word scrum actually comes from, which I had no clue. So that's really interesting, right? It's adapting on the fly, trying to get down the field. I didn't know that.

I didn't know that either. But I guess that means that it's clearly not, you know, here in America or else we would call it a scrum. There you go. Scrimmage. Yeah. scrim right there you go scrimmage yeah i mean honestly it's that might be why we didn't know is because it's not a game that really is played here in the u.s yeah i need some terms clarified actually so if you could describe uh rugby foul milestone and field i've never heard of any of

those oh god sports ball I've never heard of any of those. Oh, God. Sportsball. Yeah, we'll send you some links. All right. So I think here's the big thing, right? Like, why is Scrum such a big deal? I mean, we've all worked with waterfall processes. I'm sure you guys remember those back in the day, right?

Where they'd have a team planning a project for a year. And that year of planning would spit out a project plan that was supposed to be done over the next two years. And you couldn't change the requirements. The cost was fixed and everything else was set. And one of the interesting things that they pointed out in this course was waterfall works great for things that have known quantitative fits, right? If you go to build a house, you can basically guesstimate at what it'll take to build the house right next door to it on the plot, right? If it took you three months on this first one and you knew that

each piece of it was a week's worth of work, you can pretty much extrapolate that into the house that's right next door. There might be some things that come up, like maybe the grading wasn't perfect, whatever, but you can adjust that a little bit with a few days here and there. Software development is more of an exploratory type thing, which she called out. And that makes a lot of sense, right? Like how many times have you gone to use an API that didn't work the way

that it was supposed to, or, or, or even trying to set up the Maven dependencies on something in a Java project, right? Like there's so many things that require work outside any kind of timeframe that you could have guessed. There was one of the books that we went through in the past, and I don't recall which one it was. I want to say it was maybe the DevOps Handbook, but it might not have been. But, you know, cause, cause there's always the, the analogy that we've heard for decades about when it comes to software development and like building a building or a house or whatever.

And I think it's because of like, there's like similar kind of terminology about like building something or architecting something and whatnot. And, and, you know, so they always try to make those kinds of connections. But in, in that book, they actually said that it was more like gardening, like creating software is more like gardening. So yeah, in your housing example, sure, you could like, hey, I've built 150 of these. So I know about like, you know, what it takes to do the grading, pour the concrete, build the frame of the house, and then wire it, plumb it, whatever. But with gardening, though, you're constantly reevaluating things. Oh, we're in a dry spell right now, so maybe I need to do some watering on my own. Or, oh, this soil here isn't as rich as the soil at the other, you know, house that I've been planting. So I need to, you know, apply different, you know, feed, you know, or, you know, whatever kind of chemical will be applicable to make the soil better for the, so you're constantly like reevaluating as you go right i'd forgotten about that and that's actually a really really legit

sort of analogy right putting the houses is such a known thing but so when we got into this the project manager saw that there's a flaw in this right because trying to plan out an entire game, like even, let's get back to the sports ball analogies, right? Because I know that at least two thirds of this podcast here don't have any clue about this, but like, you don't know anything about sports ball.

You enjoy it. Wow. That's crazy. Is that what the one with the ice skates? I like that one. No, Joe. It's the one where they do the flipping around and everything. They jump around all over the place.

It's really cool. It's so hard. Yeah, it's so hard. They do it to music and everything. Some of the best coaches in any sport in time, they've been dubbed the greatest coaches because they learn how to adapt during a game, right? Like whether it's after a quarter or a period or a halftime, whatever they come out,

they see what was working or wasn't working well in the previous, you know, however many minutes of play and then they adapt to it. Right. And, and basically that's where project managers are like, how are we trying to plan out a year or two year project and, and make it so rigid that people can't make changes when business is even changing faster than that. Right. And the whole part of Scrum really was, we need to get away from this, trying to plan up front for this massively long project. And that's where this came from. Well, I think it's also an answer to like you know a modern a modern problem right like waterfall waterfall worked when you know like decades ago because to get that new computer

it was a big deal so you needed to plan accordingly because you know going through the procurement process the ordering process, the installation and setup and all that, like that was a big deal. So you needed to get it right because it wasn't something that you were going to be able to like easily change on the fly. And, you know, so, so you, you know, you use that one example, but you know, there were a lot of other parts of that puzzle that were like that too. But over time, you know, we made it to where it was

like super easy to get computers, you know, like you just jump on your favorite e-commerce website and Hey, it'll be delivered to you within two days. And you know, then it got to the point where like, Hey, you don't, you have to do that. Now you can just like go onto your favorite cloud service and, you know, spin it up. And within a few minutes you have it. So like our need to do these long planning efforts became less. Right. And so I think that Scrum, you know, was, was, was filling in that, that, that new process that we no longer had to deal with, you know, those long procurement gaps, for example.

Yeah. So it was like a new solution to, you know, to the modern problems. Yeah, and I think also because there's so many more people doing this and software's changing so much quicker nowadays, it forced that need change, right? Like businesses, I mean, look at the blockbusters, they didn't change. Um, they disappeared, right? So business has to adapt to what, what's going on in the world. And if, if you're going to set up a software requirement, that's going to be three years out, you don't know how that's going to change. You know, you want to next to the funny,

the, um, I mean, I assume we're all next Netflix subscribers here. Uh, the, the, the coincidental thing about it is that,

you know, you could argue, I think you can make a very strong argument that Netflix killed blockbuster, right? Absolutely. So the comical coincidence there is that there's an episode on Netflix or a show on Netflix called The Last Blockbuster on Netflix that is about Netflix killing blockbuster. That's so sad. I miss the days of blockbuster.

Really though? No, you don't. I do. I do. I have fond memories of going up there on a Friday night and renting a video game and sitting in front of that thing the entire weekend. Okay. Cause you're only remembering the parts that you want to remember.

But let me also remind you of those times that how many times did you walk into blockbuster and you're like, Oh, I want to watch this new movie that just came out or get this new game that just came out and they're all gone because you were like 30 minutes too late. Right. Or you would get there and there would be like an hour long line to

check out. Or, oh, by the way, you forgot to rewind, so let me charge you a fee for that. Come on, man. Nobody, you lied. Nobody likes Blockbuster. Nobody has fond memories of Blockbuster.

Man, there's like this one game I wanted to play called legendary wings dude that thing was gone forever it was not a popular game i think somebody just rented it and probably stole it or moved or whatever but uh man i'll always go there and look at the box and it was just never there so sad do you ever rent the consoles from from them i think i did what yeah yeah that was like a cool way of like oh i want to do i even want to buy one of these things let me just rent it for a while and then see it and then they would give you like this giant suitcase for it yep it was ridiculous see you miss it you miss it we all miss

it but all right so there was something that is key to this whole Scrum thing and actually to probably a lot of these new ways of project managing software development. And it's called the Agile Manifesto. And I'm going to let Joe Zach take this. I think, honestly, we should read these points off because they're supposed to be the driving points of what scrum is supposed to help you deliver. Oh crap. I'm watching a playthrough right now. Legendary wings, but all right.

All right. How about I'll start it then. And then you pick up. So individuals and interactions over processes and tools. I was going to say before we go through those it might be worth pointing out some of the names uh that contributed to this thing because there's quite a few that we've talked about before uh bob martin's one of them um dave thomas uh not not the colonel dave thomas or john jeffries uh these are the people that we said kent beck um these are people

that we've talked about on the show before martin Fowler. So we've referenced a lot. So these are people that have contributed a lot to just the industry as a whole. And there's a lot more names than that that you probably remember. But those are the ones that kind of jumped up to me that we've mentioned several times. Andrew Hunt, wasn't there one of the books? Oh, Pragmatic Programmer. Yeah. Yeah.

Him and Dave Thomas for the Pragmatic Programmer, guys. Yeah. I couldn't remember. Sorry. Hey, you were Pragmatic Programmer, guys. I couldn't remember. Sorry. Hey, you were thinking Wendy's. I totally was. I was like, God, I know it's not that Dave Thomas. Which Dave Thomas is it? But, you know, Baconator. That sounds really good

right now. So, Outlaw took the first one. Joe, you want to take a couple of these here? Oh, crap. I was looking at the people Uh, hold on. I'm looking for it. So they have it in several. I'll say this second. Well, just to reiterate, the first one was interaction individuals and interactions over processes and tools.

And then the second one is working software over comprehensive documentation. Oh, I'm looking at a different list. Okay, I see. That's weird. Okay. It's in the show notes, line 58. All right. So which one did you just read out loud?

That's weird. The ones I looked up are differently phrased. I did the first two. The working software. Yeah, the first two. So customer collaboration over contract negotiation. Responding to change over following a plan. And that's it.

Yeah, I mean, that's really it. And here's the thing. The worst part about this entire thing that I think has bitten me in the past is the very first one, the individuals and interactions over processes and tools. It always felt like people were trying to flip that. They were trying to force processes and tools down your throat to get a scrum process in place. So you were focusing more on that than you were on actually creating the software and delivering value, which was always the most frustrating part to me, which is what we kind of, we kind of want to demystify here and turn it into something to where Scrum can be valuable for you and not feel like it's all about the process. So when you, when you listen to those though,

like anything that is in front of the word over is what you're trying to put the, you know, that's the syllable that you're trying to put the emphasis on, right? That's right. So, like, you know. That's right. Responding to change over following a plan. Like, it's good to have a plan, but it's more important to be able to respond to change, right? Contract negotiation, sure, that matters, but customer collaboration, you have to have the customer collaboration because, you know, you could easily just create

a contract that the customer is going to, you know, not care to sign. So what, you know, fine, create the contract, but, you know, also collaborate with the customer. That's important. I want to point out too so um the original agile manifesto had 12 points but they pretty much bought into what you said but one thing i like on here uh they actually say the second point is welcoming change requirements even late in development which is i think the the kind of the core of what was it was like that was so contrary to what was popular at the time or what how people thought about things that was like it was like, that was so contrary to what was popular at the time or what, how people thought about things. That was like, to me, like was the big sea change there.

That was like, it kind of identifies the big change from, from how things were done up to that point. Well, yeah. Cause you know, it used to be that if you wanted to create a change, then it was like, okay, well, uh, we'll evaluate what that change is and we'll get back to you with a cost, Mr. Customer. And, and, you know, if we agree on, on that, then we will make that change is and we'll get back to you with a cost, Mr. Customer. And if we agree on that, then we will make that change. Otherwise, we're going to continue going on with what we've got because that's what the

contract is. But also, I think the big one here, too, or one of the really big ones here is the working software over comprehensive documentation. Because going back to the waterfall approach prior towards you prior to this you know like alan said like you would have everything documented like hey this is the what we're going to do and some of that documentation would even like be like uml like you know you're going to have a class called this and it's going to have methods that do this kind of functionality like some of that documentation was like rather specific, right? But yet you didn't even have a working thing yet. And, and so like this kind of flipped

it on its head, like let's focus more on an MVP kind of approach. Let's have something that works first and iterate on that and get feedback on it sooner rather than later. A lot of this conversation is Scrum came first, but it really dovetails well within to the DevOps handbook. If you think about some of the

concepts that we talked about in there. Yeah, it was really scary. I would say the business at the time that were doing things the other way, because they would do things like have a list of requirements that were signed up by the CEO or signed up by the board, and the doc team was working, and the QA team had already written their test plans around it. People had budgeted their vacations,

and basically how they were going to spend their year or years on this stuff. And so to suddenly say, look, just toss all that away. Let's just go. That was really scary at the time, of stuff and so to suddenly say like look just toss all that away like just let's just go that was that was really scary at the time and uh i'm still like amazed that like somehow this one because working in large industry at the time it wasn't clear that that was going to be the case yeah i think the one thing you lose with this is one thing that you guys just pointed out with with agile and scrum in general is you can't forecast costs for the entire thing up front,

which is why I think Waterfall was so popular, right? Like if we sit down and we do the documentation, the requirements, everything, we know that we're going to need 10 developers for a year and X number of hardware costs and it's going to cost us a million bucks, right? Like something like that. You can't do that as much with Scum because the thing's changing on the fly

because you really are just trying to iterate on something. So, so I think that's the hard part of it for industry, but, but I think they probably end up getting more value out of it over time and probably waste less money in the long run, even though they can't forecast it as well. Maybe, I don't know. It's cool to be able to say to you, like if you, you blow by a milestone by a month,

you could say, Hey, we're at least a month late. And that was pretty cool for, for some kind of processes. And I think sometimes, you know, a game industry will still do things like that.

We'll, where a game will have a date years in advance. They were releasing in 2022 and, you know, Christmas time or uh you know christmas time or you know uh winter time and then uh as the day gets closer they'll bump it and be like oh now it's spring or q3 of 2023 or whatever and so you can kind of guess based on that that there's still some sort of waterfall going on and uh sometimes uh like games like uh cyberpunk was kind of famous for uh the number of bugs and problems when it released.

I'll find a link here. Jim Hummelstein, a design pattern evangelist, sent a really great link to a YouTube video talking about how Cyberpunk was probably developed with waterfall-type principles because it suffers some of the problems that we see and associate with that. I mean, you know, you take a game like the call of duty franchise, right? Like that's definitely, you know,

on a, on a cadence of like, you know, around November every year, there's going to be a new version and any version that is, uh, that, you know,

they're working on the, I think it was like a two to three year cycle that, you know, they would, uh cycle that they would spend trying to develop that particular version before it would get released. Yeah, and that's the thing. When you have a hard date, that's probably why people fall back to Waterfall because it's very much based around

providing a hard date on things. And Scrum really isn't. I remember it was a big deal. Like, I think Steve Jobs might have been before he passed. I forget when. Or it might have been shortly after he passed. Maybe that's what it was. I think it was.

That Apple made an announcement because they had previously been on a schedule like, Hey, we're going to release, you know, we were at WD, WDC and we said we were releasing this at this time. So that's what we're going to do. Uh, or, you know, uh, you know, like, Hey, we're releasing iTunes, a new version of iTunes on this specific date. And, you know, come hell or high water, like they were going to make that release date. Right. And, um, you know, there came a point where they said, you know what, we're no longer going to make that release date, right? And there came a point where they said, you know what?

We're no longer going to do that. We will release the software when it's ready to be released, but we're not going to release on a specific date just because somebody says that we need to, right? And I remember like when they made that announcement, like it was, you know, people thought it was a big deal at the time. That's cool. I mean, really, when you try and force it out like that, the bugs may cause more frustration than the software being late in the first place, right?

We've all experienced that as developers. And that was exactly what happened at the time with Apple, too, was that they were forced. They had made a date that, like, hey, we're going to release this software. I don't even remember if it was like iOS or iTunes or what, but hey, we're going to release it at this particular time. And they did, but it was not well received because of bugs and whatnot.

And they said, we will never do this again. We will, from now on, we will only release it when it's ready to be released. We will not do it because of a date. Which is the right way. I mean, being honest. Some of the core bits of Scrum are, one, having business partners and stakeholders work with the development and software

teams throughout the project. Measure success using completed software throughout the project. And what that means is you're actually trying to finish bits of it that can be tested as the project's going on. It's not, hey, we're going to deliver you this thing at that very end. It's more of the iterative approach that Outlaw mentioned a second ago. And the other one that's really interesting is allow teams to self-organize and was that this this so

i think we'll get to it here in a minute um we'll come back to it um so first scrum wants you to fail fast like we've used this terminology a lot in what we've done probably over the past year. And for us, fail fast means it doesn't mean you necessarily want to fail, but if you do, it happens quickly so that you can turn around and try and do something, right? You get fast feedback so that you can keep moving forward. So basically what they said in this course is failure is perfectly fine as long as you're learning from it, right? The problem is if you fail after a long time doing something, then it's hard to recover

from it. Whereas if you can quickly iterate on things, then you're not necessarily failing fast, you're learning fast, right? You're going through the process, you're getting what you need, and you can adapt to it and move forward quickly. This is another thing that I really liked about this particular course is they said that, hey, the Scrum framework is not supposed to be rigid. It is supposed to be, hey, here's a framework that has been created and adapted by teams over time. Not necessarily pick what you want from it, but know that everything's not locked in stone, right? I think the problem is when a lot of people try to pick up Scrum,

they do what Jay-Z said, and that's, oh, well, I like this bit over here, and I like this bit, and I'm just going to do what I want with these two pieces, right? You really need to try and buy into the entire idea, but just know that you're not locked in, right? Like if a two week sprint doesn't work for you, then maybe try a three week. You know, it doesn't have to be something that's super set in stone. One thing though, one, like, I guess, clarification for myself is like the measure of success using completed software. Like it doesn't have to be, we say completed software, but could it also just be infrastructure? Like if you, if you're setting up a pipeline to, you know, automatically deploy out, you know, to say a

Kubernetes cluster or whatever, or build a Kubernetes cluster on the fly or whatever, like, you know, that could be part, that could be a part of a success, right? It doesn't have to be like, oh, hey, here's a UI and I can click this widget and it performs this action. Like, that's great. But I made that call out because like, you have to get to that, to the ability to do that UI. And it's all about how do you define done? Going back to our DevOps handbook, right? The definition of done. And if done means deploying to a production-like environment, which according to the DevOps handbook it does,

then how are you going to get to that deployment if you haven't gone through the process first to set up that pipeline? Absolutely. And what you're talking about are functional versus non-functional types of goals, right? Like your DevOps pipeline is not a functional thing. It doesn't do anything inside your software, but it's what allows you to deliver that software. So yeah, you need to have all these things taken into account when you're doing these frameworks here. So here is a general, general breakdown of what the entire Scrum

framework is supposed to be about. You have a product owner who has a prioritized backlog of work for the team to do. Every sprint, the team looks at the backlog and they decide what they can accomplish during that sprint. Usually your sprints are two to three weeks. Some teams like to go four weeks. There are some teams that like to do two weeks or one week. I think probably two is probably the best,

but it'll be different for every team. The team develops and tests their solution until completed. This needs to happen all within a sprint, the entire thing, right? Soup to nuts. They then demonstrate that finished product. This could be anything. To Outlaw's point, it could be, hey, we set up the DevOps pipeline so that we can now deliver the software. You demonstrate that.

You show, hey, we made a change. It went into the build pipeline. It's deployed. Or it could be, hey, we made a change to the UI. Go demo it to the product owners, right? This should be done at the end of the sprint. And then the team has a retrospective to see how the sprint went and what worked and what they can improve going forward. So that's really, in a nutshell, what Scrum is supposed to be, right? And then, obviously, the devil's in the details. I think part of it is that having – sorry. No, go ahead, Drew. I was going to say, I was wondering if having a longer sprint period

is kind of a sign of an anti-pattern. Because it kind of seems like in a perfect world, you'd almost be doing this every hour hour everyone would run out do something useful come back demo it talk about what went wrong move on it seems like the faster you could have your sprints the kind of the healthier you are so if that's the case maybe you know then maybe the longer you're doing it the more likely you are to kind of start drifting into a waterfall territory? I think, I think yes, it's, it's a fine line. So here's the deal, right? With Scrum and with any kind of project planning type thing, there's definitely meetings that are set up, right? So you've got a lot of things you have to do, like to make scrum work,

you're meeting pretty frequently as sprints, as new sprints are coming on, you have meetings to groom that backlog, to story point things, to assign things. So there's overhead, right? So the more sprints you have, like let's say you make it a weekly thing, then you're dedicating probably a day a week of your sprint to trying to set up what's going to go into that sprint. So you could lose an entire day there just trying to make sure all that's good. If you go to a month, then you're kind of finding what agile is all about, which is responding to what the customer wants, the needs and all that kind of stuff. So yes, absolutely. But I think there's a fine line, right? That's why I think probably two to three weeks is the right balance. Two probably allows you to pivot quicker. And three is probably the edge of how long you actually

want that to go. Because yes, if you're practicing the true, you know, desire, what scrum wants it to be, once you've locked into stuff or a sprint, you're not supposed to change it. Right. Which means that anything pressing that comes in, you're waiting. If you're at the beginning of this sprint, you're waiting three weeks before you can get to that next thing. So yeah, it's a,

it's a balancing thing, right? Like it's, it's definitely not easy. Okay. I wonder how that fits in though. Cause like, uh, I remember years ago there was a, an article about Facebook's development cycle or process and how like they would have developers push out, uh, changes, you know, like you get a ticket, whatever that ticket is, like a new feature or bug fix or whatever. And you know, you're developed, develop, develop, and then, Hey, I'm, I'm done committed passes test. It automatically gets pushed out and you can verify that it went out to production and you could do all that within a day.

And you might work on several of those tickets within a day. And so you've done several production deployments all within a day. Like to me, the ability to have such a fast feedback cycle sounds amazing and awesome and kind of consistent with what Joe was saying that, you know, if you're the shorter that window is then you know the better you are responding right and i think google had a similar i think we've discussed google having a similar kind of setup too if i recall um as part of our devops handbook conversation it was thinking like if you were shipping every day it kind of implies if you're doing things like totally you know by the book agile then it doesn't really give them enough time for like the business owners and you know to do the demo and people

basically agree that something's done so i don't know just kind of interesting to see that there's a it's almost you know it's almost like there's people going faster than agile which is maybe dangerous maybe awesome i don't know it sounds awesome. It might depend on the... Go ahead. No, go ahead. I was going to say, it might depend on the type of software, too. Because if you think about Facebook, they're not building something that a customer wants. They're building things that they want you to use. Well, I mean, they would hope that it's what their users want.

Right, right. But it's what their users want. Right, right. But it's not, I guess the difference is if you are building something for a hospital, right? Like they have needs. They have things that they need to be in there. You need to be able to choose the medications. You need to be able to do this. You need to be able to do that. Facebook's throwing features out there that they want you to adopt.

And so it behooves them to get that stuff out as fast as possible and see who's adopting it and who's not. Whereas if you're writing something for the medical field, you've got to abide by HIPAA compliance and all kinds of other stuff. So I think it probably depends on the software that you're writing, right? Like if it's just something you can iterate on and create features willy nilly and just see what people like and what they don't, then awesome. But if it's something that actually needs to meet a certain requirement,

then I think, I think maybe the daily thing doesn't work as well. Yeah, that makes sense. It's definitely an interesting thing. Like, you know, if you're working on like software that's going to be part of a physical piece of hardware, you know, like, like, uh, you know, um, okay. What are those machines like a CAT scan machine or MRI machine? You know, like if you're creating the software that's part of the operating system for that thing, then, okay. Yeah, sure. It probably doesn't make sense to do daily deployment. So you're right. I was definitely thinking of like

dot com type, uh, world when I definitely thinking of like dot-com type world when I was thinking of like fast deployments or even like it could, you know, well, I was going to say like iOS app development, but Apple really doesn't like it when you do that. They want it a little bit more structured. But I think where I struggle with parts of this though is that with that backlog of, that backlog of, of that prioritized backlog of

stories and specifically where I have some struggle with that is that those stories aren't necessarily my understanding and correct me if I'm wrong. Those stories aren't necessarily like fully thought out or, you know, like they're, I guess the one I'm trying to say is that like, it could be the general theme of like, Hey, I want to be able to add something to the cart and check out. Right. But it doesn't go into any kind of details as to like what's required for that. Like that's on you, the team to sort out the individual tasks, right. And, and apply, apply that to the story. So like you might have the story and you think like, Oh, I think it's roughly about this amount of effort. And you know, I want to be able to add things to the cart and check out.

And I think that's roughly a two week effort. I don't know. I could be totally wrong, but I'm going to say it's a two week effort. And then the team is like, yeah, sure. We'll take that. We'll take that story. And then they're like, okay, what is it going to take? What are the tasks that are required to implement this story? And then let's add the tasks and let's estimate all of those tasks. And is this still within the two week timeframe that we originally thought we're really don't even use two weeks, but we're, I guess I'm getting ahead of myself there. But at any rate, the point is, is like that's where that's where I struggle with some of this process, though. See, and now you're jumping into part two of what is going to be because. Oh, that's fine, though, because that's actually where I think a lot of people struggle, including myself in the past. But we kind of drew a line on this episode right before we get into the stories, because

what you just hit on is probably the most important part. And we will cover all of that in the next episode and talking about stories and prioritization and story pointing and task association and all that kind of stuff. So we're basically just going to hit the overview and the main selling points of Scrum in this one, and then we'll jump into the details next go. All right, so I guess then let's talk about some of the things that every project has. And probably most people that work on software

don't even think about this, right? Because as a developer, we're thinking about what we're trying to create. We're not thinking about the things that the project management team or upper management is thinking about, which is the time, the cost, and the scope, right? Like in the waterfall process, all three of those things were fixed, right? It's going to take two years. It's going to cost $2 million. And we have the requirements that need to be hammered out for this. What happened is, is Scrum turned that on its head and it said, hey, you can keep two of them fixed, which is kind of funny because the time and the cost they say are still fixed, but the

scope is what changes. But if you follow what they're trying to do here, the point of Scrum is different from Waterfall. Like Waterfall, like anytime anybody built something or planned out a project, the whole idea was we're going to have every nitty gritty detail in those requirements docs, right? In Scrum, Outlaw hit on this earlier. The idea is to get an MVP out there. And the reason you want to get the MVP out there, which for those that have never heard of this, is the minimum viable product. The reason you want to get that thing out there is you can get feedback. So you don't waste time building stuff that the end user doesn't want or need, right? Like you might've thought something was super important

and they see it and they're like, yeah, it didn't really add much value. Okay, well, all you did was spend two or three weeks on it instead of two or three months, right? So that's the whole point of that. But let's talk about some of the roles that are on these scrum teams. One is your project owner.

That's the business representative that is 100% dedicated to the team, the scrum team. They act as the full-time business representative. That means that they're talking with the product owners and anybody in the business to make sure that they're getting the requirements and that they're writing good user stories. They also review the team's work constantly. So in theory, they should be involved in everything that the team is doing all the time. So they're making sure that what's being delivered

is what the vision was. They interact with the stakeholders. They're the keeper of the product vision. We'll talk about that in a little while. And they are the ones that are responsible for constantly going through and prioritizing the business needs, right? Based off their conversations with the stakeholders. I mean, what isn't said here, they're like the in-between, like the developer and the customer, right? That they, they, that's why they are the business.

That's why they know what the business needs are because they are doing that communication. They're basically a people person. Right. I take the requirements from the customer and I give them to the developer. Right. And, and by the way, stakeholder and customer are basically interchangeable here, right? Your stakeholder is the person that you're delivering the software to. And that's, yeah, that's totally what their job is, is to make sure that you're building what they want and need. in here and I've heard some people want to change the name of this. The standard way of calling this was a scrum master. And from what I understand, just due to sensitivity issues, the whole term master here means that they've mastered the skills. It doesn't mean that they're, you know,

driving people to do things different ways. And really, when you find out about their role, they are sort of the spokesperson and the person for the team that is trying to look out for the team's best interest. So their primary thing is to make sure that they're trying to help resolve daily issues. And they are also the ones that are trying to make sure that they're balancing out the requirements that are there and making sure that the team can actually fill those requirements, right? Like if the product or the project owner comes to you and says, hey, we need these five additional features, then the Scrum Master is going to be like, hey, we're already at capacity, right?

If you need this stuff, then there's going to be other things that suffer because the whole idea is you're not supposed to make a team work 80 hours each to get something done, right? It's actually supposed to protect from that. Yeah, I mean, that means they're leaving like another 40 hours on the table. So yeah, 120 is the goal.

Oh man, that's terrible. But the scroll master on top of those two things, they're also supposed to help improve the internal team processes. They're responsible for protecting the team and their processes, which means that they're balancing the demands of the product owner, which I just said. And they're also keeping the team working at a sustainable rate, right? There is a quote that was used that says Scrum doesn't value heroics by teams or team members, meaning that they don't want your team working each 80 hours a week or one person working 80 hours a week to get something done. If you've done that, then you probably over crammed your sprint with things to do is what,

yeah, you overcommitted your team. And that's not something that's going to be easy on day one because you don't know what the velocity of your team's going to be, right? It's something that you'll learn over time with the team as you find out what the velocity of that team is. But those kinds of heroes can totally throw off your,

your velocity. So that's why, that's why scrum doesn't value it because it wants, it wants everybody to work at a sustainable rate. And if you have, if you burden your team to where you are working, you know, triple digit hours per week,

uh, a, it's not sustainable, but it's going to totally make your velocity look like, Oh, Hey, this team can do look how much this team can do in a given sprint when, you know, yeah, they pulled it off the one time, but you should play exactly every time they completed 80 story points, but the next sprint, they were only able to get 30.

Why are they slacking off? Right? And half of the team quit. Right, right. Exactly. So it's a problem. Like really, you want people working at a good clip, right? You don't want them to be slacking off and you don't want them to be working into the wee hours of the morning. It should be a legit good work week. The other roles of the Scrum Leader, Scrum Master is they're supposed to act as a spokesperson for the entire team, right? Like if that team needs something, they're the ones that kind of go push that up. Another one is they're also responsible for providing charts and views into the progress of the team over that sprint, which is interesting, right? Like you're trying to make that transparent. And then the other thing here, and this is an interesting one, because this came up on the call the other day, is they're also responsible for removing any blockers. And the way when you hear that is, OK, well, they're just being tasked with trying to get rid of a blocker. Right. Like if Outlaw comes to me and says, hey, man, Jenkins is down, can't do anything. Well, that doesn't mean the outlaw is going to quit doing anything to try and help resolve it, right?

Like he's not going to wait until the next stand up to tell his run master that, hey, I need you to go take care of this because Jenkins is down. It doesn't mean you stop trying to do anything. Your team should constantly be in communication and trying to resolve problems. You bring these things up the next day. If you say, Hey, you know, me, Outlaw and Jay-Z, we all worked on this all day. We couldn't get anything going forward. We may not even have the right contacts. I don't know. Could you reach out and see if you can do something about it? That's what it's supposed to be. It doesn't mean that you stop trying to do things. It just means that they are the next line of defense. If you aren't to resolve something, usually within a day.

It also feels like, though, this person isn't actually one of the devs on the team. Because it seems like a lot to manage within a given sprint. I would hope not. You would hope it's not a lot or that you would hope that they're not coding? I would hope that they're not being tasked out with a ton. Assuming that things are kind of moving along, they could totally be developing. If things are falling apart, then yeah, they might be chasing their tails, trying to figure out how to get things resolved.

But I mean, if we think about our day-to-day, really the two things on here that they would probably spend additional time doing, assuming there were no blockers, would be providing the charts or the view, which a lot of tools do that now, right? Like if the scrum master is telling your team, hey, make sure you're keeping these stories up to date, right? Like make sure if it's in progress that it's actually in the in-progress swim lane or whatever, so that the tools like Atlassian or whatever can show you, hey, this is where our team is right now. So I think that in general, as long as the team is operating well and communicating and keeping things where they should be, then they shouldn't be overburdened with things. I guess there was just some of this that I interpreted as like, oh, that sounds like

another way of saying meeting. And meetings are just annoying. They take up time. I mean, they have a purpose. I'm not saying that they don't. I'm not trying to say they don't. But, oh, gosh. I mean, you know, it's hard to like be in a lot of meetings and get a lot of

deving done because, you know, you see like words like responsible for protecting the team and their processes. Well, that means that, hey, if there's any kind of communication that you want to go through the team, it should go through the scrum leader first, and then that person would disseminate the information or vice versa, right? And there was another one here, like access the spokesperson for the entire team. Well, that to me translates to like, okay, anytime there's like, you know, a need to communicate to others outside of the team, like you're going to be the, that, that person is the one in the meeting going to some other meeting to be like, yeah, and this is what

my team is doing. Right. So that's where I'm saying, not's fair. Not to mention like the charts, you know, providing those charts and everything for transparency. And why do you need to have those charts? Because you're later going to be in a meeting where you're going to present that stuff.

Right. So, yeah, I mean, in fairness, I think the, the spokesperson for the team is basically if in your daily standup, you find out that,

I don't know, you need a piece of software, right? Like maybe that person's going to go, Hey, boss, we need a piece of software, right? Like it's not necessarily that they have to be the entry point to and from your team, but they are definitely trying to help the team achieve its goals, right? So I think that's the big distinction there is I don't think they're supposed to be a barrier to anything. They're just really supposed to be the advocate for the team is really what it boils down to. And that kind of leads to sort of the final point that they had on this is the project

owner focuses on what needs to be done. The scrum master focuses on how the team gets it done. So one of the things that wasn't in these bullet points that I thought was interesting is it's sort of the Scrum Master's job to hold your team accountable. So in your... And that means in your daily standup. So in your daily standup, you have these 15-minute things, right? Like, Hey, Alan, what'd you work on yesterday? Uh, I worked on ticket ABC. What are you working on today? Ticket ABC. If tomorrow I'm saying the same thing, they might say, Hey, that was supposed to be a four hour task. Why are you still working on that? Hey, uh,

Hey, Jay-Z, can you help out? Can you help Alan today? Try and get past this? Right. So they're kind of holding people to this whole notion that you have to be moving forward. And if you're stalling on something and it may not even be because it's anything you're doing wrong, you might've been pulled into five production support things. But the goal is, is to make sure that you're moving that sprint forward. So.

As I say, the support story is always where I struggle because support is, you know, production's on fire. That's one way of doing it. And that's, you know, something that stinks and you want to get rid of that, right? That's a problem. But there's also the notion of support, just like you mentioned, where it's like,

hey, you know, somebody's having a problem with their ticket. Can you kind of jump in if you're like in a lead type position? And that kind of stuff happens to you all the time. It may not even be your team you know maybe like hey someone else's team you did something similar can you jump over there and help them out for six hours over the next week that's just important but stuff really helps the the greater team and you know i think is good stuff but it's really hard to budget for and so it may be that you're you know you've got an eight hour ticket that takes you three days because you have other meetings for other stuff or you're helping other teams or you've got production issues or you've got all three.

And that's something always that kind of frustrated me with estimates and doing stuff because I'm just kind of like, I can't help. If someone tells me something's broken, my mind jumps there instantly. I like to be able to hop on stuff. That's very motivating for me, but it doesn't seem to jive very well with like strict agile. Well, I mean, you tell me if, if, uh, we're going to get to this, you know, at some point and, and I'll, I'll leave it be, but cause I'm in a similar, a similar boat. Cause part of the problem that I have is I think that you're supposed to like when you're when you're planning your your sprint uh and and you know based off those story points that alan mentioned earlier you're supposed

to leave like a portion available for things like bug fix or production problems or like ad hoc kind of stuff so like you know if whatever your team velocity is i think alan in his example mentioned like 80 story points you know if that's what your team does you wouldn't say like okay let's fill up all 80 with these stories and instead you might say like hey let's do 40 points of stories because another 40 might be reserved for things that are going to come up i think is the way we're supposed to do it should average out right um but it just it always uh i don't know it seemed seemed kind of rough to me but it does make sense that you know like yeah maybe the first couple sprints stink but uh measuring velocity that's the whole point is to be able to kind of account for that and kind

of smooth those lines out and so maybe some weeks you're able to grab some more stuff maybe some weeks you know don't go as well but over time it should average out to be pretty close. I kind of view this as like a production line, like, like, like literally an assembly line. Right. And sure. You might be able to like crank that thing up to 11.

Right. And, and the team could work on it for a short period of time. But then, you know, as soon as somebody has to like take a bathroom break or something like that, then it's like,

Oh, well, if everything fell apart, right. Because somebody had to step away for some reason. Right. And so you need to slow that line back down to where it's at a sustainable rate that, that works well for the company and, you know, profit wise or whatever, you know, productivity wise, but also is realistic with things that are going to happen to like you know hey we need to account for lunch

breaks and we need to account for like you know uh you know bio breaks and things like that right like i don't know yeah i think i think to you guys's points though like when it comes to things like support issues or just in general helping other teams out right like if you're one of those people in those roles then i think that you do set up stories so that they're part of the sprint, right? Like you don't just want this big hole in the sprint saying that there's not things happening, but if you can allocate that, then I think it helps.

And again, I think that's something that you find out over time, right? If all of a sudden, you know, Jay-Z was pulled away for three days on something, then maybe we know that we need to create a story for, you know, Jay-Z being involved in whatever it is. So it's I think it's one of those things, Bobby, who was real big on this Scrum thing and trying to lead the charge and getting things set up. He even brought up a really good point, right? Like we've all been in situations where it felt like every week you were spending half that week on firefighting, right? And what Scrum allows you to do is also take a step back and look at that

and say, why are we fighting fires 50% of our time, right? Maybe next sprint, we need to dedicate the entire sprint to technical debt or fixing these issues that you're spending half of your time on, right? So it's a good way to help identify a problem because if you're just in the world of managing tasks, it's easy to get lost in the fact that you're just fighting fire one, two, three, four, five, and not looking at the overarching problem as a whole. You know what I mean? So it could be a really good opportunity to just really take some hindsight and try and make things better going forward. I like that.

Yeah. It's like there's two fish in a tank. One says to the other, I'll drive, you fire. Different kind of tank. Terrible. Come on. It wasn't

terrible. Sorry, Mike RG. I didn't do you justice there. Terrible. Terrible. Barclay says

it's terrible. It's terrible. Today's show is sponsored by Datadog, the monitoring and security platform for visibility into modern and maybe even old applications. Security threats in cloud-native environments move fast, which means that security teams need to have the same visibility into their infrastructure, network, and applications as developers and operations

yeah and this is the beauty of like everything that we've learned about like the devops handbook right you know about like observability so datadog has long uh had this concept of the three pillars of observability metrics traces logs all in one one platform and if you've never seen datadog you really need to go check it out. You can go to datadoghq.com slash coding box and see just some great visualizations that come out of the box. But with that, though, we talked about this in the last episode, too. Security, I guess maybe they need to change it to the four pillars of observability. But Datadog includes real time threat detection with out of the box detection rules. And, you know, there's a lot of cool stuff there that you could see.

Like, you know, we talked about the the the maps that you could see, like the traffic flowing from like where, you know, geographic maps, like where traffic was coming from. And maybe that matters for your particular application, right? But, you know, there's analytics and collaboration. It's really a great platform. And if you haven't checked it out, you really need to, um, again, because in this world, everything that we've learned about DevOps is that if you don't have observability in your application, you can't call it done. So, again, datadoghq.com slash codingbox, you can find some great examples there of what those visualizations look like. But I highly recommend you check it out. Use out-of-the-box OOTB detection rules and detailed observability data in one unified platform to investigate security attacks.

With Datadog security monitoring, engineering teams can easily detect malicious activity in real time before it affects their customers. You can see it in action by signing up for a live security demo and receive a Datadog t-shirt by visiting datadoghq.com slash codingblocks. Again, get your t-shirt at datadoghq.com slash codingblocks. Again, get your T-shirt at datadoghq.com slash codingblocks today. All right. So if you've enjoyed these terrible jokes that I failed to get across correctly, then you can leave us a review. You can find some helpful links at www.codingblocks.net slash review. And we do

greatly appreciate all the feedback that we get from the listeners. It really has meant a lot to us over the years and is really a, I would say it's like a driving force, like a motivation to continue on to like it really does brighten our day. you know, brighten our day. So, uh, yeah, we would appreciate it if you haven't already, if you would. And with that, we head into my favorite portion of the show. Survey says, all right. Uh, don't make fun of the way I move my head when I say that Jay-Z, I saw that you gotta like get into it. move my head when I say that, Jay-Z. I saw that. You got to get into it when you say it. You can't just scream it into the microphone. You just got to have that Doppler effect.

Yeah, that's true. All right. So a few episodes back, we asked, and I don't think, maybe this one was just Jay-Z and I, I think, because we didn't do a survey for that episode. It was just, you know, we only asked one. We didn't answer one. So the survey was which company has the best open source projects? And we limited it to three answers.

And your choices are Facebook, Google, or Microsoft. So this is what episode? 155? So according to the Tatuko rules of engagement, it would be Alan's turn to go first. So what do you think your answer is in percent? This one's hard because I'm really impressed with what Microsoft's done. I mean,.NET Core is open source, right?

Like that's a, or.NET One or whatever they're calling it now. Like that's amazing. Oh, they'll change the name tomorrow. Man. It'd be.NET Framework Core. But man, Facebook. For Windows, for professional. And then, you know.

Right..NET Core 2021 for professional and then you know right dot net core 2021 for professional office uh 365 i mean let's not even talk about the confusing name of microsoft uh xbox one x and one series x and whatever man um at any rate well i mean you know you gotta love it it was like there's the Xbox the Xbox 360 and then the Xbox One wait what shouldn't one have come first they're not necessarily the best at naming but I gotta say

though Facebook has really killed it with some stuff GraphQL PrestoDB I mean so I'm gonna go Facebook and this is just from personal admiring of some of their projects. I'm going to say Facebook and we'll go 50%. You didn't even say React. You didn't even say React.

And wasn't like Cassandra. Yeah, man. Wasn't that a Facebook thing? What was, or no, what was the, it wasn't Cassandra.

It was like a search for the M. That's what I just said. Rocks DB. No, I thought there was another one though. Okay. Well, cause all right.

So Facebook 50% and, uh, the math of a chicken. Mm. Hmm. Uh, the correct answer is actually Google. Uh, Microsoft. All right, so Facebook, 50%, and the math of a chicken. Mm-hmm. The correct answer is actually Google. Microsoft, great things, and they've definitely got the PR machine out about it, but man, Google's got some stuff.

Yeah, right? I mean, Kubernetes. How about Kubernetes? Oh. All the container tools. I mean, yeah. Everything that even exists in the Kubernetes world. Scaffold, for example. Yep.

That's pretty big. Yeah. Angular, of course, on the front end. Dart, Flutter. I mean, there's just a lot. Like, you can bring a bunch of names, any domain, and they're in there. Yeah. So both of you are at 50% each,

but Alan says Facebook and Joe says Google. Do I have that right? Mm-hmm. Okay. Yeah. Well, you're both wrong. No. Yeah.

So it was 52% from Microsoft. All right. go Microsoft. Wow. Yeah, I'm going to assume that that's largely just the audience, our audience being probably, I'm going to guess, more Microsoft-flavored because the.NET and our name definitely would imply a lot of Microsoft, I would assume. So I'm going to assume that that's why,

cause I would have, I would have picked one of the others, like not to Microsoft hasn't done a lot of great stuff. I'm not saying that cause they have a huge amount of stuff available on GitHub, but I would have, I would have been torn to pick one of the other two. I would have probably picked Facebook like Alan did,

honestly. Wow. Just because Microsoft, um, I think would have been my number two uh but the pr machine is out and so i think that they like microsoft is constantly reminding you like how big of open source uh contributor they are which is you know it's fine it's great and you know i like that but i also think that like google doesn't promote it as much, but dang, they got some stuff. Yeah, they do. Yeah. Yeah.

I mean, all three, right? Like seriously, what, what these three companies have done for the open source world has been nothing short of amazing. And that's why we limited it to these three.

Cause like, you know, they are three big players that matter right now in that space. So it was kind of curious to see like, you know, which, which people people which one people tended to uh you know like the best between the three but yeah tough it the other well that's what i was about to say it went microsoft google and facebook so yeah and and it wasn't really close either. It was like 35% for Google. So, you know, I mean, there was a, there was a steady drop off there from one to the next, you know,

they were heard a chromium. Yeah. Right. Right. Yep. Yeah. A little bit by chromium though. Oh yeah. Enjoy. Yeah. Yeah. Yeah. It's still the, I mean, yeah. Android, yeah. Yeah. Yeah, it's still there. I mean, yeah, the fact that all this stuff is out there for us to use and learn from is just killer. Node, I mean, that's just the Chrome V8 JavaScript engine. Is it? I thought that was the origin of Node, was the Chrome V8 JavaScript engine.

Am I wrong? I thought it was the guy. I would say let's go Google it, but that seems like we would be breaking the open source rules here. I guess we'll Bing it. Yeah, we Bing it. I don't know that we're going to be able to trust that result, though. I guess that would be a Microsoft thing, too.

So maybe we DuckDuckGo it? We Duck it? I'm still looking it up so i i know that so there's a guy ryan doll who i was thinking of i just i'm not sure it's relationship to the v8 though but i don't yeah like you said i don't think he went and re yeah it runs on the v8 engine so yeah thanks google yeah and and for some reason like uh the ducks made me think of like you know a dinosaur's favorite file format do of like, you know, a dinosaur's favorite file format. Do you know, do you know what a dinosaur's favorite file format is? Uh, rawr. Yeah.

I got one. I got one. Yeah. He got one. He got one. Thank you, James. I was sent to us from James. Yeah. Um, yeah, That's awesome. Yeah. Yeah. It's interesting. And, you know, just in general, like, too, though, as we're going through our Scrum and Waterfall conversation, it really makes me think, too, like, you know, some of that depends on, like, where you are career wise, you know, like, like, which is, I guess another way of saying like what generation you are, you know, because if you, if you are older than you probably did a lot of waterfall stuff. So you have those bad memories of it versus if you are newer and younger in your career, you know, then you've only ever known things like agile and scrum. But then, uh, it made me think like, what generation is Forrest Gump a part of?

Oh, my gosh. I don't know. No? Joe's thinking. Yeah, I got nothing. I don't know. Something about chocolate. No.

Jenai. Oh, my gosh. Jenai. Oh, my gosh. Oh my gosh. Thank you, Michael. All right. So for this,

for this episode survey, we ask always the ever important questions. So let's say you're in Slack and you want to reply to a conversation in Slack. Do you reply in the channel? Because I don't want to risk someone not seeing my thoughts or in a thread because I like to keep my conversations tidy, like my desk. I mean, I obviously,

I mean like what kind of monster would just reply to the channel? Oh, sorry. Am I like naming the jury poll there? Like I need, I need to know these answers here. They added that checkbox too, where you can like say reply and thread, but also add to the channel. Right. So you can like let people both.

I kind of have mixed feelings on that because it like dirties up the channel conversation. And then like if you do read the thread, you're like, OK, read it, read it, read it read it read it and then you go back to the channel and you're like oh here let me read that oh wait I already read that so I don't know yeah your point well yeah sorry sorry not sorry whatever wow there's still So sorry, not sorry. All right. So yeah, whatever. Wow. There's still a little bit more. All right. We're going to try and we're,

we always say we're going to try and blow through the second half. It never happens, but in an attempt to go through the second half, we're going to, um, all right. So here's, here's one of the big things, right? Scrum is all about daily collaboration. Um, whatever you can do to make this easier will be good for the team. They had some suggestions, which in the pandemic world that we've been living in is probably not the way it would happen. They say, co-locate your team if possible, right? That seems to be the inverse of what everybody's done here in the past year.

If you can't do that, though, there's lots of good options. Video conferencing, chat, conference phones. We've mentioned on this show several times, like when we do meetings, cameras on, right? Unless there's some extenuating circumstances, camera on. Make it personable. I mean, you could still consider co-locating your team, though, to include things like accounting for time zones, right? You wouldn't want somebody, like if you have an East Coast team,

Eastern time zone here in the United States, but yet you have one member who's in, say, India or China, like it's going to be a real, uh, you know, challenge for them every time there's a meeting, depending on time of day, right. For them to, to, uh, you know, one attend that meeting and also to not be tired and be able to pay attention or vice versa if you try to attend there. So I think you could still say you could modify what co-locate your team means to account for our new virtual world. That's a really good point. I like that.

Interestingly enough, I didn't put it in the notes, but one of the things that they called out in that course was one of the things you can do if you do have a team that is distributed crazy regionally around the world is instead of trying to make somebody in India join your stand up on the East Coast, you can actually have them record their stand up. And then that gets played during your stand up on the east coast you can actually have them record their stand up and then that gets played during your stand up right so there are ways around it where you're not trying to force people to be online at unnatural hours oh man but watching watching videos in the meeting just makes me like want to die i'm sorry yeah no i would not i would not i would i would might i would strongly advocate to put that person on a team that makes sense for their time zone then. Unless they just wanted to work.

If they wanted to shift their working hours to match up with the team. Because otherwise, that just seems painful for all parties involved. I like flexibility a lot, too. There's a lot of times like it feels like the it's easier to get work done when nobody else is around you know so i i don't think that always you know be whatever the opposite of collegiate is but i think it's nice to have some overlap and some not overlap yeah well that's all i'm saying like you can't i'm not saying i'm not taking it to an extreme and saying like hey, everybody in your team has to be in an Eastern time zone. And if somebody's in a Central time zone, then they need to be in a different team. I'm not saying that. You could have some flexibility there, right? Because I do agree. But again, going back to this, this doesn't work if there's not that daily collaboration's not that, that daily collaboration, which is just

another way of saying communication, right? If you can't communicate regularly with one another, then it's not going to work. And while email is fine, you know, we've talked about forms of communication before in the past, like there's, there's a big difference between like you write me a message and the way I might interpret that versus the way I might interpret that. If I actually hear you say it and see your facial expressions as you're saying it, right? Like those, all those nonverbal cues, they, they matter. They're important. Yep. Totally. So, so no sharing of videos during video calls got it oh all right so here's one

thing i don't think we were trying to say that you couldn't but yeah it just sounded like to submit a hair i've pre-recorded my stand-up just sounds awful because then like take it to an extreme right like okay fine it's not even a time zone issue i just don't want to attend the meeting Stand-up just sounds awful because then like take it to an extreme, right? Like, okay, fine. It's not even a time zone issue. I just don't want to attend the meeting. So I've prerecorded my stand-up. Here's my two-minute video. You could play it.

And then everybody else is like, well, that's a great idea. I'm going to do the same thing. So then you have everybody submitting their two-minute stand-up communication to the scrum leader, and only the scrum leader watches it and communicate like, like, because again, in that, in that video there, it's one way collaboration,

right? There's only one way of communication, one direction of communication. So, you know, you as the video creator, you're not getting any feedback from what's being said there. So it's not,

is it really stand up? Is it really scrum at that point? Like, no, I don't think so. Well, you're not supposed to get feedback during the meeting. Anyway,

you got two minutes, you know, boom, boom, boom. It's really supposed to be fast. We haven't hit on that yet, but we will for sure.

So yeah, let's talk about the team makeup. If everyone does it, you can actually watch all the videos at once and be done in two minutes like that sounds cool alternatively if you just email me the text then i can just not read it right that's that's really nice you could also just not watch the video exactly well you know i so i don't i don't love video anyway i maybe this is i'm not good with those non-verbal cues whatever but man i love having searchable text so just anyway i'm not good with those nonverbal cues, whatever. But, man, I love having searchable text. So just anyway, I'm not anti-scrum.

You know, I am anti-waterfall, if you can help it. But just kind of like to point that out that I don't like video. We're going to convert them. That's fine. All right. So let's talk about the makeup of the team. So this first part is probably, what were you about to say? Yeah.

If you could email me your scrum status and this format of a podcast, that'd be great. Probably be more apt to listen to him. Yeah. All right. So the dedicated team, they make a very important part of this. If your team is not dedicated to that project for that sprint, your likelihood of success takes a major downward trend.

So if you're going to set up a scrum team, that team needs to be able to work on that work, right? That's really what it boils down to. If Jay-Z is being pulled across onto another team to do something else, he's losing efficiency because he's having to contact switch all the time, right? It's super important that you try your best to make sure these teams are sort of insulated from a ton of outward forces. The next thing they say is the ideal team size is between five and nine members. If you go over nine, communication becomes impossible. We've talked about it before on this podcast,

communication is really hard to scale. It's hard to get everybody on the same page. It's hard to keep everybody focused. If people aren't working on the same stuff, then they don't care. So seven people is probably a good size. Anywhere from five to seven is probably good. Anything outside of that, you're probably stretching a little bit, but the max should be nine. And there are research articles out there to back this up. I can prove that really quick. Think about your daily work interactions, right? How many people do you regularly go to lunch with during your day, right? It's not, you don't go with a dozen people.

You don't go with 20 people. Why? Because trying to find some place that all those people are going to agree on is impossible, right? Because you got to go to each individual person and be like, well, what are you in the mood for? Well, what are you in the mood for? Well, what are you in? And then like try to sort that out. No, just you, a handful of people at most, right? That's as most as what you have the patience to try to sort out. Right. And this is no different. It's true. You know, your, your, your, your, your work is your work part is of the day is no different than that. Like, you know, trying to sort out and communicate like how you're going to work on something

or how you're going to create something. Right. It's the same, it's the same problem. We're just changing like what the conversation's about instead of it being about food. Now it's about you know code i like that i think i think joe will like this part here you want t-shaped developers you want people that have a good breadth of knowledge but are also good at getting into the details of any particular language, right? Or technology. Or technology. This isn't necessarily a hard, fast requirement, but she did call it out in the course, right?

Like if you've got four or five people on your team that can each do front-end work, back-end work, database work, whatever, then you have people that can work on any task on the team, right? And so that's really helpful. That doesn't mean that the team shouldn't have specialized people, but having those people with a wider skill set does make it easier to accomplish tasks and those stories on the team. And then they did say, though, that there are situations where you might need somebody that's sort of like in a consulting role. Let's say that you've got a really challenging database problem, right? You've tried everything. You can't get the performance right.

You might need to call in the big guns and have somebody come in and work some magic on the database. You don't have enough tasks or stories to keep them occupied full-time on your sprint. So these people can sort of be treated as consultants that you call in for help when you need them. And they're sort of available to all teams, right? So it is important to know that you can have some external help when needed and not have to try and fill them up with tasks the entire time. I like that. Yeah, I did too. I thought that was really good. I know that for us, our teams are very much T-shaped developers with one or two

database specialists and one or two QA specialists. I like that. I like that mix. And I like the fact that most everybody can just do whatever they need to, to get things done. Now, here's one thing that's important about these teams and they call it, you need to establish what are called team norms. And this basically defines how people work together. Like not, hey, you need to call him at this time or you need to call her at this time. Not that. It's really more about how to work through the tough things. When a conflict comes up, you need to know how do you come to a consensus, right? Is it, you know, you go around your room of five or six people and you say,

do we go with solution A or solution B, right? And then everybody makes their points. Four out of the six of you said that we go with solution A. Okay. That was the choice. And one of the things in Amazon, one of their key, I don't even remember what they called them at this point, but it was agree to disagree and still move forward with the agreed upon solution, right? So that's a good team norm, right? If everybody else says, hey, this is what I think we should do, even if you're like, yeah, I don't think this is right, whatever. The team has spoken, move on.

So you kind of need to come up with some of these rules so that when conflicts arise, you have a nice, well-defined path to resolving those issues. Not a huge deal, and it doesn't have to be a problem, but if you have those ready, then it'll probably smooth things over a bit. And then the other thing that was really important here is creating these team norms isn't enough. You need to make sure everybody on your team is bought into them. So if, if this whole agree to disagree, but still move forward, if,

if people haven't bought into that, then you're going to have a lot of discontent and probably morale issues on the team. So, or you're going to have a lot of discontent and probably morale issues on the team. Or you're going to have people that are really quiet because they're like, well, I don't agree with this person. I'm just going to keep my mouth shut. Whatever.

They're going to check out of the process. Yeah. That might be a really good point. Maybe one of your key team norms is everybody has to have a voice. You're not allowed to be the person that says, I don't care. Right. You have to choose a side and give a reason why. I don't know. Like just making sure that everybody is on an even

playing surface and they're all contributing is a big deal in making sure that you have a healthy team. All right. And then, so the next piece, and this is starting to get into where things all start coming together. So we've talked about some of the overview of Scrum and what the pieces are. This is where it all starts coming together. So you're supposed to have a product vision. We're an hour into this. We're now getting to the part where, like, this is the part that matters.

Right, right. The rest of it, you know, you could have turned off. Well, it was a joke because you're like, only an hour into it? Come on. I don't know how far we are into it because my interwebs went down oh that's okay the squirrels are still holding the strings tight so we somewhat hear you they are currently yes so the product vision it's the map for your team it tells you how to get where you want to go and this has to be set up by the project owner

right they have to be the ones to say know, you're creating this e-commerce app. This is how we're going to approach it, right? And this is what we want at the end of it. The destination should be the minimum viable product. It should not be some full featured, we built Twitter over six months, right? But that's not how Twitter got there. That's not how you're going to get there.

And again, we mentioned it earlier, the whole point of doing the mvp fast feedback right get it out into the hands of the people that are going to be using it get their feedback and then spend time on the features that they see being valuable right don't waste time on stuff that's not um and the beautiful part of this too is waterfall, where scope creep was like the two words that you heard every meeting, this isn't scope creep. This is just pivoting and adjusting and working on the next most important thing. Well, that's the big deal. I think that's the big difference, though, right, is that Waterfall was all about protecting against scope creep, whereas Scrum and Agile are recognizing that scope creep is a reality and you need to be able to adjust for it and pivot when it pops up to, you know, don't try to ignore it, but, you know, work on it, accept it. Yeah. It's, it's no longer scope creep. It's more of, oh, this seems like this should be the priority, right? This adds the most value to the product. Let's focus on the thing that

adds the most value to the product. It's not scope creep. It's, you know, just work on changing needs. That's it. So here's the next key part. And this is, we're almost to the end of this one and we'll start talking about the individual bits in the next episode. But in this one, once you have the vision out there, you have to start to decompose that vision, right? Because saying, hey, we want an e-commerce app where people can order food from their own home and have it delivered. Okay, fine. You can sort of see it, but you got to break that down into its pieces, right? So what they like to call it is you break it into themes. And a theme is nothing more than a broad grouping of similar work. Are these the stories or are these the tasks for the story? No, this is actually above stories. So themes aren't usually like if you're working in an

Atlassian world or something like that, themes aren't necessarily represented in the ticketing system, right? This is more of a breakdown of your main vision. This is probably something you put into a wiki, right? Or something like that for showing your roadmap and how you want to get there. But the purpose of the theme is you're grouping that similar work together, because that allows you to be more efficient when you're working on something, right? Like you could totally imagine if you're working on a user profile page, keeping all that work in sprints that are pretty close to each other will allow you to stay familiar with that code and work on it easier.

Right. And this also allows you to think about finishing up these chunks of work in a particular required order. So here's an interesting thing that I found because I was kind of curious when you brought up the Atlassian point. And they actually have, I'll include a link to it, there's an Atlassian Agile Coach page, and it talks about Epic's stories, themes, and initiatives

and the differences between them. So it's kind of weird because I think they have them kind of out of order in my mind, but it says, what are stories, epics, initiatives, and themes? Stories are also called user stories, are short requirements or requests written from the perspective of an end user. Epics are large bodies of work that can be broken down into a number of smaller tasks called stories. Initiatives are collections of epics that drive toward a common goal. And themes are large focus areas that span the organization. So I think about

leadership versus management. Management is how you get there and leadership is where you're going and i kind of think about that leadership is coming from like the kind of c levels of the board and so like you might have a quarter and the ceo or gm says hey uh we are we need to get profit to uh you know five percent up and we need to cut costs by five percent and uh you know we need to roll this new product out by this whatever and so that to me those are the three themes and so all the stories should hopefully align to like making those goals happen and so i kind of think of that as being a little bit outside of jira it's like more at the business level um so you know that's how i kind of think

about it but it's more about strategy than the tactics i i think that absolutely could work. It really needs to be something that you can visualize is really what it boils down to. So if you have your roadmap, right? Like you just said, your C-level says, hey, we want this app out there, right? That's going to be on your roadmap, that thing. Then you're going to break that down and say, all right, the themes of this are, you know, whatever they're going to be. You know, we want to create this ordering thing, right? Like maybe that's a theme. But the whole purpose of that is you can then chart that on some sort of calendar and say, we think that this theme, because we've broken it down into X number of stories or whatever, is going to take us two months to get this done, right?

Across three, four, five sprints, whatever it is. But it two months to get this done, right? Across three, four, five sprints, whatever it is, but it allows you to break it down that way. So yeah, I mean, it's a little bit harder to do when you don't have a project sitting in front of you to sort of break down this way, but yeah, I agree. And to what you just read off of the Atlassian page too, Outlaw, the thing that stinks about it is some of those are just sort of ethereal, right? Like you don't have your initiatives and you don't have your themes in Jira, right? They're just things that you've planned out. And the only things that actually show up in Jira are your epics and your stories and then your tasks. So it could be like towards, you know, I think it still lines up though with what Joe said, because like the theme might be like, Hey, you know, your, your respective CEO has said like, Hey, I want to reduce our costs.

So we're going to, I've, I've negotiated a better deal with another cloud provider. So we're going to switch cloud providers. That's the theme. And then the initiative might be a collection of epics that are going to do that migration of work. And then an individual epic might be a very specific portion of that. And then you start getting more specificity as you go down to the story and then the subtask.

Right. But it all falls under the theme of, Hey, we're switching cloud providers. Right. So you wouldn't have a, you wouldn't have a JIRA for like, Hey,

we're switching cloud providers. Right. Right. But it falls under that. So I think, I think the way that Jay-Z said it about the difference between leadership and management, like I liked that,

you know, analogy. I think, hold on, let me see. So, oh, yeah, the next part's here. So I used a couple of these things here. So after you've identified those themes, like what you were just doing with the cloud things, like some of the stuff that I put on there is if you had a theme that was for a user profile in your application, right? Some of the features would be things like you need to be able to change your password, set up multi-factor authentication and link your social media accounts, right?

Like those would be some of the things there. But here's the key part. Once you've identified those features that you need, you might not be doing all of them. Because remember, the goal is to get the MVP out the door. So you might say, hey, in order to get this MVP out that I can get into the hands of my stakeholders, the only thing that's absolutely required at this point is a change password. Get it out to them, let them give you feedback, and then figure out what the next features are that you want to implement next.

So with that, that kind of wraps up what we have in this particular episode. Next episode, we're going to start getting into the nitty gritty details of the user stories, the tasks, the sprint planning, all that kind of stuff, right? Like how you actually implement it. So hopefully this gave you a decent overview of what the goals and, and what is involved with setting up the scrum and the teams. And next episode, we'll get into how you actually do it. Okay. And maybe some of the problems and use cases. I'll pay attention on that one then. Not this one.

Right. I think. Yeah. I think. Yeah. Oh, man. It went longer than 15 minutes. We all lost focus. Yeah, a little bit. Like, yeah, we didn't adhere to the stand up that well.

But, you know, that's okay. I mean, things are getting faster, like, all the time. And, like, our meetings are getting faster. Our computers are getting faster. I told my father that modern computers have gotten so fast that they can complete an endless loop in 10 seconds. That was pretty good. Thank you, Klaus. Who was that one?

Yeah. Klaus? Yeah. All right. So there'll be some links that we'll have in their resources. We like section, um, that, uh, you can, you know, follow along with as you're listening to this and, you know, we've said this before, but in case if you didn't know this, if this is new information to you, um, as you're listening to this episode, most podcast players will include our show notes, which, um, you could read and scroll through as you're

listening to the episode. So you can click into these, these links in their resources. We like section, uh, as we're, as we're talking about it and follow along. So, um, you know, there's your, there's your, uh, podcast tip of the week right there. we head into alan's favorite portion of the show it's the tip of the week hey hey uh i'm first oh uh so i wanted to mention a free technical writing book and the reason i wanted to mention it specifically because i haven't actually read very much this is uh they actually have several examples uh i mean like i don't know 15 examples of i don't know a lot of examples of uh really good like letters and proposals and uh that sort of thing so if like you want to write a complaint email like here's a several like just

looking at the complaints there's like five of them uh that kind of like show you good examples of uh what that looks like if you have to write a progress report which is something that we do sometimes like here's one uh database development and really lays out like the format um whether it's just tables where the bullets look like what the kind of um uh what's called the the overall structure of the thing. Cause I think writing really good artifacts, whether it's emails or wikis or whatever, it's so important to not waste your time. Cause if you write an email,

that's not properly formatted or too long or whatever people don't read it. If you write, it's too short that people don't get any value out of it. And so I think it's really important to be able to write well for humans and also for searchability. And so there's a free book. It's all about it. And I've got a, I'll put the link link the examples there uh too which is really nice so it must be working for you i mean you say you haven't read this but i i swear you must have

because uh jay-z's wiki documentation has been on point lately so yeah kudos to jay-z i just like pull up one of these things. I changed the words to my topic and I'm done. It makes sense. Just copy and paste. Yep. Find an airplane. That is programming,

right? It's copy paste edit. So yeah, makes sense. Makes sense. All right. Well then, uh,

we'll head into my tip of the week then. Uh, so, okay, I got a few of them following in Alan's footsteps here. So I've only got 17, so I'll go through these as quickly as I can. But in the past, I believe it was Jay-Z

that had recommended using canines for all your Kubernetes needs. And I recently, I ran into trouble with it and every time, like I've said this before, but you know, the issues that I have with canines, I don't believe to be a fault of canines, just my environment and things, you know, like I just have had bad luck. Right. And, but, um, you know, other people that we work with like are all raving about. So I've been forcing myself to like, uh, okay, let me, let me see if I can just like overcome like the environmental issues that I'm having on my system with it. And, you know, I'm gonna force myself to, to use it. And, uh, you know, because, you know, I, I, I'm, I'm definitely not trying to hate on it. I recognize that like,

you know, the issues are on my end, but, um, so one of the cool things that I found that, you know, everything in Kubernetes and canines you can do from the command line, but you know, canines is all about like trying to make things easy. So one of the cool things that you can do is you can create a cron job in your Kubernetes cluster. And the hassle with that is that, you know, it's going to be on a schedule. And if you're testing that, that cron job, you want to be able to like just execute it right then and there, make sure that it's working correctly. And, you know, life is good before you commit your code in. Right. But in canines, you could just do an escape colon, type in cron jobs to see all the cron jobs that are in your cluster, select your specific cron job, and then control T, boom, it'll go run it. And so I thought that was like – there's a lot of things that you could just do with ease, right?

And so there you go. There's can lot of things that you could just do with ease, right? And so there you go. There's canines. Yes. And then a couple other ones that I thought I would mention that I don't know that we've really given much love on this show. But I know that we've talked about Connie Mew and Commander, but I don't know that we've talked about Windows Terminal. And I've actually switched from Commander, which is really just a wrapper on top of Konami. I've switched from that to Windows Terminal. And it's pretty nice because it's like a built-in Microsoft kind of way of doing the terminals. And you can do all the same kind of things.

I haven't discovered anything that, um, Connie, me, you could do for me that I can't do with windows terminal. Um, aside from the big one, which is,

you know, the, the whole purpose of commander is the fact that you could just throw it on a USB drive and pop it into any system. And boom, you have your terminal, your favorite terminal there. But,

um, you know, aside from that one takeaway, like everything else that you would want to do with, uh, those like splitting multiple terminals side by side, you know, aside from that one takeaway, like everything else that you would want to do with, uh, those like splitting multiple terminals side by side or one on top of the other or whatever you can do with windows terminal, you can, uh, keyboard shortcuts to like start up a new terminal, the same ease of copy and paste, which sounds silly. Uh, if you're coming from any other environment, except if you use command command prompt, which if you're coming from any other environment except if you use command prompt,

which if you're still using command prompt, we need to have a talk. But so there's none of that like, hey, let me go up to this little menu that's hidden and do a mark and let me go back up to it to do a paste. And it's really simple in Windows Terminal. And you can easily customize it to change what you want your default terminal to be, what you want the ordering of the terminals to be. If you want to, you know, because that'll impact the keyboard shortcuts for it. You know, you can have an Ubuntu shell startup. You could have a PowerShell, whichever one you want. You can easily add into that list list of available shells and, again, change your default. So, like, every time you open up Windows Terminal, maybe it defaults to your WSL Ubuntu instance.

And so, yeah. So I thought we would, like, you know, I thought we should give Windows Terminal its due because I didn't recall that we had already. And I apologize if we have. But another one that I don't think that we've talked about either, though, is the GitHub CLI. And so we'll have a link to that as well. And the GitHub CLI is pretty nice because, you know, you can, I guess the big one would be the ability to create your pull request from the command line. Because, you know, technically pull requests are not like a get thing. That's a, that's a feature that was added on top of get, um, you know, uh, you know, the visualization of it was really just

something that was built on top of it. But, uh, yeah, so the GitHub command line gives you the ability to create those pull requests from the command line. And you can check on it. You can check on your repo, your issues, the status of your PRs, various commands like that. So it's pretty cool. And I thought, hey, let's include a link to that. Yeah, I actually have this tip a while back, by the way. Oh, you did? I'm sorry. No, I love this, though.

So just creating a repo in there alone is pretty amazing. And the issues, too. So I actually like to be able to create issues. You see it. And it's really good about prompting you for what you need to do. So say, like, GH, I think it's like new repo or something. A repo new. And then it'll prompt you.

It's like, hey, do you want public or private or whatever? So it can kind of step you through that stuff so you don't have to memorize a bunch of arguments. But I love it's like new repo or something, a repo new. And then it'll pop just like, hey, do you want public or private or whatever? So it can kind of step you through that stuff so you don't have to memorize a bunch of arguments. But I love it. Well, I will include that. Oh, yeah. It was in episode, what number was this that it was mentioned? 142. So it wasn't even that long ago.

Yeah, I'll include a link to that in the show notes. Outlaw has forgotten that in the show notes. Yeah, it's good stuff. Outlaw has forgotten something in the episodes. Yes, finally got him. Yeah, it's the mind's first thing to go. So I guess this is the beginning of the end. Sayonara. All right, so I have a handful here that I just remembered a few of them as as we're going

through these the first one the first one man i love this so this is actually a jet brains plug-in that's available on a lot of the jet brains ide's not all of them which kind of stinks but from what i understand it's at least in PyCharm, IntelliJ, and some other ones. I think they have an exclude list. But it's called grep console plugin. So if you go into your IntelliJ or your JetBrains IDE and go to the preferences and go to plugins and search for grep console,

that's all you need to do, install it from there. It's so awesome. So I don't know if you guys, if you run an application, an IntelliJ or PyCharm, you'll have your debug console and you'll also have your console output, right? Now, the JetBrains IDEs are really good about letting you search in that console output, right? So if you're looking for a log message or something coming from your application, you can search for it and it'll highlight it in there.

But what stinks is if you've got 5,000 lines of that stuff, you've got to scroll down to try and find all the instances of it, right? This grep console plugin will let you put in a regular expression or even just a string of text that you want to search for. And it will only include the lines directly in the console output. So it's just like having grep in a shell except available within your IDE. It is fantastic. So I would highly recommend installing that. The next thing. so this came up, I was actually helping somebody out

with a PowerShell problem the other day. And so the terminal thing is what made this pop into my head is the Windows terminal is pretty good. Conn and move, command are all those. We've all liked them. One thing that I really like about PowerShell, and I think we've talked about it here on the podcast before, is it's cross-platform now, right? So in the old day, you create shell scripts because it was sort of the most universal way to do things, right?

If you create batch files, it's only good on Windows. If you create shell scripts, it mostly works on Linux and Mac. Well, PowerShell, if you create a PowerShell script, you can actually put the PowerShell executable on Linux, Windows, Mac, whatever. There was a weird problem ran into the other day, though. When I execute PowerShell scripts on my Mac, I usually call PWSH and then pass in the script name and then pass whatever arguments to it, right? The problem is Boolean values. So if you shell in, if I were to just run PWSH and it opens me into a PowerShell terminal, everything worked fine.

But if I passed a Boolean doing PWSH powershell script name and then dash argument and true or false, it would fail. It would say it couldn't convert from a string. What you have to do if you need to be able to pass it calling the powershell command with the script is you do the argument name colon true or false. So the colon is important. It's really weird.

It's an odd way to go about it. Hopefully this will save somebody hours. I think I spent probably an hour trying to help somebody out on this the other day. Really obscure. And then the last thing I want to share is actually from what? Go ahead. Well, I was going to ask, like, did you intend to include a link to that? Was there a link for that? I will try and find one.

Like that was actually the problem is when I was trying to find the solution on how to make this work. There wasn't much out there. Like it was really frustrating. It took a while to try and figure it out, but I'll try and find something and drop it in the show notes. And then I also have another stuff for the last tip here is from Ted Possum, who just got a new position. Congratulations. That's awesome. He reached out and let us know that here's a good tip for those of you that have picked up a Jet Brains product and you're in the middle of using it, right? Like you're halfway into your subscription or whatever. JetBrains is really awesome, right? They allow you to prorate

purchasing an upgrade or so if you wanted to go to the all tools plan and you paid $100 for IntelliJ or whatever, they'll allow you to apply a prorated amount of that to the upgraded tool. Right? Like it's not like you just have to jump over there and do it and they'll do it at any point during your subscription period. So, um, that's a,

that's a great tip. One to know about. So, um, and it's automated. We're sharing that. You don't have to go through a person. Like you could just literally go to the JetBrains website and be like,

Hey, I want to, I want to automate, I want to, uh, Oh, what's the word? Uh, JetBrains website and be like, Hey, I want to, I want to, I want to, uh, Oh, what's the word? Uh,

prorate this and it'll, it'll figure it out for you. Like through the website. You don't. Amazing. Yeah. So it could be like 3am in the morning and you're like, you know what?

I want to get up all the products and I don't feel like talking to people because it's three o'clock in the morning. Right. So, yeah, that was, that was it for all of mine. I'll, I will update those and we'll have those

in the show notes for you as well all right well uh we hope you've uh you enjoyed this episode where we talked about um i guess all the boring parts of scrum because you know the the good parts that we're supposed to pay attention to we we get to on the next episode, I guess. But hey, thanks for hanging in there with us so far. And if maybe a friend sent you a link or you're listening to it from their device or something like that, if you haven't already, you can subscribe to us on iTunes, Spotify, Stitcher, wherever you like to find your podcasts. I'm sure we're there. And if we're not, let us know. We'll figure that out. And like I said before, if you haven't already, we greatly appreciate the reviews. They really do put a smile on our face and we enjoy reading

those. So you can head to www.codingblocks.net slash review and find some helpful links there. Got to keep them on their toes. All right. So while you're up there at the website, you can definitely check out our show notes or even like Outlaw said earlier, if you're in the podcast player, you know, the show notes are probably there just to swipe away. We have some good discussions up there. Drop us a comment. You can do that on Fedbox.net slash episode 155. And you can send your feedback, questions, and rants to our Slack channel, which did we ever get that resolved? Do we know?

No. I did update the text on the page, so now it basically says, hey, send us an email. Well, preferably not an email. Send us a tweet or something, and we'll get you in there. Slack changed our API, and they changed it, so the requirements for using the API specifically for invites has changed. You basically have to be on an enterprise plan. So it looks like this is the way.

Until we move to discord right that's a lot of people to shift all right make sure to follow us on twitter at coding box and send that request over there or heading over to CodingBox.net. And you'll find all our social links at the top of the page.