I don’t believe in sprints • Hacker News Board

Re: I don’t believe in sprints

#251

Post by mobiuscog » Wed, Oct 05, 2022, 1:49 PM UTC

denton-scratch wrote: post #238

amadvance wrote: post #158

I'm frankly puzzled how SCRUM sprints are even expected to work with a development + QA cycle. When a sprint starts, what QAs people are expected to do ? When the developers finish, and QAs start testing, what developers are expected to do ? It seems to me that this forced synchronization is just pointless and harmful. Where I work, we handle "sprints" just like checkpoints. This is in developing stage, this is in te…

> When a sprint starts, what QAs people are expected to do ? Dedicated QA folk are redundant! The devs write automated tests for all the code they submit. It's 20 years since I spotted a dedicated QA person in the wild.

And then the tests are slowly scrapped to get the CI/CD build time down to 'seconds'. Who needs tests anyway, right ?

Re: I don’t believe in sprints

#252

Post by manmal » Wed, Oct 05, 2022, 1:49 PM UTC

dbingham wrote: post #241

(Sigh) This is just a religious pronouncement in a religious war. There are many processes out there - not just sprint, kanban, water fall, or "no process". Pick the process that works for your team. As an engineer and an engineering manager I have worked in strictly controlled water fall, "no process", well structured sprints, kanban, and scrumban. They all have their pros and their cons, their costs and their benef…

> I developed a preference for scrum style sprints as both an engineer and as a manager, because I prefer to work collaboratively where everyone knows what everyone else is working on and everyone gets a chance to have a say

Are sprints necessary for knowing what other people are working on, and for having a say? I thought sprints are only tangential there.

Re: I don’t believe in sprints

#253

Post by rs_rs_rs_rs_rs » Wed, Oct 05, 2022, 1:50 PM UTC

I am surprised at the fact that there's so many PMs on Hacker News

Re: I don’t believe in sprints

#254

Post by robotsquidward » Wed, Oct 05, 2022, 1:50 PM UTC

robotsquidward wrote: post #244

https://ajkueterman.dev/posts/make-the-thing-better/

Actually another similar post on the front page at the same time: https://bigthink.com/progress/pessimism-is-a-barrier-to-prog... It has a great opening line:

> PESSIMISM SOUNDS SMART. Optimism sounds dumb. It’s no wonder, then, that pessimistic messages hit the headlines, and optimistic ones hardly get a middle-page snippet.

Re: I don’t believe in sprints

#255

Post by layer8 » Wed, Oct 05, 2022, 1:50 PM UTC

BirAdam wrote: post #13

Personally, I never liked agile. I like to get a description of a problem. Prototype. Take that to that customer and ask for feedback. Iterate. QA. QA. QA. Release. Thing is, much like governments, these models all fall short because people aren’t great. I think that if agile isn’t working for a team they should try another method, and if agile does work for a team that’s fantastic. People, imho, shouldn’t blindly fo…

If you look at the actual agile manifesto, I don’t think your view is in conflict with it: https://agilemanifesto.org/

Re: I don’t believe in sprints

#256

Post by ngrilly » Wed, Oct 05, 2022, 1:50 PM UTC

"Sprints" are a very bad name, giving the impression that the team is always running, which is a bad for morale and quality. In reality, they are just "cycles".

I see them like CPU cycles, but for a team. They are a heartbeat keeping team members in sync. It's all about answering what's my next task when I'm done with the current one. If you I work alone, or in a very small team, with no external stakeholder, then I can answer that "just in time" and don't need cycles.

But if I work in a larger team and/or with external stakeholders, then it's not practical to do this "just in time", gathering everyone to decide what should be the next task, every time a team member completes a task. In that case, we need to batch the planning work. That's what cycles are for.

I agree with the author that too often the process feels unnecessarily bureaucratic, and I really dislike the "sprint" terminology, but I wouldn't throw the baby out with the bathwater. Cycles still have a purpose.

Re: I don’t believe in sprints

#257

Post by mgkimsal » Wed, Oct 05, 2022, 1:51 PM UTC

> side note: there are no crappy teams, only crappy managers

I disagree. There are, in fact, crappy teams. You might argue that it's a crappy manager that either allows that team to continue in its current form, or simply doesn't recognize that the team is crappy, and does nothing, but... there are crappy teams. There are combinations of personalities and skills that are simply not suited to solving the problem at hand, and nothing short of removing actual people and replacing them with different people will 'fix' anything. Again, you can say that's down to management, but it feels like a word game. The team itself is 'crappy' for the goals at hand - management/owners (crappy or not) need to recognize and fix that.

Re: I don’t believe in sprints

#258

Post by patrickserrano » Wed, Oct 05, 2022, 1:53 PM UTC

stingraycharles wrote: post #24

gbro3n wrote: post #11

Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2…

Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines). Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses…

At a past job for a while we did Kanban with the sprint as a time box and it worked really well for the constraints we were working in. When we had work with deadlines, we'd flag that work as needing to be done in the sprint time box and put it on the top of the pile. Otherwise the team just kept picking up the next item, and we'd do a single review meeting at the end of the sprint to check in and see how everyone felt and what was accomplished. It was less of a retro and more of a temperature check.

It worked really well for a team that served a lot of different stakeholders and also had to field requests from customers since the priority of the work was always changing even if the deadlines for the work didn't.

Re: I don’t believe in sprints

#259

Post by throwaway4aday » Wed, Oct 05, 2022, 1:55 PM UTC

bkq wrote: post #2

I get the hate for sprints, and the bastardisation of agile. I think however, the root cause of this is the way in which our society as a whole has been modelled, in a top down manner where control is wrested from the bottom, and perceived control is given to those in between. Each of these articles that make, valid criticisms in my opinion, always makes me think of Bullshit Jobs [1][2]. Most of our lives nowadays ar…

I don't think hierarchies are necessarily bad, I just think that we tend to implement them in a crappy way where they become the playthings of people who are solely focused on gaming the system for their own benefit. Flat organization makes sense in small groups but that group still needs a leader who can act as the agent of the group when dealing with other groups. It's the representative democracy model which is needed when there are decisions that need to be made on scales larger than that of the group concerned. A leader can also and should act as a tie breaker and moderator when the group is divided or finds themselves unable to make a decision.

Problems arise when those leaders are unaccountable to the people that they represent, you need to have very strong customs and procedures in place that allow you to immediately recall the leader and replace them if they start acting in their own interest rather than the group's. This also requires the group to have good knowledge of what the leader is doing, transparency and a public record of the actions taken by the leader.

Re: I don’t believe in sprints

#260

Post by polynomial » Wed, Oct 05, 2022, 1:55 PM UTC

hurril wrote: post #208

rob74 wrote: post #112

Earlier quoted context omitted.

And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what…

My experience from my previous $work was that things never quite got completed. I really tried arguing for a more sprint-based approach but they didn't like what they expected to be undue overhead. I disagreed since ... well, you can't have a conversation about overhead if $thing is not even done, can you?

But what if it takes even longer to not do what we're already not doing?