Just read title. Me neither.
I don’t believe in sprints
421–430 of 459 posts
Re: I don’t believe in sprints
#422This 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…
May be a strawman, but his frustrations are real and I share his sentiment.
Sprints et al have been a mixbag for me, but the last 7 yrs (current team) have been plain utter BS. All the ceremonies too, retros are nothing but waste, because they only serve to praise undeserved credit with no product to show for most of that time period.
I credit the OP for his courage to raise his voice to shame those/any bullshitters behind the Agile movement.
Re: I don’t believe in sprints
#423Earlier quoted context omitted.
Testing should occur within the same sprint as dev where possible - if you're throwing all work over a fence to a distinct QA team, you're doing it wrong. If testing in "real time" is not possible for some reason, the following sprint should have testing support baked in as an explicit task. And, IME, sprints work well for mature products where there's a steady flow of defects and enhancements that are relatively eas…
“ if you're throwing all work over a fence to a distinct QA team, you're doing it wrong.” That’s how it works in an industry where product bugs can kill people. The devs do their own testing but there are large testing teams that take a deep look at at everything the system does.
Fair enough, that's why my second sentence is there. The scrum master/manager should be building in QA support. If they aren't, they'r failing at their job. A individual developer should never be put in the position of killing a sprint in order to support a QA team for work the dev team did last week.
Re: I don’t believe in sprints
#424Before sprints there was waterfall scheduling at the project level: requirements, design, development, testing, delivery, and maintenance. Often tasks would be late and delays would propagate resulting in the old adage for estimating how long a software project would take: think of a an amount of time it should take, then to get the actual time, double the number and then change the unit to the next longer time unit.
Re: I don’t believe in sprints
#425Earlier quoted context omitted.
> it's safe to say that this is not kanban But that's the problem with agile. Nobody can or wants to pin it down. When it fails, "you are not doing it properly". The stated goals are iterations, early feedback, people over processes... except when they aren't.
Hum, no. If you go calling some infinite WIP generating process by the name that has as the one most important principle "no matter what you do, keep WIP down", it's you that are bastardizing the language.
> Hum, no
Um, yes.
I'm sorry, but the "Agile works, it's just that you are doing it wrong" line of argument is weak and unconvincing. The theory of a methodology means little when there is no buy-in from stakeholders, as is often the case. They reinterpret it to mean whatever they want it to mean. If you haven't struck this wall, then congrats! Most of us in software have to deal with it, though.
Re: I don’t believe in sprints
#426Earlier quoted context omitted.
In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.
How does something like this take 30% of your time? On my calendar it's two hours out of 80, or 2.5%. One hour per sprint for planning, one hour for retro, why would it be longer? My team lead spends more time prepping tasks with the PM prior to sprint planning, but even then it's about 5%. My last company, we had one-week sprints, but we didn't do official retros, so it was still 2.5%, one hour of planning for 40 ho…
Sprint planning today took 26 minutes.
The Retro yesterday was 30. So that's less than 1.25% of my time spent.
Re: I don’t believe in sprints
#427Earlier quoted context omitted.
And... in my experience, 'sprints-point-cards-planning-estimating' can also be a recipe for having the team on a constant death march to burnout. Doesn't mean it always is, but... find what works for the team. Let the team decide. I'd go further and say "let the people doing the bulk of the code work make these decisions first". Make process adjustments after some baselines are established to see if those adjustments…
Agreed, but is anyone arguing that the team shouldn't decide?
Being the person to say "let's stop doing X and do something different" has generally not served me well in team settings. Whether or not others on the team agree or even care, they often don't want to be vocal about stuff, and would rather just punch in and do some work and go home.
The psychology around "team decisions" is a weird one, and I don't think there's always as much 'group buy in' or consensus as people might think.
Re: I don’t believe in sprints
#428Earlier quoted context omitted.
> if they were ever aware of it This is my biggest pet-peeve on my current project. I am a solo dev on my current project at work, and for some reason, we are still choosing to use agile/scrum with sprints and all that jazz (seriously, your guess as to why is good as mine). Regardless, one of the more difficult issues I have encountered through out my current project is the usage of proper abstraction and avoiding re…
> Since, everything is given to me in sprints, I literally have no idea what is coming down the pipes. So you literally don’t know what the end goal of your project is? I would say then definitely not a “self organised” team, or in a sense, you’re not in the team?
> So you literally don’t know what the end goal of your project is?
I know the end goal of the project in a general sense (like any other CRUD app), but I do not know what is takes to get to the end nor when the project will be considered finished. I'm also the solo dev, and I've been working on this for almost a year now. I'm so stressed and burned out because of this bastardized process (not real agile, but my org's "agile"). I know the only way things will get better is to find a new job, but I seriously cannot muster up the willpower to improve my situation.
Re: I don’t believe in sprints
#429Earlier quoted context omitted.
> WIP Do you mind defining this?
"Work in Progress". "Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)
Thank you for the clarification, but I am afraid you lost me at this part:
> "Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)
What is "in flight stuff" and "traffic limits?" Are you saying strict Kanban minimizes the number of tasks that are in progress in order to prevent overloading the team i.e., there is an upper limit set to curtail the amount of simultaneous tasks?
Re: I don’t believe in sprints
#430Rich Hickey has a great joke about sprints, paraphrasing: So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon... Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.
Actually marathon runners are used to regular running. You might even skip the marathon and just run regularly. No need to be a superstar, just stay fit, with a steady progress. Same for software projects. Maybe the analogy isn't that bad.