Most developers we know find project management to be a necessary evil but without it a lot of us would be stumbling around in the dark. Shawn and Caleb look back over their careers to discuss different project management methodologies. Whether it is waterfall, agile, scrum, or none of these, projects are hard to manage. Both Shawn and Caleb have seen a lot of different ways that projects can be managed or mismanaged and they have differing opinions on what works best. Join us for this episode to find out which they prefer and what allows them to focus on getting to work coding. What is your preferred project management style? Let us know on Twitter at @dotnet_Podcast

Picks

Hello, and welcome to another episode of adventures in dot net. I'm Sean Claiborne, your host. And with me today, your co host from Louisiana, Caleb Wells. Hey. Hey.

How are you? Hey, y'all. Exactly. Hey, y'all. Good.

We're, of a a warm warm jet stream coming off the coast, so we've had a lot of rain and things that like that lately, but, at least it's not snow. No. Hey. That's, yeah. Snow's no good.

Yeah. We're we're coming off of, we're coming down from Mardi Gras, I guess. But we've had a week of nice weather, fifties in the morning and mid seventies in the afternoon. So can't complain there. But yeah.

So, it's just us today. I thought maybe we could spend a little bit of time talking about project management. You know, I kinda had some Sounds like fun. That over the over the number of years. There's ways to put things together and Yep.

Something's good. Something's frustrating to me as far as, you know, just personally how I like to do things. I like to always keep things as as simple, as streamlined as as possible. And sometimes, project management structure can help you with that. Sometimes it can, be a little frustrating.

So what's your Yeah. What's your experience? Well, I honestly, I think I've with different jobs of yours, I've been all over the spectrum. Right? For me, I do like some structure.

I do if scrum is done well, I think it works. But right there's so many cogs that have to fit just right to get things to work without holding you or the process up. Right? So what about you? Yeah.

I mean, over the years, I think I've done you know, everybody kinda started out that's been doing coding for a while. They started out with kind of the waterfall where you do a a big block of things, and then you have a release. You know, there's a big block of things, and then you have a release, and so on and so forth. So that's always been very fairly straightforward, but it isn't always the most productive as far as, you know, getting things out the door so that the the customers are getting that better experience for each release, you know, in a more timely fashion. And so I I've been working a lot in the past with small teams, you know, maybe 2, 3, 4 type developers, and so we're all able to kinda switch instead of waterfall to work on our own little block of things that we need to to add to the code or create and then release that.

And that always worked well for for me. It's kind of in agile, but it's without a lot of formalities. It's more of, okay, we need to get this small little feature done or this bug fix or whatever. We don't worry about the big description of it in in a feature or a user story or tasks and things like that. It's just basically just, you know, it is just task based type stuff or or maybe just feature based stuff, but without the formalities of, you know, putting it in a project management type system other than, you know, I, for years, I used just used Trello, and that worked well for me to just have a little card that says, here's the little problem, here's the issue, whatever.

And Trello was good enough, or I moved things from left to right as it worked along the workflow progress, and then got out out the door and released. And lately, I've been doing a lot of things with, you know, Azure DevOps, and Azure DevOps is a a great product. And I think it's it helps with larger sized teams. I can definitely see the benefit when you're on a larger sized team, and people have to know where everything's at and what people are working on, and have some some transparency and visibility of what what's going on in the project as a whole. But I think it can get still a little bit overwhelming, a little bit extra stuff that goes in there that really isn't that necessary in my opinion.

What's your thoughts? Yeah. Right. Depending on how big the project is or how big your part of it is or what you need details, the whole epic, and then and I think you and I have talked about this. Right?

The the whole, like, Jira workflow, so to speak. Right? Azure DevOps has a a similar flow. Epics, features, tasks, user stories, I think those have their place depending on the size of the project. But when you've got a smaller team, I do agree with you that that might be overkill.

You actually reminded me of I've been on teams where you've had the gamut. Right? You have developers, you have leads, You have QA. You have business analyst. Then you have a project manager.

Right? And I've worked in a couple of those where they worked out well, for me at least, because all I had to do was write code. Right? The user stories were done for me. The requirements were gathered.

Most of the time, I had the majority of what I needed, and I could just go do my job. Right? Which is kind of the ideal. But then on the opposite end of the spectrum, you know, I've been in teams where it was just 2 or 3 developers. Like you said, there's no QA, no business analyst, no nothing.

And that's where I do find that more structured approach or all the tasks and the backlog and user stories more cumbersome because you as a developer end up doing it. Right? So Yeah. For me, what works is basically just give me give me the feature or the task, and a wireframe, if you if you have it, is great because I work very well visually seeing what, you know, this is what you're looking for. This is what you're expecting.

And then the the acceptance criteria for that. You know, if I get into user stories, I'm sorry, but I skip most of the things that they actually describe up there. You know, the whatever role as a Yeah. Whatever role I need to do I want to because, yeah. Yeah, yeah.

It's like that doesn't help me as a developer, you know? I don't care who, it's just the thing I need to build needs to do this. Whoever's using it, I don't care. It's just like, but, you know, it's in there, and it seems to be that's what the, you know, the formal description of of agile, you know, calls for, and so people do it. And I always question those things.

You know, you mentioned kinda using Trello. Right? And just moving things over as they come along. And I've worked at companies where you kinda did the the kanban board approach. And I think that's fine if you don't have any tight deadlines or there aren't expectations that you're gonna get this item done this week and this item done next week.

Right? If you do, if your business, if management has those expectations, I do find that true sprints work better. Right? Because you can say, okay, I can pull in these two tickets and almost guarantee that I'll complete them in this sprint, but then you're not expected to to grab another ticket if you have one day left in the sprint. You know what I mean?

Mhmm. How do you feel about that? Yeah. I, I work off tickets, you know, in the sprints and things like that, and Mhmm. Sprints are okay for me because, you know, it's saying during this time period is this is what we expect to get done, and and this is what's gonna be working on.

On what? And that's great. I think it's great. Estimates seem to always be off no matter what. Oh, yeah.

Oh, they're gonna be. Yeah. So, yeah. Why put a number to it when that number is just, really isn't a single number? It's a range.

It is. It could be a 3. Oh, yeah. Could be an 8, depending on whatever I run up against while I'm implementing it. So if I run up into something that doesn't work the way I think it should be working, and I've gotta go out and research and figure out why it's gonna the number gets bigger.

Yep. And so it's like, okay. Do I always overestimate Mhmm. Under promise, over deliver type of thing? Or do I try to give an honest number so that they can plan based around that, but then comes to, okay, you're supposed to be done that with that.

Why are you still working on it? Well, because of this. Okay. They totally understand, John promised that, but but, it's been a hard Some some management does. Yeah.

It's interesting because I have gone to work for companies that had that kinda did waterfall, but they but they really didn't have tickets. It was just like this person in management or the owner or whatever had this idea what they wanted. And they're like, okay. I want you I want this. And I've come in with other senior developers and implemented, you know, more of of a process.

Right? And it's interesting because sometimes that process rubs management the wrong way. Because once you commit to a sprint, you can't just decide you want me to do something else tomorrow. Right? You can't decide something else is a higher priority.

I mean, you can, but but you're violating the process and and all that stuff and it has to be a fire. Right? And I've also worked at places where initially, they actually gave had us give estimates in hours instead of story points, which is even less accurate than story point. Right? Yeah.

I've I've been all over the place, but I have heard management, for lack of a better word, complain about the sprint process or or how it limits them or limits us moving forward or limits enhancements. I think that's really a lot of that's perspective. For me, it's it's puts us in a position to do our best and guarantee that what we write is quality code and is not gonna break something else. And if you're just flying by the seat of your pants and throwing stuff at the wall and changing priorities, you're going to end up getting poor code one way or the other. Right?

It doesn't really matter how good of a your developers are. And when it comes to story points, for instance, right now, my current company, the complexity of our systems is on the very high level of complexity. Not not intentionally, but just the way that it's grown organically. And so we look at something that in another shop might be a 3, and it's an 8 year. There's nothing you can do about it.

And so we tend to lean more towards the higher estimates because we know we're gonna have added complexity or run into issues. Right? So Yeah. Another benefit that I've had, you know, with being in a system that's a little less formal is bugs really irritate me, especially bugs that affect the user experience because that's the number one priority for me on anything that I build is the user experience. And if they're getting things that it's not working how they expect it or how it should, that's always my top priority.

So I could be working on something and a bug gets reported that's affecting them, and I wanna jump off what I'm working on right now and fix that and and get it out the door. And and to me, you know, if you're working on sprints and you've got things assigned to it, it's like, is it okay if I grab this bug and but it's gonna affect my points for the current story that I went on, and things like that. Right. So sometimes, that's okay, but sometimes it's like you're assigned this as the way you gotta work on. If the bug is high enough priority, then we'll assign it to somebody else that's not working on something, so on and so forth.

Mhmm. You know? And that also irritates me when I'm reporting bugs to companies, those things that I work for. It's like, hey, I found this bug. Fix it.

And they said, well, what? Add a trail list. It's like, no. It it affects my experience, and not only my experience, but all the other users' experience. So why don't you just fix that?

Yep. I agree with you there. The flexibility to be able to pull in bugs or issues that are impacting your customer base, I I think that's valuable. And and I've been in positions where I've been able to do that. But I was also it was an odd setup because the product owner, he wasn't really worried about timelines or even necessarily return on investment.

So right? He would say, this is what I want and this is how I want it. We're like, okay. Well, it's gonna take twice as long to do it this way than if we did, did it a a certain way, you know, the, a more, I guess, normal way. It's like, I don't care.

I'm like, okay. And so, you know, you spend 3 weeks working on an item. And if bugs pop up in between there, you go and grab the bugs, and you can fix them and come back to that feature. Right? So I I do find the value in that.

One of the other ways of approaching it, which is kind of what you said, and I understand that it can frustrate you, especially if it's something that you worked on and a bug got out. But, we currently have a production support team in our company because we do have so many issues that pop up and things in existing code or trying to migrate code or trying to update and things don't mesh well. So we actually have a team that has all we do is bugs. And so if if a bug comes up, they're gonna handle it, which in turn means that that we don't we focus on the task we've been given, and we don't have to use that mental space thinking, oh, this got out there, and I wanna go fix it. Right?

So you prefer okay. Or you're okay with agile as long as it's more loosely defined, and and you got more flexibility. Yeah. That kind you're going to. With that.

Yep. Yep. I think of all the places I've worked, and, of course, this was more when I was a, like, a mid level developer. So I don't even know that I'd get that now if I were working there in my current role, but I loved having a full team, and all I had to worry about was the code in front of me. That worked out really well.

But, again, in my current position, that wouldn't happen anyway because I get pulled into meetings for this or I'm helping determine how we're gonna handle this or architecture decisions. And then you end up at well, this is a a good thing too. And I'm curious how how you approach this when it comes to sprints and managing your time. The longer you're on a project or the longer you're at a company, you're going to become, a subject matter expert on something or some area. Right?

And so then if if someone is trying to write code in there or a bug comes up, you're the first person people think about. They're like, hey, Caleb. Can you join us in this meeting to discuss so and so and yada yada? And you end up in an hour and a half meeting. Right?

And then they still can't figure it out. So later in the week, you end up actually doing pair programming with them. Right? And it's good that they have that resource, and it's good that there is a subject matter expert, but that definitely impacts your sprint and the time that you have to complete your work, or you think. Yeah.

It happens to me all the time because, you know, as I've been, you know, a developer for so long, you know Right. How much I know and have experience, you really can benefit a lot of the other developers that I work with. So I find myself being they're stuck. It's like, reach out to Sean, and, he'll he'll figure out the the issue, and we'll get past this. So a lot Yep.

There's a lot of context switching. So there's some costs there Mhmm. For me to switch over what I'm doing and figure out, okay, clear my mind, load it up with what they're doing, and figure it out, and then come back to what I'm working on, and pick it up. So but I think, you know, as far as the overall picture, I think that's probably worth it because we need to keep everybody moving, not just Right. Some parts of the train are faster than other parts of the train.

So Yep. No. I'm I get it. And I think in some cases, that also helps determine the story points you put on things. Because well, in in right?

Story points are subjective, and and they're gonna be different for different people. But for a junior, something might be an 8 for different reasons that I might give it an 8. Right? Again, context, like you just said. So yeah.

You know, this is this is one of those things. I don't know company does it right, and there's no perfect way of doing this. And there's there's finding a space that works for for you and your company, and it's a moving target. Right? How do you divide up what juniors work on versus what seniors work on?

Is it easier stuff, the less important stuff gets to the juniors, and then do you always have a senior look something over that a junior rerouted, and Oh, yeah. Prove it, work together with them? Because there's times where somebody that's really new developers works on something, and they spend a lot of time on it. And then I look at it and go, I I go, oh. Yeah.

Yeah. That's not quite the way you should do it. And, you know, they have to learn, which is which is Oh, yeah. Great. You know, I always I learned at the beginning too.

I asked lots of questions, but some 2 years feel a little intimidated or shy about asking questions when they get stuck, and so they just kinda work through it and get it to work and pass it on. It's like without saying, okay. This is the way I should do it Right. And asking for help. Yeah.

So and I and I've told everyone in our team. Right? There is no such thing as a as a dumb or stupid question. Because if you don't know, then then it's, you know, you you need to get the information somehow. And so I've, I've told them, hey.

If you have questions or need help, hit me up. Right? As far as determining who does what, I really feel like in my experience, juniors end up getting more of the front end work. Right? And not necessarily because it's simpler, but because if you really if you screw up some back end logic, you could be affecting a vast array of things.

If you're working on 1 or 2 pages, right, inside of an application and, you know, maybe you're doing some forms or specifics, you the impact is lessened. And they can still learn things like MVC and controllers and that kind of stuff and and get more comfortable with dot net and the c sharp language. So that that's where we've tended to have juniors live in my my experience. We do pull requests regardless of who you are. It does not matter.

If it's if it's going into the develop branch, it gets a pull request. And then, of course, it has to be fully tested. And once it's out in master, then even going from develop to master is a pull request. That one's kind of a rubber stamp. Yes.

It's not master. But it's still up here. Well, some of ours are still master. So it regardless, the the primary branch. Right?

I actually and and that's that's that's a weird thing with work because half of ours are master and half of ours are main. No. You're right. Yeah. The it's main more these days.

But here's the thing. I can tell if a junior is learning and growing, if they can if they ask questions and they can take constructive feedback. Right? If you send me a poll request and there are issues, and since front end is my my domain, right, I might get in the weeds. And I'm not gonna tell you that how you code something is wrong necessarily on the way you your the your style of coding, unless we have a defined style cop, right, or format.

But I am going to question, well, why don't you do it this way? Or does this cover all of the use cases? Or this might be more efficient? Right? And so sometimes I can go to, a pull request and everything's good.

And I maybe have to do one comment, and it's not even something they need to fix. Other ones, I get in there, and I've I've got 20 comments. But I've seen juniors I've worked with grow that way. Right? And you can see their code changes and matures, right, as they do.

And then there's some developers who just don't ever get it, and you can bring the same thing up in every PR, and it never changes. So yep. Yeah. I guess a lot of my experience, with juniors has been, at least with with juniors that have had a couple years of experience, you know, I've never had to deal with anybody that's just right out of boot camp or right out of college or anything like that as far as in the professional environment. You know, I used to I used to teach college students how to program and things like that.

And so you could always kinda pick out the ones that that really got it and the ones that that didn't. But as far as creating production code and things like that, I've always dealt with somebody that's had at least a couple years experience. So Mhmm. That's kinda thing made things a little bit better for me. I wouldn't have any problem, you know, if somebody came out a boot camp or or college that's that's really good, and they they they showed that what they learned while they were in school, or even their side projects that they did while they were in school, really show an an aptitude for for being a a good developer as far as their understanding of patterns and practices and things like that.

So Yeah. It's we work in a very interesting industry. It is still figuring things out as we go. Right? Actually, I think I was reading something like Quora and somebody was saying, we really shouldn't be called software engineers, But that but that was the closest engineers were the closest thing to what we do that that that the name made some sense.

Right? But we're we're really not even that close to engineers in general. Right? Engineers, I think, a lot of them are much more structured in their work. Whereas with software, sometimes it's the wild, wild west.

Right? Whether you want to be or not. Yeah. Well, I mean, if if we make a mistake and are building or or structuring something, just Yep. Some data.

They make a mistake. You know, if you're talking about, you know, actual physical engineers Oh, yeah. Like that. That can be dangerous. So, yeah, they definitely deserve some kudos there for what the risks that they take on and that they have to to think about and go through.

You know? Yep. We have a bug. It's like we can we can fix it. They have a bug Yep.

That's gonna be really expensive. Oh, yeah. Yep. Or maybe we're making bugs for them for all this Oh, I don't doubt it. The tools they use.

I don't doubt it. The amount of bugs and poorly written or poorly performing or code that that has security issues, there's more of it out there than there's not. It's put it that way, which I guess says something about our industry or the the the youth. Right? We still got a lot of, growing to do.

So Yeah. There's a lot of times where, I don't know about you, but I'm using some software, and it's working really well. It's like, knowing the process that they had to go through to to get that built Mhmm. It's like, you know, it's almost you knowing what's behind the curtain. You're almost Right.

Scared. It's like, k. There probably a lot of people worked on this. There's gotta be some some issues in there somewhere knowing what the what the process is Will be like and developing code. And it's like When when I say that trust software, and how much do do you not?

Right. But when I say that, I'm like, man, I'd like to work for this company. Of course, of course, like you said, you we're seeing the finished product, and we're like, oh, man. This is great. It does it does what I need, and it works.

And but, you know, maybe if you were inside looking out, you would not have the same opinion. So, yeah, perspective. Perspective. Yep. Okay.

On that notes, let's, wrap this up and, and Yeah. Have a have a good weekend, and hope our listeners have a good weekend, and, let's do some picks. Cool. Sounds good to me. Alright.

Alright. Do you have a pick? I do. My pick is, and it's funny because I think I picked Lost Ark, maybe a month ago or a few weeks back. Mhmm.

I'm already on to another game. He's doing really well on on stream. Oh, yeah. Oh, it's, yeah, it's game buster. Says it's good, but I haven't had I haven't had the chance yet.

Yeah. No. It's it's fun, but, you know, there there's always a new, treasure or a new jewel to to go after. Guild wars 2 released their 3rd expansion. It's been like 5 years.

And I've been playing Guild wars off and home for years. So I've hopped in, and I'm trying that. And I'm really enjoying one of their new classes. So if you have played Guild Wars too and you like it, then maybe check out end of dragons. Is there a new expansion?

And every expansion, each class gets a new specialization, which is based on a different way of playing the class. And they came up with some cool ones this time around. So that's what I've been playing the last week or so, was Guild Wars 2 with the dragons. Oh, okay. Nice.

I don't know if you know that I used to do a lot of video production. Yeah. For the local towns around here, I used to do TV commercials, things like that, and things like so I've always been into, you know, good audio, good video, good lighting, and all that kind of stuff. I did video production. I did, and then I did photography for a number of years, and retouching and things like that.

So one thing that I picked up lately is a new video light for using in the office, and Yeah. I guess it's just it's just me, but even for, like, my Zoom calls or my team meetings or even in recording the podcaster, I'm always looking to have a good microphone, a good webcam, good lighting. I actually run a green screen behind me, even though hardly anybody else you know, it really doesn't matter. I could just use one of the little, you know, fake backgrounds or whatever, but I'm running green screen, and I just picked up a new video light that I use in front of me while I'm recording and in meetings and things like that. So I'm looking well.

And I was looking at one by Elgato. Mhmm. And it was a nice one, but it was a little more expensive than I wanted to to spend. So I searched around Amazon and I found one by a company called Neewer. They make a lot of things Yeah.

Nowadays. And I've found a lot of good products by them. And so I found this lighting kit. It's about a $100, but it's the nice thing about it is it's kinda got a large light, and so you want large lights to get more of a soft feel for whoever the light is hitting. It's not so direct and and so it's got a large screen.

It's adjustable to really, really bright. I almost run it at it at its lowest lowest setting while I'm here in my office, but it's got a remote control so I can control the brightness from the remote while I'm sitting here. But I can also control the color temperature. So Oh, yeah. I need to look a little bit warm when I'm on video.

So I lower the cut the color temperature to about 38 to 4000 Kelvin Mhmm. Rather than daylight, which is more like in the 5000, 6000 Kelvin. And, it makes me look better, I think. So Cool. So I don't look great.

Yeah. For me. I, Just because it's me. So I picked I actually bought my wife's, one. Yeah.

It's, hers isn't anything near yours, but I got her a cheapy one that she, clamps through her laptop. You know, because, you know, with people working from home and COVID and everything, you still wanna look good. I mean, like, right now, I don't have my lights on, and I I look junky, but it's just you and me. Right? You know?

So Yeah. Yeah. I mean, listen, for a hundred bucks, it comes with a case, the light, the desk mount that Yeah. Clamps to your desk, and then telescopes up, and then you can you can angle it down to what a Wrangler you want in power supply. So Nice.

Yeah. It was it was good for me. Works well. Let's see. Cool.

It can go super bright. It's like Okay. Yeah. Good deal. 45 watt light, so, yeah, pretty bright.

And that's 40 watt 45 watt LED, so Oh, nice. Yep. Okay. Good deal. Alright.

So if our listeners wanna reach out and get in touch with me, they can listen to or they can follow me on Twitter and give me feedback on the show. Let us know what kind of topics you wanna hear. I am at dotnetsuperhero. And they can also listen to us right here. Right?

Weekly. It's much better to listen to us than than if they could actually see us. Yeah. And I'm Caleb Wilkes Coates. Although no one reaches out, I'm just I I feel unwanted and loved.

Anyway Alright, guys. We'll catch everybody else on the next episode of adventures in dot net. Bye