Deadlines and sprints are bad for you • Hacker News Board

Re: Deadlines and sprints are bad for you

#11

Post by mpweiher » Sat, Mar 09, 2019, 7:35 PM UTC

spenczar5 wrote: post #5

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

> If your answer to them is "I can't tell you, we just do stuff on the kanban board and don't think about deadlines," they're (1) going to be less than thrilled with you, decreasing trust, and (2) unable to make their decision effectively.

I think the point is that if you do make those commitments you are just making things up, in reality those commitments are worth pretty much exactly as much as not making the commitments.

Where with reality I mean the actual physical reality. I realise that social reality can be different, and even a commitment that you make despite everyone knowing that you don't actually have any basis for making that commitment (no track record, no reasoning, no nothing...) can be valuable.

Re: Deadlines and sprints are bad for you

#12

Post by zdragnar » Sat, Mar 09, 2019, 7:57 PM UTC

doctorpangloss wrote: post #3

zdragnar wrote: post #2

Kanban is appropriate for maintenance work, but I don't know of too many companies that will invest in a project without at least a general idea of "when will it be done?" and "how much is it going to cost to complete?" Sprints are about accountability. Estimates are supposed to change based on new information, the understanding being that things change- priorities, desired outcomes, designs, sick time, and so forth.…

> management's expectations are simultaneously deadline, cost and feature driven. There is no management technique I suppose when the product you're making is, say, advertisements, because you merely arbitrage, you can satisfy all of those at the same time. The more interesting point of view is, "The kinds of software businesses you want to get into require no management at all."

It is entirely reasonable for management to set an expectation for two of the three between deadline, cost and features. The whole point of agile, as I understand it from "Uncle Bob", is that as professionals, developers are expected to provide information and guidance based on their professional opinion. Not only does agile help ensure accountability, but also acts as a continuous feedback cycle for developers to provide new context, information, and ideas as they surface.

I did in fact work at a company that was something of a dev shop for marketing agencies, and it was pretty miserable at times, because they inevitably expected contracts that held to all three. Cost was typically the one thing we could get them to budge on as new information came up (i.e. this necessary feature wasn't accounted for) though who actually ate the cost depended on negotiations.

I don't think I would enjoy working in a business with no management at all, to be honest. There are things that I am good at, and there is a definite perspective from which I view things, and the same applies to good managers, and there is not a complete overlap between the two. On top of that, they deal with problems that, often as not, I'd rather not have to worry about.

Re: Deadlines and sprints are bad for you

#13

Post by kerpele » Sat, Mar 09, 2019, 8:34 PM UTC

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 work can be influenced, namely project/product management. They should then, completely independently from the development team, adjust the backlog and/or deadlines in case the project schedule starts to slip. If the deadlines are needed because there are doubts that the dev team is not working as hard as they reasonably can then there are bigger issues that any project management method cannot fix.

Re: Deadlines and sprints are bad for you

#14

Post by rileymat2 » Sat, Mar 09, 2019, 8:37 PM UTC

pm90 wrote: post #7

zdragnar wrote: post #2

Kanban is appropriate for maintenance work, but I don't know of too many companies that will invest in a project without at least a general idea of "when will it be done?" and "how much is it going to cost to complete?" Sprints are about accountability. Estimates are supposed to change based on new information, the understanding being that things change- priorities, desired outcomes, designs, sick time, and so forth.…

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

Re: Deadlines and sprints are bad for you

#15

Post by sklivvz1971 » Sat, Mar 09, 2019, 8:40 PM UTC

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_ over time. They learn how to estimate better, and having a fixed "box" to fill is a very easy way to do so.

So: Scrum is a "scientific" way to reach a sustainable pace ("scientific" meaning: based on objective, repeated measurements).

This is not to say that Kanban does not work. It's just way way harder to do right, because measurements of how good a team is at having a sustainable pace are not as intuitive and are easy to ignore for teams -- and ignore it they do, unless they are very well disciplined.

But all of this is well know in the world of Agile, I remember talking about this ten years ago. Perhaps an agile coach would truly help this person.

Re: Deadlines and sprints are bad for you

#16

Post by jarl-ragnar » Sat, Mar 09, 2019, 8:41 PM UTC

je42 wrote: 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/...…

I was astounded to watch in one organisation while the Software Eng. Manager talked in terms of sprint failure and turned it into a performance issue. That resulted in all sort of unintended consequences.

Re: Deadlines and sprints are bad for you

#17

Post by wwarner » Sat, Mar 09, 2019, 8:44 PM UTC

dasil003 wrote: post #4

Something I've learned in startups is that you've got to have immediate short-term goals and keep pushing towards them relentlessly. In bigger companies with stable revenue the natural sense of urgency is lost, and you can often spend endless time in analysis paralysis or perfecting inconsequential details. Having milestones and deadlines in whatever process you choose to implement is very important to keeping everyo…

Exactly.

Re: Deadlines and sprints are bad for you

#18

Post by lima » Sat, Mar 09, 2019, 8:45 PM UTC

spenczar5 wrote: post #5

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

No, the idea is that you don't set hard deadlines for the team - they're pointless. It results in unnecessary stress and work won't get done any faster (maybe in the short term, but it's unsustainable).

Either the deadline is too short and your team has to work overtime, or it was too generous and you lose efficiency.

The project manager, of course, still needs to be able to make an estimate according the his team's velocity, which he can then communicate to other business divisions.

See: https://apenwarr.ca/log/?m=201712

Re: Deadlines and sprints are bad for you

#19

Post by Terretta » Sat, Mar 09, 2019, 8:52 PM UTC

lima wrote: post #18

spenczar5 wrote: post #5

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

No, the idea is that you don't set hard deadlines for the team - they're pointless. It results in unnecessary stress and work won't get done any faster (maybe in the short term, but it's unsustainable). Either the deadline is too short and your team has to work overtime, or it was too generous and you lose efficiency. The project manager, of course, still needs to be able to make an estimate according the his team's…

In fact, Scrum changed the word “commitment” to “forecast”.

https://www.scrum.org/resources/commitment-vs-forecast

“One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it.”

Pretty sure the Scrum folks are aware of needs of enterprises and their deadline addiction.

Re: Deadlines and sprints are bad for you

#20

Post by zdragnar » Sat, Mar 09, 2019, 8:58 PM UTC

rileymat2 wrote: post #14

pm90 wrote: 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...

If a task cannot be completed within the timeline of a sprint, one of two things are true:

1) The task was not correctly estimated; it is discovered during the sprint that more effort than originally thought is needed.

2) Work that was not accounted for during sprint planning reduced your capacity; things like ad-hoc or unplanned meetings, sick time, peer and code reviews, HR processes, bugs from previous sprints, and so forth.

In both cases, the plan that came out of "sprint planning" does not match reality. I don't consider this to be a failure at all. How people react to it can be wrong, however. "Just get it done anyway", failing to inform team leads / managers when the change occurs, etc are unhealthy, because it creates a disconnect in expectations among the team due to either conflicting understanding of the work being done, or changes in expectations about capacity required.