Live data from Hacker News

Deadlines and sprints are bad for you

medium.com

61–70 of 75 posts

Re: Deadlines and sprints are bad for you

#61
post #9

ok, 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.

so this means you have implemented scrum not efficiently.

if you work in an inverted pyramid where the team has autonomy (within boundaries) - scrum doesn't become a reporting tool it is for the team. since there is nothing else "above" the team.

The story points are a measure. That help your team to plan a sprint nothing else.

Re: Deadlines and sprints are bad for you

#62
post #13

I 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…

One point of contention for me is the dichotomy between the managers and programmers where one takes care of the "what" and the other the "how" in order to learn "when".

To find a solution within the constrains of this problem-space there need to be made tradeoffs that require creative thinking at every level.

I used to focus on technical work until I realised we where spending millions on projects that go nowhere.

Like in the Dilbert comics its ok for management to wast the time of the developer but a developer should not be allowed to wast his time. It may sound like a cop-out but its much more productive to be able to say, ever so politely, "no this is not something we are going to do".

Re: Deadlines and sprints are bad for you

#63

The 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_…

This is one of the reasons Scrum stopped using the word commitment in favor of forecast https://www.scrum.org/resources/commitment-vs-forecast Most people who say they are doing Scrum or think they are doing Scrum aren't really. Scrum is far from perfect but it's better than most of the bastardizations people invent for themselves when they claim to be doing it.

At some point if most people are following your framework incorrectly it might be time to acknowledge that the framework is hard to implement correctly.

If your proposal for fixing it is for people to try harder to do it correctly then you might have a bad framework.

Re: Deadlines and sprints are bad for you

#64
post #57

Earlier quoted context omitted.

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.

If story points are fictional then that's not the fault of the process, it's the fault of the person who made the estimation. If you've been working as a developer for any length of time, you should know roughly how long a particular task is going to take you.

I know how long it takes me to accomplish a task given spherical cows. Since nothing is stable (test environment, content, other fires), the story points are irrelevant.

Re: Deadlines and sprints are bad for you

#65
post #61

Earlier quoted context omitted.

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.

so this means you have implemented scrum not efficiently. if you work in an inverted pyramid where the team has autonomy (within boundaries) - scrum doesn't become a reporting tool it is for the team. since there is nothing else "above" the team. The story points are a measure. That help your team to plan a sprint nothing else.

No true scotsman. If everyone is working efficiently, why would the team need another layer of overhead to do the job they are already doing?

Re: Deadlines and sprints are bad for you

#66
post #7

Earlier quoted context omitted.

> Sprints are about accountability This, so much. If you're missing sprint deadlines, its not necessarily a personal failure as much as a process failure. The solution is to commit to less, to refine your items of work so they can possibly be met in the time you expect. For this to work though, there has to be buy-in from the team members: you can't force it on them. I've also found that the somewhat artificial sprin…

> If you're missing sprint deadlines, its not necessarily a personal failure as much as a process failure. Is this true? I was watching a talk from James Coplien the other day and he claimed 50%. That seems extreme. https://www.linkedin.com/pulse/scrum-evening-james-coplien-v...

The 50% is simple math. If your velocity is V, you take V estimation points of work into the Sprint. V is a stochastic variable with a mean and a variance. You rarely deliver exactly V points: it is just the mean. About half the Sprints finish early, and about half the Sprints don't deliver everything on the Sprint backlog.

So this isn't about failure at all: a failed Sprint is one that fails to meet the Sprint goal. I suggest taking a Scrum class to learn how velocity works, how agile works, and to learn how to manage uncertainty (and if you don't admit to this 50% uncertainty, then you are lying to yourself and cooking the books) and to learn about Sprint Goals.

Your post suggests that you understand none of these things. They are all Scrum basics.

Re: Deadlines and sprints are bad for you

#67
post #60

Earlier quoted context omitted.

I used to dislike this too, mainly because they put the problem in your bucket. The solution is to not let this problem end up on your side. "We will see what we can do, but since we didn't make any estimate on this, the risk of failing the deadline is on you. If you want to set a proper deadline next time for my team, consult me first so we can do a proper estimation. I hope it works out for you this time." I also h…

This isn't something you can get away with in many businesses (at least not in terms of the kind of businesses that would put you in that position to begin with) - and the few you can do this, it's not something you'd want to do frequently because you can end up being seen as an obstruction and that ultimately works against your interests. I've found it's better to work with them on a compromised phased released / MV…

> you can end up being seen as an obstruction and that ultimately works against your interests.

I always worked in small companies If you are the competent software engineer that always delivers quality software, and is always pushing the company towards a better and more progessional way of working, you will not easily be seen as an obstruction. I never was, and always had good to excellent reviews.

A sales person that sucks a deadline out of their thumb is in no way to be seen as professional. Questions such as "who estimated this? Was anyone from software development involved? Did you account for testing? Do you expect the custommer to find all our bugs?" Etc, should reveal that there is another way of working.

I had a sales guy respond to me "I've been doing this for 30 years, so I know". This guy was fired half a year later

Sales people setting deadlines without consulting the people that need to do the work, is very unprofessional, and there is no way that anyone can defend that. You just have to make this very clear, in a diplomatic but clear way.

Re: Deadlines and sprints are bad for you

#68
post #60

Earlier quoted context omitted.

This isn't something you can get away with in many businesses (at least not in terms of the kind of businesses that would put you in that position to begin with) - and the few you can do this, it's not something you'd want to do frequently because you can end up being seen as an obstruction and that ultimately works against your interests. I've found it's better to work with them on a compromised phased released / MV…

> you can end up being seen as an obstruction and that ultimately works against your interests. I always worked in small companies If you are the competent software engineer that always delivers quality software, and is always pushing the company towards a better and more progessional way of working, you will not easily be seen as an obstruction. I never was, and always had good to excellent reviews. A sales person t…

It sounds like we’ve had very different experiences but from what I’ve seen I think it depends more on the management / CEO than the company size. Some of the smaller companies I’ve worked for have been worse than any of the larger companies and that was entirely down to the fact that the CEO saw the sales team as the money bringers because they scored the lucrative deals, where as the engineering team were seen as replaceable work horses.

But as I said, the best thing you can do in those sort of places is take the money and move on because you aren’t going to change the CEO’s attitude.

Re: Deadlines and sprints are bad for you

#69
It's like someone that's never painted in their life giving estimates on how long it'll take to paint the interior of a new house based on the total width of all brushes that'll be used and the total area to be brushed. Even if it's small and you'll have a lot of brushes, there could be lots of detail work because of windows/doors/etc.

Who would have a better idea? Probably someone who knows how to paint.

Re: Deadlines and sprints are bad for you

#70
post #68

Earlier quoted context omitted.

> you can end up being seen as an obstruction and that ultimately works against your interests. I always worked in small companies If you are the competent software engineer that always delivers quality software, and is always pushing the company towards a better and more progessional way of working, you will not easily be seen as an obstruction. I never was, and always had good to excellent reviews. A sales person t…

It sounds like we’ve had very different experiences but from what I’ve seen I think it depends more on the management / CEO than the company size. Some of the smaller companies I’ve worked for have been worse than any of the larger companies and that was entirely down to the fact that the CEO saw the sales team as the money bringers because they scored the lucrative deals, where as the engineering team were seen as r…

Changing the CEO's attitude is indeed impossible, even with multiple people that he respects.

If you are seen as a replaceable work horse, you lose a lot of leverage indeed.

Here in Belgium there is a huge shortage of software developers, which places the programmers in a stronger position than the companies.

I can leave a company and instantly get the same or a higher pay somewhere else.

A company on the other hand, first has to find somebody, and then still overpay the first few months before the new employee becomes productive. From that point it's a bad position to be in.

Post reply on HN