31–40 of 459 posts
I rank them as 1) Agile 2) Waterfall 3) Whatever it is this guy wants.
The only thing that comes close is "every efficient and productive team I’ve worked on has ignored the concept of sprints altogether".
Okay, but why don't do scrum meetings, pointing, retros, or keeping Jira up to date, work. There's nothing in the article to address that.
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…
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…
Assuming you don't stop there and keep doing those things, I don't see why you don't like agile.
If not, then chances are the team will need some guardrails, that’s what agile and scrum offers. It’s a place to start.
Just because you don’t believe in having a system to break down work doesn’t mean it isn’t useful.
Personally, I’ve seen the alternative in action and it always leads to burnout.
This is nothing but a bad strawman from start to finish. Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability. This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and…
Also helps that companies love to employ clueless people to organize the sprints and those tend to care more for jira to look good, than actual work.
This is the fundamental reason why sprints exist.
If you exist in an environment where all team members are highly motivated, consistent, diligent, and pulling in the same direction then yes, sprints are a distraction, but it is my experience that teams that are genuinely like that are rare as hen's teeth.
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…
Producing effort estimates is one of the many approaches to start talking about a task, and not doing it may mean that somebody else's better idea on how to tackle it gets ignored.
Having sprints is a good way to coax people in fully finishing things, it is often needed as many developers tend to jump to the next shiny.
If any of these three things gets used by a bad manager to get fake importance, to put pressure, push people down instead of pulling them up... then get rid of that manager.
I agree with the title, but the article fails to deliver on the essence - saying "points are bureaucracy, backlog is bureaucracy" does not really say what is the problem, it does not explain what's an alternative to backlog that helps to solve the same problem (visibility of the work to be done, predictability, etc.) For me the biggest problem with sprints is that they force a continuous flow into discrete boxes. An…
Why do you need visibility and/or predictability? I would say Steve Yegge's classic Good Agile, Bad Agile gives the answer - Kanban (or, more informally, a work queue).
Because someone's paying you to do stuff, and they might like to know what's happening. The incredible rush of money into tech in the 2010s might have given the impression that that isn't a thing, but it is, and teams that can't self-manage (including giving visibility and predictability) are going to become encumbered with more and more people managers to compensate.
What they should be doing is understanding their role, making sure it's fulfilled, and then taking that cash that would be spent on managers and spending it on engineers instead. But that won't happen if they can't communicate, or can't even see a need for communication.