Deadlines and sprints are bad for you

Deadlines and sprints are bad for you
medium.com

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

In a moderately large (say, 500+ employee) organization, deadlines are essential to get anything done. Suppose, for example, you're overhauling a billing system, making international tax calculations simpler. The finance team is making a hiring decision: they need to get tax stuff calculated before the end of the year; do they need to find consultants to help them with this, or is the software going to be ready in time?

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 don't think "there's only "stuff" to be done" is an adequate alternative to deadlines and sprints if it doesn't address the reason organizations use those tools. They're primarily tools for predictability and scaling outbound communication about progress; I think the author mistakenly believes they're supposed to be motivational tools. They're sometimes misused that way, for sure, but that's not the whole picture.

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 sprint goals do act as a good motivation for the team to help each other if they see that the goals might be missed.

There's also the part where you have to be continuously getting feedback and tweaking the ways in which you run the process based on the feedback. If team members feel that this is just another unresponsive management tool designed to get them to work more, it will fail miserably. Instead, if they see it as a construct to provide accountability to stakeholders, they will strive to change and improve the process until it works well.

Ultimately though, the key feature seems to be: the people. If you're not working with a team that's genuinely interested in accountability and helping the product succeed, this process will not work. These are high-trust, highly nimble processes which are completely inefficient if they are actively sabotaged or the promises of good-faith expectations are violated.

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

> How much effort goes into each task?

"how large is the story compare to other stories we had before?" is a better question.

Refinements are a crucial meeting to keep the team aligned and make sure they can collaborate on user stories and help each other.

> How many sick days are there going to be in the sprint?

you don't plan for that.... you only plan for things you know in advance (vacations etc. ) Capacity planning takes less than 5 mins in our sprint planning. not sure where the problem is.

> Is someone leaving or joining the team?

Yep, very important to discuss. in any context (regardless if you do SCRUM or something else).

> people end up confusing sprints to deadlines

End of sprint is a deadline according to definition:

> the latest time or date by which something should be completed.

Because the team thinks it can complete the sprint's stories by the end of the sprint.

It is important to deliver value to customers in a timely manner. This is to lower the risk and prevent multi month/year projects that never go to production, etc.

Sprints help you with structuring your process to achieve this goal. Please keep in mind, this doesn't free the team from thinking how to get the value to the customer as soon as possible. (You can have sprints and never go to prod...)

> trigger the fight or flight response

If you have people in the team that have that kind of reaction ? Talk about it in a retro, and improve.

SCRUM requires a "save" environment, if you don't have one, almost no sane process will work.

if you don't meet your sprint goals. talk about it in the retro and improve as a team.

Consider, pulling in experience good SCRUM master's the good one's can help how to improve your procceses.

One thing to keep in mind, if the SCRUM is only a thing of one particular department and/or is not fully accepted by the CEO and board, you have some side effects where situations can be quite disappointing and stressful.

however, the scrum master and PO can help sometimes in these situations. If they can't the SCRUM process will be bypassed by people outside (like the CEO) and hence it undermines the process and makes it less effective.