Detailed Notes
In a recent episode of the Developer Building Better Developers podcast, Rob Broadhead and Michael Meloche delve into the nuances of Agile development, with a particular focus on defining and achieving “done” within Agile frameworks. This discussion is critical for developers who aim to deliver functional software efficiently while avoiding common pitfalls like scope creep and burnout.
Read More... https://develpreneur.com/defining-done-in-agile-how-to-stay-on-track-and-avoid-scope-creep
Stay Connected: Join the Developreneur Community
We invite you to join our community and share your coding journey with us. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.
Additional Resources * Getting It Right: How Effective Requirements Gathering Leads to Successful Software Projects (https://develpreneur.com/getting-it-right-how-effective-requirements-gathering-leads-to-successful-software-projects/)
* The Importance of Properly Defining Requirements (https://develpreneur.com/the-importance-of-properly-defining-requirements/)
* Changing Requirements – Welcome Them For Competitive Advantage (https://develpreneur.com/changing-requirements-welcome-them-for-competitive-advantage/)
* Creating Use Cases and Gathering Requirements (https://develpreneur.com/creating-use-cases-and-gathering-requirements/)
Transcript Text
[Music] and there we go we have figured out where the record button is because they move it around because I love I'm not going to name who they are but they may start with the last letter of the alphabet um this episode we're following up from the prior one and we're going to go into the agile world of it took you a second to get that didn't it um anyways this time we're gonna go into the agile world of scope creep everybody's favorite like actually it's everybody's favorite Boogeyman I think everybody is always worried about scope creep and all this kind of stuff and yet every project seems to have it but particularly in the agile world and I think that's where we're going to go with this one is how to how to manage it really because that's sort of what it I mean agile is really built on we don't really know what the finish line is yet we sort of know where we're going but we want to be able to change gears but you still need to and this is I think where it really is uh it can be done by the the scrum master but it's usually going to be more like the product owner with in combination with the team the development team is basically how do we keep this stuff on track how do we keep it from going off the rails how do we get something that is useful and not let the customer just bury Us in last minute things this actually even it's interesting because it ties into something we've talked about before uh I don't think we ever talked about on the podcast but where we've talked about when we get close to the end of a product that we're building it is very particularly if it's our own product we stretch out the Finish Line basically because we're like oh I want to put this in there I want to put that in there I need to do this I need to do that I want to do this we keep piling stuff in instead of stop it give it a like this is your definition of done and I think we're the worst when it's our own product because we don't think about saving ourselves from that little living hell and yet we you know it is something that we run into so we can also I think we can empathize with our customers but that's where you have to have those conversations that we'll talk about as we get into the podcast but I think that's what I want to focus on is how agile does not stop us from having things like what does done look like and some of those things and we as you talked about earlier maybe we talked about some of the ceremonies and things that will help us uh keep those things on track is this a good one to also include when the communication breaks down with between the different departments because I ran into a situation similar to this where we were we've been really good at hitting all of our Sprints you know we're on track and then somehow a epic we were working on was conceived by business to be done but we weren't done and it was not done because tickets weren't created by the developers by the product as needed and then people went on vacation and we had lots of miscommunication during that time so I don't know if that's a good one for this one or save that for another one um I think I don't I think it's probably a good one to step into it's communication is always key with all of these things and it really is the I think that's the the nut of what this story is about or what this episode is going to be is it's really about communicating that how to do that and making sure for example that's a great example of where things can go wrong is where you know people assume that there's some features or something in there but it doesn't get created right and the next thing you know somebody thinks because the backlog is empty everything's done but it the problem is because the backlog was not properly filled goes back to missing requirements effectively um so I think that's a good I think that's a good example to use of where things can go horribly wrong to some extent or maybe completely to an extent all right so we'll dive into this one one hello and welcome back we are continuing the Journey of a developer as we're talking about being building better developers and this is the develop andur podcast I am Rob Brad I one of the founders of develop andur and also a founder of RB Consulting where we help you tame technology through simplification Automation and integration we take all of that crap that's out there and find ways to put it all together in a nice pretty bow on it and all that kind of stuff so that you can use these things and not have 15,000 logins or having to do a lot of manual imports and exports and all of that stuff that is a headache now one of the things we do is we talk about what's good and bad that's happened since the last time we talked so from a good point of view I'm going to start with I actually have a couple of customers right now that there is the the budget the bandwidth to do it right you know a lot of times we get into stuff and they're like it's like it's got to be done today it's got to be done with it like cut hours cut testing cut this cut that you know documentation can be done later and things like that where they keep cutting Corners to try to hit their deadlines but they're they're really sort of hurting themselves and they get to the end and they're like well I've got something that's completely you know it's it's not done and you say correct it's not done because we didn't put the time in to get there and I've got customers that are able allow me to do that and it is so fulfilling to be in a situation where you can actually apply all your skills in doing things the well say in quotes the right way but being able to do that uh bad thing is bad thing I guess is my kids are I've got like I'm going to be an empty nester soon and one of the empty nester one of them that are flying The Nest is going to be like this close and for those that can't see it which is some of you a lot of you maybe um very close I've got my fingers all the way together uh this close to being out of money and so it's already like he's going to be able to get in and he's going to have to grow some vegetables in the backyard or something wherever he's at because it's like dude your budget is like your Runway you're gonna you're going right off the Runway so we're gonna have to work on that bad news too long on that so I'm gonna pass that on to you and let you introduce yourself hey everyone my name is Mikael milash I'm one of the co-founders of developer building better developers I am also the founder of Envision QA where we help businesses and analyze their software to identify basically workflows that are either not in the system or find better ways for their software to work for them instead of against them so with that I'll go into my good the good is one of the projects I'm working on while we are in a bit of a time crunch because of the necessity for their change we are taking the time and they're willing to work with us to Define these requirements correctly so we avoid a lot of the things we're going to be talking about today on the bad side my wife bought this wonderful TV at Christmas last year and it's gotten to the point now where we've tried moving it around the room a couple different times but because of where they put the speakers we can't hear people speak at all so I had to buy another external speaker more cost hopefully this thing works but right now I'm not holding my breath ah that is my favorite I ran into that just the other day with some I'm trying to remember what it was but it's one of those where it's like you have to use close captioning because the speakers and such are just not where they should be or they have bad audio it's like one of these things where all these soft talkers and there's loud stuff going on and you put in close captioning and suddenly you see it's a whole different show it's a whole different story because that's stuff that you miss because they don't get the audio right old right yeah that's that's for another topic we can have like a we can have a venting session I want to talk about agile this time and with respect to done now one of the things that we have talked about in the past in both for career and for projects are the idea of road maps and it is in the agile world you have these like epics and things like that so it's not there are things that span multiple Sprints but an epic doesn't necessarily get you a product what I think you need to really have and I found that has worked the best when you're going into a an agile approach is that you have an MVP which is a minimally viable product and that's from the start from Sprint one you have them in an MVP which is very hard to say together but you have that and yes it will it will be adjusted basically as you're going from Sprint to Sprint to Sprint but what you should be able to do then is show progress towards that product that you're going to release now of course in a Sprint technically if you're doing them right you have a usable deployment of software at the end of every single Sprint now we all know that that does not always happen there are cases where usable is I've got a login screen and I can log in okay great that doesn't really help me a whole lot there are going to be situ or maybe you have to go to Sprints you don't release this one because it's just too many things in flux I get that but that should help because you're going to show some usable things along the way that are and usable is obviously it's a soft definition of what usable is but those should be marking you towards your MVP your MVP is your why that is why we are going through these Sprints we're getting to this thing that is what helps us Define done because if we have all the features that we decided were going to be the minimally viable product in that yes we can continue but at least at that point we know that we are done we'll say that we have completed that project now that doesn't mean that you set it up on Sprint one and you don't think about it again until Sprint 10 it does mean that that is a living thing just like everything else but it gives you it gives you like an anchor it gives you a foundation it gives you a core because you can look at that as you're going from Sprint to Sprint to Sprint and I'm going to let Michael talk a little bit about some of the the things about agile that may help you with this but what you're going to do is you're going to have conversations effectively about this is a big change to the MVP or this is a minor change to the MVP or I'm gonna go on mute for a second because I'm about to sneeze oh wait maybe not wait apologies you can always edit that out or not because hey that's We Roll um as you're getting to that mvp there are going to be changes maybe that are made to it that are big that are substantial and those are the things that you want to communicate back to the product owner to the customer that we have now made a big change so it may be a big change that says we are effectively back to Sprint one or this is now going to add multiple Sprints of function it and even within that as you're going from Sprint to Sprint to Sprint there should be there's if it's done right you're always also looking ahead the product owner the scrum Master are looking ahead and if you're starting to look ahead and you're seeing nothing but we're just adding just adding just adding we're not really getting closer to that then those are the kinds of things you need to bring a heads up to say hey this is going beyond the scope of what we originally talked about this is going Beyond we talked about as a comfortable Runway to get this thing launched because those those require those are like meta or core requirements to the project it's not requirements when we're talking about software requirements these are requirements like we only have X amount of dollars or x amount of resources or x amount of time or there are you know maybe there's regulation authorities or stuff like that where we have to have certain stuff by a certain time period which become yes that's your MVP that's your why those are the things that if you're moving off of that mvp if you're pushing back that those should always be discussions that's a great communication point to say hey we're making some changes and we just want to all agree like when you first make them we want to all agree that that makes sense and that's going to work so we don't get in a situation where we try to bite off essentially bite off more than we can chew as part of that I'll toss it over to you and let you you go you know sort of step into that from your point of view yeah so typically either when you're first starting out or if you're already in a release cycle system with agile one of the key takeaways with agile which is supposed to help avoid some of this scope creep and some of this uh bloat or unforeseen uh requirements is your daily standup you know you you meet as a team you talk through what you're working on uh are you blocked by anything did you run across something that is in of itself requiring a requirement from something else that either wasn't thought of or another piece of work that's being done that is behind holding you up or did you just get ahead uh and so on so we moved our tickets through the process of you know we're working on it it's in progress we're blocked testing and so on the other thing is when you move it to testing did the tester run across a scenario that wasn't thought of you know did you have a special character that was supposed to work that's not working as expected so there are other things that at least within the standup process you catch daily and these things can get flagged and hopefully addressed quickly either individually with one-on ones or as a team as a whole the other thing as you're going through the process at towards the end of every Sprint you're going to have a backlog refinement where you're going to sit down as a team with the product owner the business owner and go through the requirements for the MVP that you need to work on for the next Sprint you know what are the next batch of features that we need to roll in or what tickets from the current Sprint are potentially going to roll over because we're running into some difficulties or it's taking more work or we we hit some type of blocker that caused a little bit bit of time uh you know scope to be added to the ticket and then when you get to the end of the Sprint you should always do some type of Sprint burndown go through your tickets that you just completed in the previous Sprint and identify you know what went well what didn't go well uh what requirements you know did we miss uh and make sure all that gets put in to tickets if that is either not communicated to the business or not in tickets it's going to be missed you're going to run into situations where you know someone could go on vacation for a month come back be your manager product owner and they think everything's going to be done based on the timelines and then they come back and it's like yeah it's ready to go we missed a feature so now it goes out and you have an unhappy customer or the product doesn't even work it breaks so now you have more deadlines or more delays trying to get this software out the door so by doing the uh kind of burndown and uh end of Sprint review you collectively as a team hash out what you can do to make things better what can you do as a team what would essentially is your development agreement to keep things moving forward to get these tickets done right get the right requirements into these tickets and also make sure that as a team you have a collective understanding of what the definition of done is is so as you work on these tickets you're not just throwing the ticket over to test with one line uh of change that doesn't address all the the issues that were in the ticket so you don't want to miss things that you're you should be doing causing tickets to go back and forth through different phases that are happening because you didn't do the work right the first time now the other side of that is don't sit on a ticket for days trying to make sure it's 100% right because again we're shooting for that mvp but if you run into blockers if you run into situations where this ticket should have taken like a day or two but now you're on day three maybe day four maybe it's time to bring it up and stand up or collectively have a team huddle and say let's hash this out I'm stuck or something's just not right so you kind of have to communicate work together to get back on track so again your Sprint moves smoothly you're going through the right Peaks and valleys and your software is continuing to move down that mvp towards your deliverable at the end of the spring two things are really important there one that's probably a little bit off of the scope creep thing but I do want to touch on when you pick up a ticket there is an estimate attached to it and that is often that is a huge part of what you should have in your mind of like what level of coding of what is the scope of this what is it that I should be dressing if it's a if it's something that roughly should take you you know half a day and it's into a full day and you're still not done with it those are like those are little Flags to say hey let's raise that up in the Sprint or in the standup or ideally before you get into it if you think it's going to take longer than that that should be part of the estimate discussions so it should be clear on what really is the what is really contained within this ticket and again it also helps you Define what's in the it helps you write a better ticket because if somebody says you know if you're scoring it on a scale of 1 to 20 and bunch of people say one and a bunch of people say 20 that's a good point to say okay we need to talk about what does this mean because obviously we have a very different picture of what this project is now I really want to look at the U at the burndown the retrospective kind of piece of a Sprint because that is also something where we can very easily get into the mode of we you know we get a couple tickets done but we push a couple into the next Sprint and into the next Sprint and into the next Sprint and very often when you've got a team working on you know they get in that retrospective like what went well what didn't usually what you're end up finding is somebody's going to say hey we keep like punting stuff to the next Sprint this is going to bite us at some point we need to figure this thing out we need to estimate better we need to project better whatever it is because if you're still kicking stuff forward then that technically means you're probably somewhere down the line pushing out your release dates you can't keep doing those things and those should be a heads up if if we're seeing this that may be something that you say okay in the next Sprint one of the things we're going to do is we're going to walk through and look at what are we doing why are these slipping and then make those adjustments because it could be that it could be from almost anything it could be the tickets are not being the requirements are not deep enough and so we're spending too much time kicking those back we're in a cycle trying to flesh those out it could be something where nothing's being Mark done until the last day of the Sprint and then QA doesn't have time to test it all and then all that stuff gets kicked into the next one it could be anything in between those as well and it could be things like scope creep it could be things where we originally had this picture of what the MVP was but as we're getting clarification from Sprint to Sprint it's changing what that mvp is and maybe we haven't looked at that enough to say hey we are now expanding on that or we're shifting it in some way form or fashion that is now something we need to communicate back to the powers that be the people that sign your check the customers people like that to say hey this is not where we started what we talked about and where we thought we were going to go we're not going there it would be stuff like you know you start in Washington DC and you're like oh we're just going to go to you know Cincinnati but along the way you realize you have to go all the way out to San Diego if you guys don't know geography Google Maps but you know it's one of these things is that those things can be and we've had those kinds of situations there are projects that are so much like that where it's like we're going to go to this little place that's not that far away this is like a this is easy I that is the worst thing to hear in software development this is gonna be easy that's easy that's no problem yeah just use that piece of cake that is should always be a red flag there's Pro what if it's not just ask that question what if it's not what if that doesn't work the way you think it is those are the kinds of red flags that should be even if we're heads down in development those are things that we should be thinking about when we get into our reviews and our retrospectives as we really should be looking at what is the feedback that we're getting from the customer when we're going through that demo that review process are we seeing things that are are concerns to us that maybe we're not hitting the mark and then in the retrospective are we repeatedly bringing up something along the lines of we're kicking stuff down the road too often and that we need to make that our priority in the next Sprint uh more thoughts on those because I know I did open the can of worms a little bit more oh yes um so I'll t on a little bit because I didn't talk about the points before um but as you're reviewing the tickets and defining the requirements and the definition of done as a team collectively you want to agree on a pointing system or we use points to kind of figure out okay who do thinks it's easy who thinks it needs a little more work and then you kind of flush out an average to use as a team for the ticket this helps kind of Define the deadlines or how long that works going to take so that they can plan out release Cycles unfortunately though and I like you touched on this but sometimes you run across a bug that is a major bug or you have like medical laws change or financial laws change and you have to do something because of Regulation but you have to do it quickly well sometimes that gets thrown in but they don't take something out so if you start seeing a lot of things not necessarily just being kicked down but if you see more and more work coming into a Sprint after it's started and stuff is not being taken out you're never going to reach the end you're going to kind of be in that CR crunch firefighting mode and you're kind of on a death march until you get to a point where you can say cut now let's start over let's begin again but unfortunately you're going to probably be in a situation where you're three four five six Sprints down the road and your team is in crunch mode firefighting mode burned out these are other signs that you need to revisit your Sprints these tickets to make sure that things are moving smoothly if you see a lot of people dropping burnout PTO revisit your plan revisit your schedule because something that is another indicator that something is wrong and you may not see it right now but very quickly you you will start seeing that scope creep or you're going to see that um release Cycles being missed and tickets that should take a day or two probably going to take longer just because the mental capacity is not there for your team yeah let I guess we'll we'll continue on discussion another time because there's a lot we can go into this I do want to mention that there's going to your point there is to think about and that you may not be able to as a developer but if you're a scrum master in particular think about Sprints that are and as a product owner even that are uh Performance Tuning Sprints that are bug fixing Sprints and it's really hard to sell a technical debt Sprint but it may be one of those things and a lot of times I think I've seen it best done where there are technical debt tickets that get pushed into each Sprint and maybe it's only one or two but it's something that hopefully you can you know and they're almost they're never going to be the we got to have it or almost never but try to have somebody like if you can just tackle one or two two of those from Sprint to Sprint to Sprint it at least is moving the ball forward and we talk so much about you know momentum and moving the ball forward in our careers and it's the same way in software because as Michael suggested you get this burnout you get all this stuff when we don't if we as developers don't feel that we're done then we're going to end up stressing about it so we need to help the customer and ourselves by saying what does done mean and this can be down at even a feature level it's like when this feature is done what is it going to do what do we need to take care of now if we're writing buggy code and stuff like that that may be on us it may be partially because of stress but but if we should be able to you know go through test it verify it and then if it's a bug maybe it's an integration bug or something that we can come back and usually then hopefully it's not critical so we can say I'm not gonna I'm not going to push it into this Sprint I'm going to we'll put it on the backlog we'll make it a high priority we'll tackle in the next Sprint or maybe two or three Sprints down and if you talk to your customers if you sell it that way as we call it refer to that way and say hey where we're not we're focused on this other work right now it is not effective and this is true it's probably going to be not effective to go chase down those bugs instead we're going to get this feature thing that we're working on done and then we'll come back in another Sprint and we'll go through those bugs because that makes more sense and that in particular saves you one if you do that the customer trusts you to say okay we're going to come back and fix it two it saves you from those most annoying things where it's like this is just going to take me a minute it's things like you know this color isn't right or this isn't spelled right or this button needs to move or this this field needs to go from a date to a date time or those things that are yeah we can probably fix them really quick but it takes us out of our groove it takes us off of whatever the main track is and if we're not doing those in bunches and in a batch kind of approach it really hurts us as far as like Switching gears mentally as that time goes I was going to pass it back to you but I'm not because I think we've run one about this we're going to run this we will wrap this one up we're going to make it a two-parter this probably will actually be sort of a three-parter maybe even we'll see where we go with the next episode apologies if we run a little bit long if we've gotten a little long- winded but these are the things that are near and dear to our heart and should be to you as well because these are where we win and lose the battles for building better software is it making sure that we are communicating making sure that we understand what we are building what does done mean what are the requirements what is the goal line what does that mvp look like that is why we go out to you all the time as we are looking for our requirements via email so send us an email at info developer.com check us out on developer.com and check out all the different content there which is a lot over a thousand articles out there on a wide range of stuff leave us comments you can leave them on the article you can there's a contact us form you can use that you can check out school. developer.com there's also comments in all kinds of sections in there that you can go check that stuff out see a little bit different way to consume all the content we have there any of those areas including this one leave us comments leave us you know ratings whatever you want to do and include please what would you like to see what are some things that we could do more of do less of what are the things you like what are the things you don't like sort of like a retrospective in a Sprint what do we do right what did we do wrong what do we do more of what do we need to stop or do less of that kind of feedback is what helps us help you and it will help us give you a more entertaining and educational we'll say dare I say educational podcast that being said go out there and live your Better Life as a better developer until we meet next time go out there and have yourself a great day a great week and we will talk to you or at you next time bonus material so with this one I'd like to kind of throw the idea of kind of within scope Creek look at the tickets is it something that needs to happen I need to have I have to have or a want to have really break it down into that because if you're running into scope creep or you're running into Sprints where tickets are just kind of being kicked down the road reset look at what is it that you're pulling in and make sure it is for that mvp not just a nice to have feature that could have waited till we got this particular release out the door that is excellent I think I really like that as sort of a follow-up is that it's because we didn't bring that up is that it's really is it's like musthave nice to have you know want need cool you know that kind of stuff because the cool stuff almost is never going to get done I mean you may but it's more going to be like what do you need and this is where as a better developer I think it really and this I'm thinking about this because I've got a customer right now that they're they're figuring out this Grand Vision of what their product is and we're in sort of a Sprint we're doing an agile approach we're not fully doing sprints but it's pretty close and this is where a good developer better developer is going to help their customer better is talking through them with them if you have that opportunity what what this can look like and giving them some examples instead of them sort of being in their head of like this is how I see this process or this is how I see us solving this problem toss some ideas out there and say hey I'm you know you are the customer we want to help you do your job better or solve your problem better but maybe here are some things that I'm hearing that are different approaches to it or when you're looking at that you know what do you need what do you sort of need what you really not need at all kind of list is looking at that and saying helping them out with that because there's going to be pieces that we know from a technology point of view it's like no you don't think you need that but you really do need that and it does get into technical stuff times it's sometimes it's things like particular if you're getting into compliance related stuff so it may be uh security or uh like auditing controls or logging or it maybe things like we have to set up a development environment or production environment or we have to set up you know a a development environment a testing environment a production environment and we need to have the pipelines that move those things out they may say oh yeah we don't need that we'll do that later it's like no you may say we really need to get this now because we need to really hammer on that so that by the time we do a real like a full production process we have beaten The Living Daylights out of that thing and we know all of the good and the bad and we know that it works we don't want to wait till you know the last Sprint and that's where we're actually going to figure out what deployment looks like I think that is something that too often we miss and we either end up oversizing or undersizing it's a little easier to do in a sense it's a little easier to do if you do Cloud deployment because those things can just dynamically grow however that Dynamic growth can also dynamically grow your bill and sometimes your your I'll say it your architecture your core solution is really not designed for where they need to be so start that earlier on that's one of those things that they'll also often pass off and you might even as well because you don't want to you know start spending that cost on them but find ways to work into it and that's just an example that being said I think that's enough bonus material right now so we will wrap this one up we'll come back next time maybe a part three and maybe not we haven't really talked about that yet uh as always we're just figuring this out as we go but as you know there we could spend days and we mean not just us but all of us the greater develop or Community here could all spend forever talking about all these little headaches and gotas and all the little you know War Stories from our careers whether you've been doing it for a year or hundred years 100 years would be really fun to talk about I guess because your technology was not the same then but nevertheless uh one once again thank you guys for your time I don't want to waste any more of it go out there have a great day we will talk to you next time around [Music]
Transcript Segments
[Music]
and there we go we have figured out
where the record button is because they
move it around because I love I'm not
going to name who they are but they may
start with the last letter of the
alphabet um this episode we're following
up from the prior one and we're going to
go into the agile world
of it took you a second to get that
didn't
it um anyways this time we're gonna go
into the agile world of scope creep
everybody's favorite like actually it's
everybody's favorite Boogeyman I think
everybody is always worried about scope
creep and all this kind of stuff and yet
every project seems to have it but
particularly in the agile world and I
think that's where we're going to go
with this one is how
to how to manage it really because
that's sort of what it I mean agile is
really built on we don't really know
what the finish line is yet we sort of
know where we're
going but we want to be able to change
gears but you still need to and this is
I think where it really is uh it can be
done by the the scrum master but it's
usually going to be more like the
product owner with in combination with
the team the development team is
basically how do we keep this stuff on
track how do we keep it from going off
the rails how do we get something that
is useful and not let the customer just
bury Us in last minute things this
actually even it's interesting because
it ties into something we've talked
about before uh I don't think we ever
talked about on the podcast but where
we've talked about when we get close to
the end of a product that we're
building it is very particularly if it's
our own
product we stretch out the Finish Line
basically because we're like oh I want
to put this in there I want to put that
in there I need to do this I need to do
that I want to do this we keep piling
stuff in instead of stop it give it a
like this is your definition of done and
I think we're the worst when it's our
own product because we don't think about
saving ourselves from that little living
hell and yet we you know it is something
that we run into so we can also I think
we can empathize with our customers but
that's where you have to have those
conversations that we'll talk about as
we get into the podcast but I think
that's what I want to focus on is how
agile does not stop us from having
things like what does done look like and
some of those things and we as you
talked about earlier maybe we talked
about some of the ceremonies and things
that will help us uh keep those things
on track is this a good one to also
include
when the communication breaks
down with between the different
departments because I ran into a
situation similar to this where we were
we've been really good at hitting all of
our Sprints you know we're on track and
then
somehow a epic we were working on was
conceived by business to be done but we
weren't
done and it was not done because tickets
weren't created by the developers by the
product as needed and then people went
on vacation and we had lots of
miscommunication during that time so I
don't know if that's a good one for this
one or save that for another one um I
think I don't I think it's probably a
good one to step into it's communication
is always key with all of these things
and it really is the I think that's the
the nut of what this story is about or
what this episode is going to be is it's
really about communicating that how to
do that and making sure for example
that's a great example of where things
can go wrong is where you know people
assume that there's some features or
something in there but it doesn't get
created right and the next thing you
know somebody thinks because the backlog
is empty everything's done but it the
problem is because the backlog was not
properly filled goes back to missing
requirements effectively um so I think
that's a good I think that's a good
example to use of where things can go
horribly wrong to some extent or maybe
completely to an
extent all right so we'll dive into this
one
one hello and welcome back we are
continuing the Journey of a developer as
we're talking about being building
better developers and this is the
develop andur podcast I am Rob Brad I
one of the founders of develop andur and
also a founder of RB Consulting where we
help you tame technology through
simplification Automation and
integration we take all of that crap
that's out there and find ways to put it
all together in a nice pretty bow on it
and all that kind of stuff so that you
can use these things and not have 15,000
logins or having to do a lot of manual
imports and exports and all of that
stuff that is a headache now one of the
things we do is we talk about what's
good and bad that's happened since the
last time we talked so from a good point
of
view I'm going to start with I actually
have a couple of customers right now
that there is
the the budget the bandwidth to do it
right you know a lot of times we get
into stuff and they're like it's like
it's got to be done today it's got to be
done with it like cut hours cut testing
cut this cut that you know documentation
can be done later and things like that
where they keep cutting Corners to try
to hit their deadlines but they're
they're really sort of hurting
themselves and they get to the end and
they're like well I've got something
that's completely you know it's it's not
done and you say correct it's not done
because we didn't put the time in to get
there and I've got customers that are
able allow me to do that and it is so
fulfilling to be in a situation where
you can actually apply all your skills
in doing things the well say in quotes
the right way but being able to do that
uh bad thing
is bad thing I guess is my kids are I've
got like I'm going to be an empty nester
soon and one of the empty nester one of
them that are flying The Nest is going
to be like this close and for those that
can't see it which is some of you a lot
of you maybe um very close I've got my
fingers all the way together uh this
close to being out of money and so it's
already like he's going to be able to
get in and he's going to have to grow
some vegetables in the backyard or
something wherever he's at because it's
like dude your budget is like your
Runway you're gonna you're going right
off the Runway so we're gonna have to
work on that bad news too long on that
so I'm gonna pass that on to you and let
you introduce
yourself hey everyone my name is Mikael
milash I'm one of the co-founders of
developer building better developers I
am also the founder of Envision QA where
we help businesses and analyze their
software to
identify basically workflows that are
either not in the system or find better
ways for their software to work for them
instead of against them so with that
I'll go into my good the good is one of
the projects I'm working on while we are
in a bit of a time crunch because of the
necessity for their change we are taking
the time and they're willing to work
with us to Define these requirements
correctly so we avoid a lot of the
things we're going to be talking about
today on the bad
side my wife bought this wonderful TV at
Christmas last year and it's gotten to
the point now where we've tried moving
it around the room a couple different
times but because of where they put the
speakers we can't hear people speak at
all so I had to buy another external
speaker more cost hopefully this thing
works but right now I'm not holding my
breath
ah that is my favorite I ran into that
just the other day with some I'm trying
to remember what it was but it's one of
those where it's like you have to use
close captioning because the speakers
and such are just not where they should
be or they have bad audio it's like one
of these things where all these soft
talkers and there's loud stuff going on
and you put in close captioning and
suddenly you see it's a whole different
show it's a whole different story
because that's stuff that you miss
because they don't get the audio
right old right
yeah that's that's for another topic we
can have like a we can have a venting
session I want to talk about agile this
time and with respect to done now one of
the things that we have talked about in
the past in both for career and for
projects are the idea of road maps and
it is in the agile world you have these
like epics and things like that so it's
not there are things that span multiple
Sprints but an epic doesn't necessarily
get you a product what I think you need
to really have and I found that has
worked the best when you're going into a
an agile approach is that you have an
MVP which is a minimally viable product
and that's from the start from Sprint
one you have them in an MVP which is
very hard to say together but you have
that and yes it will it will be adjusted
basically as you're going from Sprint to
Sprint to Sprint but what you should be
able to do then is show progress towards
that product that you're going to
release now of course in a Sprint
technically if you're doing them right
you have a usable deployment of software
at the end of every single Sprint now we
all know that that does not always
happen there are cases where usable is
I've got a login screen and I can log in
okay great that doesn't really help me a
whole lot there are going to be situ or
maybe you have to go to Sprints you
don't release this one because it's just
too many things in flux I get
that but that should help because you're
going to show some usable things along
the way that are and usable is obviously
it's a soft definition of what usable is
but those should be marking you towards
your MVP your MVP is your why that is
why we are going through these Sprints
we're getting to this thing that is what
helps us Define done because if we have
all the features that we decided were
going to be the minimally viable product
in that yes we can continue but at least
at that point we know that we are done
we'll say that we have completed that
project now that doesn't mean that you
set it up on Sprint one and you don't
think about it again until Sprint 10 it
does mean that that is a living thing
just like everything else but it gives
you it gives you like an anchor it gives
you a foundation it gives you a core
because you can look at that as you're
going from Sprint to Sprint to Sprint
and I'm going to let Michael talk a
little bit about some of the the things
about agile that may help you with this
but what you're going to do is you're
going to have conversations effectively
about this is a big change to the MVP or
this is a minor change to the MVP or I'm
gonna go on mute for a second because
I'm about to sneeze oh wait maybe not
wait apologies you can always edit that
out or not because hey that's We Roll
um as you're getting to that mvp there
are going to
be changes maybe that are made to it
that are big that are substantial and
those are the things that you want to
communicate back to the product owner to
the customer that we have now made a big
change so it may be a big change that
says we are effectively back to Sprint
one or this is now going to add multiple
Sprints of function
it and even within that as you're going
from Sprint to Sprint to Sprint there
should be there's if it's done right
you're always also looking ahead the
product owner the scrum Master are
looking
ahead and if you're starting to look
ahead and you're seeing nothing but
we're just adding just adding just
adding we're not really getting closer
to that then those are the kinds of
things you need to bring a heads up to
say hey this is going beyond the scope
of what we originally talked about this
is going Beyond we talked about as a
comfortable Runway to get this thing
launched because
those those require those are like meta
or core requirements to the project it's
not requirements when we're talking
about software requirements these are
requirements like we only have X amount
of dollars or x amount of resources or x
amount of time or there are you know
maybe there's regulation authorities or
stuff like that where we have to have
certain stuff by a certain time period
which become yes that's your MVP that's
your why those are the things that if
you're moving off of that mvp if you're
pushing back that those should always be
discussions that's a great communication
point to say hey we're making some
changes and we just want to all agree
like when you first make them we want to
all agree that that makes sense and
that's going to work so we don't get in
a situation where we try to bite off
essentially bite off more than we can
chew as part of that I'll toss it over
to you and let you you go you know sort
of step into that from your point of
view yeah so typically either when
you're first starting out or if you're
already in a release cycle system with
agile one of the key takeaways with
agile which is supposed to help avoid
some of this scope creep and some of
this uh bloat or
unforeseen uh requirements is your daily
standup you know you you meet as a team
you talk through what you're working on
uh are you blocked by anything did you
run across something that is in of
itself requiring a requirement from
something else that either wasn't
thought of or another piece of work
that's being done that is behind holding
you up or did you just get ahead uh and
so on so we moved our tickets through
the process of you know we're working on
it it's in progress we're blocked
testing and so on the other thing is
when you move it to testing did the
tester run across a scenario that wasn't
thought of you know did you have a
special character that was supposed to
work that's not working as expected so
there are other things that at least
within the standup process you catch
daily and these things can get flagged
and hopefully addressed quickly either
individually with one-on ones or as a
team as a whole the other thing as
you're going through the process at
towards the end of every Sprint you're
going to have a backlog refinement where
you're going to sit down as a team with
the product owner the business owner and
go through the requirements for the MVP
that you need to work on for the next
Sprint you know what are the next batch
of features that we need to roll in or
what tickets from the current Sprint are
potentially going to roll over because
we're running into some difficulties or
it's taking more work or we we hit some
type of blocker that caused a little bit
bit of time uh you know scope to be
added to the
ticket and then when you get to the end
of the Sprint you should always do some
type of Sprint burndown go through your
tickets that you just completed in the
previous Sprint and identify you know
what went well what didn't go well uh
what requirements you know did we miss
uh and make sure all that gets put in to
tickets if that is either not
communicated to the business or not in
tickets it's going to be missed you're
going to run into situations where you
know someone could go on vacation for a
month come back be your manager product
owner and they think everything's going
to be done based on the timelines and
then they come back and it's like yeah
it's ready to go we missed a feature so
now it goes out and you have an unhappy
customer or the product doesn't even
work it breaks so now you have more
deadlines or more delays trying to get
this software out the door so by doing
the uh kind of burndown
and uh end of Sprint review you
collectively as a team hash out what you
can do to make things better what can
you do as a team what would essentially
is your development agreement to keep
things moving forward to get these
tickets done right get the right
requirements into these tickets and also
make sure that as a team you have a
collective understanding of what the
definition of done is is so as you work
on these tickets you're not just
throwing the ticket over to test with
one line uh of change that doesn't
address all the the issues that were in
the ticket so you don't want to miss
things that you're you should be doing
causing tickets to go back and forth
through different phases that are
happening because you didn't do the work
right the first time now the other side
of that is don't sit on a ticket for
days trying to make sure it's 100% right
because again we're shooting for that
mvp but if you run into blockers if you
run into situations where this ticket
should have taken like a day or two but
now you're on day three maybe day four
maybe it's time to bring it up and stand
up or collectively have a team huddle
and say let's hash this out I'm stuck or
something's just not right so you kind
of have to communicate work together to
get back on track so again your Sprint
moves smoothly you're going through the
right Peaks and valleys and your
software is continuing to move down that
mvp towards your deliverable at the end
of the
spring two things are really important
there one that's probably a little bit
off of the scope creep thing but I do
want to touch on when you pick up a
ticket there is an estimate attached to
it and that is often that is a huge part
of what you should have in your mind of
like what level of coding of what is the
scope of this what is it that I should
be dressing if it's a if it's something
that roughly should take you you know
half a day and it's into a full day and
you're still not done with it those are
like those are little Flags to say hey
let's raise that up in the Sprint or in
the standup or ideally before you get
into it if you think it's going to take
longer than that that should be part of
the estimate discussions so it should be
clear on what really is the what is
really contained within this ticket and
again it also helps you Define what's in
the it helps you write a better ticket
because if somebody says you know if
you're scoring it on a scale of 1 to 20
and bunch of people say one and a bunch
of people say 20 that's a good point to
say okay we need to talk about what does
this mean because obviously we have a
very different picture of what this
project is now I really want to look at
the U at the burndown the retrospective
kind of piece of a Sprint because that
is also something where
we can very easily get into the mode of
we you know we get a couple tickets done
but we push a couple into the next
Sprint and into the next Sprint and into
the next Sprint and very often when
you've got a team working on you know
they get in that retrospective like what
went well what didn't usually what
you're end up finding is somebody's
going to say hey we keep like punting
stuff to the next Sprint this is going
to bite us at some point we need to
figure this thing out we need to
estimate better we need to project
better whatever it is because if you're
still kicking stuff forward then that
technically means you're probably
somewhere down the line pushing out your
release dates you can't keep doing those
things and those should be a heads up if
if we're seeing this that may be
something that you say okay in the next
Sprint one of the things we're going to
do is we're going to walk through and
look at what are we doing why are these
slipping and then make those adjustments
because it could be that it could be
from almost anything it could be the
tickets are not being the requirements
are not deep enough and so we're
spending too much time kicking those
back we're in a cycle trying to flesh
those out it could be something where
nothing's being Mark done until the last
day of the Sprint and then QA doesn't
have time to test it all and then all
that stuff gets kicked into the next one
it could be anything in between those as
well and it could be things like scope
creep it could be things where we
originally had this picture of what the
MVP was but as we're getting
clarification from Sprint to Sprint it's
changing what that mvp is and maybe we
haven't looked at that enough to say hey
we are now expanding on that or we're
shifting it in some way form or fashion
that is now something we need to
communicate back to the powers that be
the people that sign your check the
customers people like that to say hey
this is not where we started what we
talked about and where we thought we
were going to go we're not going there
it would be stuff like you know you
start in Washington DC and you're like
oh we're just going to go to
you know Cincinnati but along the way
you realize you have to go all the way
out to San Diego if you guys don't know
geography Google Maps but you know it's
one of these things is that those things
can be and we've had those kinds of
situations there are projects that are
so much like that where it's like we're
going to go to this little place that's
not that far away this is like a this is
easy I that is the worst thing to hear
in software development this is gonna be
easy that's easy that's no problem yeah
just use that piece of cake that is
should always be a red flag there's Pro
what if it's not just ask that question
what if it's not what if that doesn't
work the way you think it is those are
the kinds of red flags that should be
even if we're heads down in development
those are things that we should be
thinking about when we get into our
reviews and our retrospectives as we
really should be looking at what is the
feedback that we're getting from the
customer when we're going through that
demo that review process are we seeing
things that are are concerns to us that
maybe we're not hitting the mark and
then in the retrospective
are we repeatedly bringing up something
along the lines of we're kicking stuff
down the road too often and that we need
to make that our priority in the next
Sprint uh more thoughts on those because
I know I did open the can of worms a
little bit more oh yes um so I'll t on a
little bit because I didn't talk about
the points before um but as you're
reviewing the tickets and defining the
requirements and the definition of done
as a team collectively you want to agree
on
a pointing system or we use points to
kind of figure out okay who do thinks
it's easy who thinks it needs a little
more work and then you kind of flush out
an average to use as a team for the
ticket this helps kind of Define the
deadlines or how long that works going
to take so that they can plan out
release Cycles unfortunately though and
I like you touched on this but sometimes
you run across a bug that is a major bug
or
you have like
medical laws change or financial laws
change and you have to do something
because of Regulation but you have to do
it quickly well sometimes that gets
thrown in but they don't take something
out so if you start seeing a lot of
things not necessarily just being kicked
down but if you see more and more work
coming into a Sprint after it's started
and stuff is not being taken out you're
never going to reach the end you're
going to kind of be in that CR crunch
firefighting mode and you're kind of on
a death march until you get to a point
where you can say cut now let's start
over let's begin again but unfortunately
you're going to probably be in a
situation where you're three four five
six Sprints down the road and your team
is in crunch mode firefighting mode
burned out these are other signs that
you need to
revisit your Sprints these tickets to
make sure that things are moving
smoothly if you see a lot of people
dropping burnout PTO revisit your plan
revisit your schedule because something
that is another indicator that something
is wrong and you may not see it right
now but very quickly you you will start
seeing that scope creep or you're going
to see that um release Cycles being
missed and tickets that should take a
day or two probably going to take longer
just because the mental capacity is not
there for your
team yeah let I guess we'll we'll
continue on discussion another time
because there's a lot we can go into
this I do want to mention that there's
going to your point there is to think
about and that you may not be able to as
a developer but if you're a scrum master
in particular think about Sprints that
are and as a product owner even that are
uh Performance Tuning Sprints that are
bug fixing Sprints and it's really hard
to sell a technical debt Sprint
but it may be one of those things and a
lot of times I think I've seen it best
done where there are technical debt
tickets that get pushed into each Sprint
and maybe it's only one or two but it's
something that hopefully you can you
know and they're almost they're never
going to be the we got to have it or
almost never but try to have somebody
like if you can just tackle one or two
two of those from Sprint to Sprint to
Sprint it at least is moving the ball
forward and we talk so much about you
know momentum and moving the ball
forward in our careers and it's the same
way in software because as Michael
suggested you get this burnout you get
all this stuff when we don't if we as
developers don't feel that we're done
then we're going to end up stressing
about it so we need to help the
customer and ourselves by saying what
does done mean and this can be down at
even a feature level it's like when this
feature is done what is it going to do
what do we need to take care of now if
we're writing buggy code and stuff like
that that may be on us it may be
partially because of stress but but if
we should be able to you know go through
test it verify it and then if it's a bug
maybe it's an integration bug or
something that we can come back and
usually then hopefully it's not critical
so we can say I'm not gonna I'm not
going to push it into this Sprint I'm
going to we'll put it on the backlog
we'll make it a high priority we'll
tackle in the next Sprint or maybe two
or three Sprints down and if you talk to
your customers if you sell it that way
as we call it refer to that way and say
hey where
we're not we're focused on this other
work right now it is not effective and
this is true it's probably going to be
not effective to go chase down those
bugs instead we're going to get this
feature thing that we're working on done
and then we'll come back in another
Sprint and we'll go through those bugs
because that makes more sense and that
in particular saves you one if you do
that the customer trusts you to say okay
we're going to come back and fix it two
it saves you from those most annoying
things where it's like this is just
going to take me a minute it's things
like you know this color isn't right or
this isn't spelled right or this button
needs to move or this this field needs
to go from a date to a date time or
those things that are yeah we can
probably fix them really quick but it
takes us out of our groove it takes us
off of whatever the main track is and if
we're not doing those in bunches and in
a batch kind of approach it really hurts
us as far as like Switching gears
mentally as that time
goes I was going to pass it back to you
but I'm not because I think we've run
one about this we're going to run this
we will wrap this one up we're going to
make it a two-parter this probably will
actually be sort of a three-parter maybe
even we'll see where we go with the next
episode apologies if we run a little bit
long if we've gotten a little long-
winded but these are the things that are
near and dear to our heart and should be
to you as well because these are where
we win and lose the battles for building
better software is it making sure that
we are communicating making sure that we
understand what we are building what
does done mean what are the requirements
what is the goal line what does that mvp
look
like that is why we go out to you all
the time as we are looking for our
requirements via email so send us an
email at info developer.com check us out
on developer.com and check out all the
different content there which is a lot
over a thousand articles out there on a
wide range of stuff leave us comments
you can leave them on the article you
can there's a contact us form you can
use that you can check out school.
developer.com there's also comments in
all kinds of sections in there that you
can go check that stuff out see a little
bit different way to consume all the
content we have there any of those areas
including this one leave us comments
leave us you know ratings whatever you
want to do and include please what would
you like to see what are some things
that we could do more of do less of what
are the things you like what are the
things you don't like sort of like a
retrospective in a Sprint what do we do
right what did we do wrong what do we do
more of what do we need to stop or do
less of that kind of feedback is what
helps us help you and it will help us
give you a more entertaining and
educational we'll say dare I say
educational podcast that being said go
out there and live your Better Life as a
better developer until we meet next time
go out there and have yourself a great
day a great week and we will talk to you
or at you next
time bonus
material so with this one I'd like to
kind of throw the idea
of kind of within scope Creek look at
the tickets is it something that needs
to happen I need to have I have to have
or a want to
have really break it down into that
because if you're running into scope
creep or you're running into Sprints
where tickets are just kind of being
kicked down the road reset look at what
is it that you're pulling in and make
sure it is for that mvp
not just a nice to have feature that
could have waited till we got this
particular release out the
door that is excellent I think I really
like that as sort of a follow-up is that
it's because we didn't bring that up is
that it's really is it's like musthave
nice to have you know want need cool you
know that kind of stuff because the cool
stuff almost is never going to get done
I mean you may but it's more going to be
like what do you need and this is where
as a better developer I think it really
and this I'm thinking about this because
I've got a customer right now that
they're they're figuring out this Grand
Vision of what their product is and
we're in sort of a Sprint we're doing an
agile approach we're not fully doing
sprints but it's pretty
close and this is where a good developer
better developer is going to help their
customer better is talking through them
with them if you have that
opportunity what what this can look like
and giving them some examples instead of
them sort of being in their head of like
this is how I see this process or this
is how I see us solving this problem
toss some ideas out there and say hey
I'm you know you are the customer we
want to help you do your job better or
solve your problem better but maybe here
are some things that I'm hearing that
are different approaches to it or when
you're looking at that you know what do
you need what do you sort of need what
you really not need at all kind of list
is looking at that and saying helping
them out with that because there's going
to be pieces that we know from a
technology point of view it's like no
you don't think you need that but you
really do need that and it does get into
technical stuff times it's sometimes
it's things like particular if you're
getting into compliance related stuff so
it may be uh security or uh like
auditing controls or logging or it maybe
things like we have to set up a
development environment or production
environment or we have to set up you
know a a development environment a
testing environment a production
environment and we need to have the
pipelines that move those things out
they may say oh yeah we don't need that
we'll do that later it's like no you may
say we really need to get this now
because we need to really hammer on that
so that by the time we do a real like a
full production process we have beaten
The Living Daylights out of that thing
and we know all of the good and the bad
and we know that it works we don't want
to wait till you know the last Sprint
and that's where we're actually going to
figure out what deployment looks like I
think that is something that too often
we miss and we either end up oversizing
or undersizing it's a little easier to
do in a sense it's a little easier to do
if you do Cloud deployment because those
things can just dynamically grow however
that Dynamic growth can also dynamically
grow your bill and sometimes
your your I'll say it your architecture
your core solution is really not
designed for where they need to be so
start that earlier on that's one of
those things that they'll also often
pass off and you might even as well
because you don't want to you know start
spending that cost on them but find ways
to work into it and that's just an
example that being said I think that's
enough bonus material right now so we
will wrap this one up we'll come back
next time maybe a part three and maybe
not we haven't really talked about that
yet uh as always we're just figuring
this out as we go but as you know there
we could spend days and we mean not just
us but all of us the greater develop or
Community here could all spend forever
talking about all these little headaches
and gotas and all the little you know
War Stories from our careers whether
you've been doing it for a year or
hundred years 100 years would be really
fun to talk about I guess because your
technology was not the same then but
nevertheless uh one once again thank you
guys for your time I don't want to waste
any more of it go out there have a great
day we will talk to you next time around
[Music]