one of the things about the waterfall model is that usually the time period is pretty long there is kind of like a steady pace for a long period of time before it ramps up close to the release date right as you get close to release you go like oh this huge pressure we got to deliver deliver deliver we going to you know late nights and sting up there have been a lot of late nights where I've kind of like stayed all night at office and gotten something done you know things show up at the last
minute there are bugs that need to be fixed lot of panic but the Panic kind of has a crescendo right it goes at the very end there's a lot of panic but then for the most part you it's steady you have a plan you execute on the plan it's a longer term plan right the problem with the waterfall model is That You Don't See issues up until the very end right the late nights happen for a reason because you know there are problems those bugs were there in the code for a long period of time
but you don't see it until you actually get close to the release or the deployment or whatever that is with scrum you get this what they call a Sprint right you get these small Sprints that you got to keep going and keep going and keep going and it's almost like you have a waterfall every week right the problem is that the cresendo that you have is kind of split into in an ideal world that Rush at the very end in the case of a waterfall is split into smaller Rush at to deliver at the end
of every week but usually what ends up happening is that it's not like a you know it doesn't equally distribute if you sum up all the you know rush to deliver for a scrum it's going to add up to be more than the one time you know rush to deliver that you would have for a waterall programming today is stressful way more stressful than I remember in the '90s and early 2000s when I was just starting out back then things would get crazy around deadlines but at other times I recall feeling pretty even this is
what I'm talking about right as you get close to the deadline you basically have this panic and rush to to do things these days however the pressure seems omnipresent naturally I'm interesting in doing away with this feeling of pressure for the sake of my health as well as my productivity so I've given a fair bit of thought to why things have gotten so bad at least for me if not for others in the last couple of decades I don't think it's due to stiff competition shifting markets or even tight deadlines they have always existed but
one significant change that has occurred in my daily work routine I've been forced to start working in Sprints usually one to two weeks instead of spending larger chunks of time on larger projects this shift has some unfortunate consequences why would Sprints be more stressful this is how Sprints are doing us wrong Sprints never stop see this is the thing that I was talking about right with the waterfall you start out slow and you kind of has this Crescendo it goes up to the release when you go to the release you panic late nights all that
stuff and nothing you you celebrate right you go on a vacation and then gradually start up but Sprints you have smaller panics every week okay ideally I think this is what the thing is the scrum and the agile thing says you shouldn't have this ideally it should be a straight line okay you shouldn't have to rush at the end of the week or the at the end of two weeks if you're panicking and you're not able to deliver what you were committed to deliver at the end of those two weeks that means that you didn't
plan right you didn't estimate right which is fair but the reality is nobody does software estimates right you just cannot estimate right because estimation is basically guess work here's the thing you should know about me okay there's nothing that you should know about me but I would like to share about me I'm very very bad at estimating I'm horrible at estimating right when throughout my career when a manager has come to me and asked Kosik estimate this for me I'm like I don't know how to do this I cannot guess and basically I have to
guess right estimation is all about guessing the thing is when you have um like assembly line work right you're doing the same thing over and over and over again it's very easy to estimate you know exactly what you need to do you say okay I've done this before it's going to take this much time but when you have like you're doing something for the first time how can you even guess how much time it's going to take you can in the true sense of estimate you can estimate it but that's not how estimates are considered
estimates are considered as you are going to do this at this time right that's what estimates are going to be for it's like this is the amount of work that you're going to do and guess what they're going to do right this is what most companies do you're going to estimate what work is going to happen in the next week and you're going to estimate what work is going to happen in the next week so you better complete this because guess what there's work packed for the next week that you need to do and if
this slips then this slips as well so that's the reason why you can have this Crescendo where you have to get this done because there's a work plan and you don't want it to slip right when it comes to estimate that makes two of us hor well we guess what par we have company a lot of people are bad at estimates because I I firmly believe that estimates is just guesswork you're just guessing it's it's good for planning but when you're planning going by estimates is basically you assuming the best case scenario in my opinion
there is a chance that estimates could be wrong in both directions you could be estimating too much or you could be estimating too less and in either case you need to plan for it if you just estimate that it's exactly going to fit that's the best case scenario you need to estimate for both an overshoot and an undershoot so I don't know how many people do it but that's what need to be done 15 days Sprints do you think companies follow ail because I heard and experienced that ad hoc tasks keep coming this is true
well you you have to accommodate for ad hoc task and this is this is one thing that's good about agile and I hate about waterfall without waterfall you're going to have you you have this huge ceremony for doing anything that's different right you have with waterfall you start out with the requirements you finalize it any changes you're going to go through this committee people have to have meetings and stuff which sucks because that might have worked 10 years ago it's not going to work now you need that flexibility so agile gets its name because of
the agility part of it you have to be agile agile to changes so it's okay if new work comes in and if there is a good reason for it which is fine but then that means that you're going to go back here and you're going to change what you estimate right the problem is that that doesn't usually happen and that's where that's that's where it becomes a problem you know it's people don't like it don't like scrum kban is much better and gives freedom to developers yes so the thing with kban is you don't have
this thing anymore right you basically pick up what you can and then if you cannot it just goes over to the next thing so you're not packing up the next week or the next Sprint with work that needs to be done kind of assuming the happy path that you've covered everything in this thing so yeah I generally like kban as well I think that's a better that's a better approach in general try to complete 60 to 70% of the work and give and then give estimations to my manager well you going to have to do
it sooner right managers never want to remove task out of the Sprint at my last page no it's that's true this is a problem because you don't when changes happen you don't want to do it because again they would have packed work over here right or even the team you as a team would have packed work over here so you cannot say okay something new came in you this this cannot move so what happens this peak goes up because you're going to have to get you know a rush to get that done padding the estimate
by 20% becomes second nature yes yes here's what's funny though padding happens at different levels so it kind of becomes that's the reason why estimates kind of become a fars so usually the manager asks for an estimate and then the manager has to report to their supervisor right in my experience that's what happens the manager pads 20% the developer is like okay I I know that the manager is asking and I need to cover my behind so the developer pad's estimate so it's like 20% here and then 20% there and 20% there and the problem
is in spite of that we end up missing estimates so often which means that we suck so much at estimating that even with all this extra padding we we have this right that tells us how bad we are at at estimations in general so it's it's pretty bad I want to get back to the thing because this is an interesting idea so you complete 60 to 70% of the work and then give estimates isn't that already too late you estimate at the beginning of the Sprint so if you if you need to cover 60% of
the work then you're probably covering half of the Sprint already so how does that I don't understand how you do this but anyway this is the problem with the scrum model right this is this is what ends up happening while waterfall causes higher spikes and stress or hit this share quote things I'm just going to switch to the reader view while waterfall causes higher spikes and stress Sprints impose a more constant medium level stress the difference lies between higher short-term stress and medium long-term stress while no stress is entirely comfortable our bodies are better equipped
to handle short-term stress I I see what this person is the point that this person is trying to make because you have um you have a stress response in our body right we have a stress response when when we experience stress mental or physical our body goes through a different you know it kind of goes through a different mode there are other things that the body prioritizes over longer term right let's say there is a deer in you know in a lake drinking water and then there's a lion coming to to hunt for food right
what happens in the deer's body at the time is it's not looking for longer like sustenance right it tries to kind of switch gears to more survival at the time okay so at the time probably the digestive system doesn't get enough attention from the body blood flows to the limbs it tries to run faster so it kind of it's not thinking longer term the body kind of switches to okay survival it kind of prioritizes different parts of the body so high blood pressure is one of those things right it kind of body increases blood pressure
during stress because it needs to provide blood to different parts of the body in order to help the organism to run we aren't running from lines but it kind of triggers the same stress response so maybe that's kind of what this person is saying right longer term stress is harder to deal with short burth of stress is okay Sprints are involuntary if a development team were to sit down and de decide to deliver code every two weeks based on a process of their own design one that makes sense to them and suited to their circumstance
that would be one thing but Sprints in a scrum like process don't work that way every aspect of a Sprint is prescribed it's duration its meetings its tasks even the roles of its participants you might think that choosing your own process wouldn't make much of a difference but research tells a different story autonomy the ability to direct Ono in work plays a significant role in how the work has experienced ideally scrum is supposed to be you're running from scrum Masters looks like scrum Masters are getting extinct right to use the the wildlife analogy nobody is
opting for scrum Masters anymore it used to be a thing 5 years ago but I don't think there are a lot of scrum Masters today teams are supposed to be self organized so yeah we don't have a lot of scrum Masters run away from we are our own scrum Masters which makes it even hard hard right it's worse try to complete 60 to 70% of development this pattern is helpful when I don't have a complete idea on what's what thing I'm going to work on or what challenges are going to occur it it is fair
it makes for better estimates because you kind of know what you've done so your estimates are always going to be accurate but I think you're going to have to kind of like preload the work right you're going to have to work extra hours at the beginning so that you can take it easy later and you can get a a good estimate so you know exactly what you're going to complete it's a good strategy but then in your case isn't the work like this it's basically this this Edge flipped right you start out with a peak
and then it goes down and then start out with a peak and then it goes down it's basically the same sort in the reverse order right you need to do that so that you can estimate on time it's still if it works it's it's good it's good it's a good way to do it right there are still tons of scrum Masters in big companies and if you use safe it gets worse I have no idea what safe is then you can execute the plan ahead approach yeah I think it's if you can preload the thing
like move the stress up front I see the logic here I see the logic here if you're going to so here's the thing I see the logic in what you're saying my friend if if you're going through the stress anyway at the end of the Sprint why not go through the stress at the beginning get some idea about what it is that the work that you're doing give an estimate and then once it's done you can kind of take it easy because you know that you're going to get that thing done at the end I
don't know might be a good approach I've never tried it but might be a good approach if it if it works for you then for sure so here's the thing about deciding on a Model that works for the user right IIA mentioned about kban kban is one of those things kban is a model where you pick as much as you can you don't you're not committing to what you're going to get done at the end of the Sprint right you're picking what you can and if you didn't pick anything it basically kind of goes to
the next print like anything that you didn't pick kind of falls through you're not you're not committing to it the problem with kban is then it's hard to convey what value you're delivering to the stakeholders because the product manager is going to come to you and says tell me what I can get done in 2 weeks what can I release in 2 weeks if you're doing kban you still need to estimate what can get done even though you're not taking those things right even though you're not committing to delivering you kind of inovate committing so
that's what's going to be a problem no matter what model you pick it's you're going to have to do it safe as an agile framework built by by IBM built for Enterprise companies I guess in a way I'm glad I'm glad that I don't know what that is thankfully I don't know what that is but yeah agile framework that sounds like very agile I saw this post on LinkedIn somebody had like what are the things that you need to do Agile and it had this huge chard with all kinds of buzzwords agile framework all kinds
of buzzwords and I was looking at that thing going where is the coding in this thing what block represents the thing where you actually sit down and write code I spent like I don't know a few minutes I didn't find it and I gave up and moved on but it was like this huge that's what agile you know when I think agile framework that's what comes to mind yeah I'm glad I don't know what that is Alia if you're having to deal with that you have my sympathies Sprint neglect key supporting activities another stressful aspect
of SC Sprint in a scrum like environment is that they leave you feeling unprepared for the next task this happens because no time is set aside for proper engineering prep work there's far more to attask than simply typing out a solution you have to ideally you have to accommodate that in your estimation but again we bad estimators we don't accommodate them and we're going to have to do that in that in that Spike scrum fall the real and worse picture Okay ideally it should be a steady but then that doesn't happen as well so what
the author is saying is these spikes also go through the crescendo near the release this is the reality that happens which is which is really worse in this case you get the worse of Both Worlds stress level starts high and only escalates as the major release approaches this I feel is a problem that can be solved even with scrum because what you should be doing is you should be releasing often as well there shouldn't be a big release if you have a lot of Sprints for a release this can be solved ideally you do a
Sprint here release Here do another Sprint release here because you already have that tension you already have that stress at the time focus on a release and get something out that's what you should be doing so this I don't agree with if you're doing this if your organization is doing this this can be fixed just release often you already have that stress just push something out to production keep pushing out this the problem of waterfall is like this Crescendo happens only because we kind of hold on to a lot of changes and release it once
so all of those problems kind of happen at the same time and it becomes much more harder to deal with so if you're having this if you're doing this why even do this in the first place might as well do waterfall right so ideally what you should be doing is releasing at these points so this this I don't agree with for this article this is this is wrong this is an opportunity to fix but yeah so this is uh this is an interesting article that I found which is like this scrum stressing you out it
is yeah it stresses out a lot of people
