But are they good for the COMPANY?
That's what matters.
Deadlines and sprints are bad for you
41–50 of 75 posts
Re: Deadlines and sprints are bad for you
#42The author deeply misunderstands Scrum. They also misspell it as SCRUM but that's another story... Sprints are timeboxes and not deadlines. Stuff is done at a "normal" pace and it either fits (or does not) in that timebox. Fundamentally, it does not really matter in itself. Noting down whether the estimation was correct or not, though, is important. The whole point is that a team is supposed to get more _predictable_…
As an aside, "sprint" (which obviously implies moving at the greatest speed possible for a human on foot, pushing themselves to a point which cannot be sustained for long distances) is pretty poor terminology for something meant to represent something happening at a sustainable pace. I'm sure I'm not the first or last person to point this out, though.
When I first heard the term “sprint” I thought it was surely being used so they could later make some point like “since sprinting is of course unsustainable, we introduce weeks of relaxation between them”... Nope!
Re: Deadlines and sprints are bad for you
#43ok, it looks like this guy has never worked in a working SCRUM environment. > Suggesting that meeting a sprint by cutting corners is a thing. Yes, in bad scrum implementations. SCRUM and KANBAN have both pro's and con's. If you can't implement SCRUM in a good way, you will also have a problem with KANBAN. There some good discussions about on online like https://fenix.tecnico.ulisboa.pt/downloadFile/3779576751814/...…
There's nothing about the scrum process that helps me, as an engineer, to work more efficiently. I work at the same pace regardless of what fictional story points are assigned to a task. The entire charade is only for middle managers to communicate up the chain what is happening. Velocity can be massaged so easily that it is a useless metric.
Re: Deadlines and sprints are bad for you
#44Earlier quoted context omitted.
I'd simply say that if something isn't ready, then as a general rule, don't make decisions as though it will be ready at a particular time in the future. For instance, buying a home thinking that a new highway will be done around the time you move in could lead to multiple years of disappointment. Voting to allow your city to provide substantial financial incentives could enable the builder to go to extraordinary len…
If you run your businsss like this you will be outcompeted by people who make reasonable guesses on when things will be completed
[deleted]
Re: Deadlines and sprints are bad for you
#45The author deeply misunderstands Scrum. They also misspell it as SCRUM but that's another story... Sprints are timeboxes and not deadlines. Stuff is done at a "normal" pace and it either fits (or does not) in that timebox. Fundamentally, it does not really matter in itself. Noting down whether the estimation was correct or not, though, is important. The whole point is that a team is supposed to get more _predictable_…
As an aside, "sprint" (which obviously implies moving at the greatest speed possible for a human on foot, pushing themselves to a point which cannot be sustained for long distances) is pretty poor terminology for something meant to represent something happening at a sustainable pace. I'm sure I'm not the first or last person to point this out, though.
I like to call them "strolls" :-)
Re: Deadlines and sprints are bad for you
#46I think the author misses what the purpose of deadlines is. They are contracts between organizations for when software will be available, which are used for other organizations to make informed decisions without needing very tight and constant communication. They're analogous to SLAs in service-oriented designs. In a moderately large (say, 500+ employee) organization, deadlines are essential to get anything done. Sup…
An even simpler way to put it: I have $1,000,000 in the bank. I have 10 engineers. If we don't make at least a break-even income in 6 months I have to fire 10 engineers. So you have 2 months to build something so I can spend 4 months hyping people up to buy a bunch of it or we close down. And I know your engineer asses ain't gonna write bug-free code.
This is the only deadline which matters.
Re: Deadlines and sprints are bad for you
#47Arbitrary deadlines are unnecessary when there are better ways to manage progress.
You can adopt the product delivery point of view and track progress on something like Kanban board. You track actual deliveries of actual items when they get done and on each time box (eg. 14 days) you open the board and try to understand blockers by looking at kanban columns where items are piling up. If a column grows beyond certain size (work in progress) you should start investigating the reasons evsn sooner. This way you either keep delivering or not and in that case you use periodic sprint meetings to understand why not.
Unfortunately what happens in organizations is that over time the organization based on tracking progress of delivering items or products shifts to tracking work or time workers spent working.
So on periodic 14 day meetings instead of asking questions 'why hasn't this item been delivered yet?', 'what is blocking the progress in delivery?' or 'why are these items piling up in that column?' you get question like 'what is everybody doing and what they plan to do?', ie. typical status report and micromanagement.
The focus shifts from items delivered to work done by people. As the team then loses focus, managers start to impose deadlines.
It is another case of treating symptoms instead of looking at the causes.
Re: Deadlines and sprints are bad for you
#48I think the author misses what the purpose of deadlines is. They are contracts between organizations for when software will be available, which are used for other organizations to make informed decisions without needing very tight and constant communication. They're analogous to SLAs in service-oriented designs. In a moderately large (say, 500+ employee) organization, deadlines are essential to get anything done. Sup…
Also, there's a theory that projects take the time you give them.
There are some deadlines that are too short that can't be hit, but if you have a project your team has done before in 4 weeks and give them 8 weeks, it'll take 8 weeks. The reason is it can always be improved. There are always more edge cases and more automation that can be added. Plus, many people would gladly work at half speed rather than full speed if the outcome was the same (daily compensation, praise, success, etc.).
Re: Deadlines and sprints are bad for you
#49> The tools the development team has for combatting the deadline are unsustainable
This misses the key power of the dev team in Scrum - to say "no":
"Can you do that quicker?" No.
"Can you cut corners?" No.
The dev team may not be able to change features or scope, but they absolutely can tell the product owners to either change things, or accept what the dev team says they can do in the allotted time.
Re: Deadlines and sprints are bad for you
#50I completely agree with this article. I've worked in scrum and kanban teams and also lead both kinds at some point. To me kanban is by far the better option for the exact reasons outlined in the article. The point is that deadlines are bad for the people doing the work when they can't influence the amount of work. Not that deadlines should be removed completely, but they should be moved to a level where the amount of…
I find it interesting that in other building projects, like in construction, almost all of the pressure and responsibility for meeting deadlines is placed upon the project management. Not the ones doing the direct labor.
The reason for deadlines in software, they way they are used today, is simply to get more hours out of a week from a software developer. Unlike in construction, software developers do not get paid hourly, nor do they get overtime pay. Abitrary micro deadlines coerce developers to work extra hours which makes their cost per week for amount of work to go down.
In construction, if they made up an arbirary micro deadline that was too short, the workers would get overtime pay at 1.5x their normal rate. Plus the additional hours. So for them, a too short deadline makes their cost per week for amount of work to go up.
We debate endlessly about all these estimates becase we're all pretending its about things that its not. Its almost completely based upon getting more hours per week per developer, as it makes the labor less expensive.