6 ms·

Why sprints are taking the joy out of building software

tomrod 2y ago
I actually quite enjoy the sprint structure. I have a hard time keeping long term focus on my projects, whether side projects, daily drivers, or point of spear. Sprints work well for my planning cycles and keep me hyper focused.
- xedrac 2y ago
  Sprints incentivize both good and bad compromises. Without some time pressure, some developers may go after interesting things that aren't necessarily in the company's best interest. With time pressure, tech debt tends to pile up, and corners get cut, documentation and tests get neglected etc... Personally, I will never again work for a company that does the 2 sprint with daily stand-ups. I am way less productive when I'm being shamed on a daily basis for falling "behind schedule" on some task that ended up being more complex than first glance would suggest. You may say "But that's not scrum!" Of course it isn't, but it is very often how it gets implemented.
heroprotagonist 2y ago
"So, we sprint, and we sprint, and then we sprint again. When do we rest?" "The weekend. Sometimes."
- mewpmewp2 2y ago
  But weekends are part of the sprints, not inbetween them?
  - 1propionyl 2y ago
    Every single person who 1) I take seriously and listen to, and 2) is very into agile methodologies have all been very consistent in that: 1. A work week is 5 days. 2. A work month is 20 days. 3. These are the numbers you plan within. 4. If you work outside those limits that is a process failure. 5. Process failures in an iterative process lead to incorrect/bad feedback into subsequent planning/estimation, baked in over-optimism, burnout, and ultimately failure to deliver a product on time. 6. Don't work weekends. Doing otherwise and deliberately running your staff hot and into personal time seems pretty damn in violation of the spirit of: "Individuals and interactions over processes and tools"
CharlieDigital 2y ago
The absolute best work organization model I've seen is Basecamp's ShapeUp[0]. The structure it provides in organizing the discovery, design, development, and delivery process made for a very predictable cadence and enough focused time to feel like a dev team wasn't sacrificing (be it work life balance or code quality). It absolutely works and creates space to do meaningful work, learn, and experiment. [0] https://basecamp.com/shapeup https://basecamp.com/shapeup
kirykl 2y ago
It’s a terrible name for what’s supposed to be sustainable work pace
donatj 2y ago
I'm getting old, I've been doing this for going on 20 years, I've been doing this since before fad workflows were really embedded in the culture. They were around but not nearly as common. What we did then, and what we do now is what I will term "developer driven development". The developer picks up a task, often themselves, and works on it to completion. If there's a strict deadline, a PM might get involved, usually working directly with the dev(s) on the project. Other than that, the PM's job is largely just to watch over tickets. I don't get the draw. We've had Agile and Kanban pushed on us before, and it's never stuck. We never got anything positive out of it. It only ever had negative effects on performance. Is it just to help very poor communicators? People who can't be bothered to talk directly, so they need to waste everyone's time? We don't do meetings. We don't need them. If someone needs a status update, they ask the person working on it directly. Building software just isn't as difficult as these workflows try to pretend it is.
- kshahkshah 2y ago
  The most valuable process I’ve ever instituted as a manager is design review. Absolutely hammering a design has proven to me to be the best way to ensure people have absolute clarity on the end state and have thought through the flow, copy and other-than-happy paths through the software. “Grooming” is just breaking down things from there. Sprint planning is a formality. Ten-fifteen minutes. I guess my point is you’re right, the rituals aren’t important in a high context team. The work is really figuring out what you’re building. Like really really figuring it out.
  - RaftPeople 2y ago
    > The most valuable process I’ve ever instituted as a manager is design review. Absolutely hammering a design has proven to me to be the best way to ensure people have absolute clarity on the end state and have thought through the flow, copy and other-than-happy paths through the software. 100% agree. You can change a design on the whiteboard rapidly and with practice you can really eliminate a lot of problems with a relatively small investment of time. We just had one where a small group was stretching a bit in what they could take on, they ran into some issues and afterward commented "ok, I see what you're saying, we needed to work through that flow in more detail for a couple hours to avoid that week of pain".
coffeefirst 2y ago
The problem isn’t sprints. The problem is treating them like deadlines. Stop doing that. Treat anyone who does with derision. Without the pressure to make your stupid charts look pretty it’s just a two week planning cycle, and that’s fine.
randerson 2y ago
I've delivered many successful software projects on small teams without Agile or any other other formal methodology. At two separate startups this helped grow us large enough to hire new executives who promptly inflicted "Agile" on us. (As in a plethora of tools and processes and roles. Evidently they didn't read the manifesto). Agile sucked all joy out of the profession for me. Both times, development speed slowed, budgets soared, bugs went unfixed, and the teams lost sight of the big picture of what they were building. Yet the executives stood by their decisions because they now had a sense of visibility and control, not realizing the true cost of that.
moominpapa 2y ago
Does anyone else suspect that agile, whatever its stated intentions, has been coopted as a smokescreen for micromanagement? 20 years ago I worked on a large non-it related project that was slipping and I was tasked to call at the end of each day every team working on the project to ascertain the progress they had been made that day. It made me very unpopular as there was a tacit lack of trust in the process. Back then I feel, it just was not done to make skilled workers explain themselves on a daily basis. I suspect the younger generation have been cowed and normalised to a much higher level of scrutiny leading to creativity and joy being sucked out of the working day.
- nineteen999 2y ago
  A _suspicion_? Plenty of us saw it coming ...
cedws 2y ago
I hate sprints. Developers are not machines. We don't crunch through work like an assembly line worker. We don't work at a consistent rate. Sometimes, shit happens you couldn't possibly predict. Sometimes, you want to go work on something else for a while. Sometimes we can't accurately say how long something is going to take until we're half way through. I just don't understand the point of boxing yourself into a set of work for X weeks when you could just use Kanban and pick up/put down work when needed.

I actually quite enjoy the sprint structure. I have a hard time keeping long term focus on my projects, whether side projects, daily drivers, or point of spear. Sprints work well for my planning cycles and keep me hyper focused.

xedrac 2y ago
Sprints incentivize both good and bad compromises. Without some time pressure, some developers may go after interesting things that aren't necessarily in the company's best interest. With time pressure, tech debt tends to pile up, and corners get cut, documentation and tests get neglected etc... Personally, I will never again work for a company that does the 2 sprint with daily stand-ups. I am way less productive when I'm being shamed on a daily basis for falling "behind schedule" on some task that ended up being more complex than first glance would suggest. You may say "But that's not scrum!" Of course it isn't, but it is very often how it gets implemented.

heroprotagonist 2y ago

"So, we sprint, and we sprint, and then we sprint again. When do we rest?" "The weekend. Sometimes."

mewpmewp2 2y ago
But weekends are part of the sprints, not inbetween them?
- 1propionyl 2y ago
  Every single person who 1) I take seriously and listen to, and 2) is very into agile methodologies have all been very consistent in that: 1. A work week is 5 days. 2. A work month is 20 days. 3. These are the numbers you plan within. 4. If you work outside those limits that is a process failure. 5. Process failures in an iterative process lead to incorrect/bad feedback into subsequent planning/estimation, baked in over-optimism, burnout, and ultimately failure to deliver a product on time. 6. Don't work weekends. Doing otherwise and deliberately running your staff hot and into personal time seems pretty damn in violation of the spirit of: "Individuals and interactions over processes and tools"

CharlieDigital 2y ago

The absolute best work organization model I've seen is Basecamp's ShapeUp[0]. The structure it provides in organizing the discovery, design, development, and delivery process made for a very predictable cadence and enough focused time to feel like a dev team wasn't sacrificing (be it work life balance or code quality). It absolutely works and creates space to do meaningful work, learn, and experiment. [0] https://basecamp.com/shapeup https://basecamp.com/shapeup

kirykl 2y ago

It’s a terrible name for what’s supposed to be sustainable work pace

donatj 2y ago

I'm getting old, I've been doing this for going on 20 years, I've been doing this since before fad workflows were really embedded in the culture. They were around but not nearly as common. What we did then, and what we do now is what I will term "developer driven development". The developer picks up a task, often themselves, and works on it to completion. If there's a strict deadline, a PM might get involved, usually working directly with the dev(s) on the project. Other than that, the PM's job is largely just to watch over tickets. I don't get the draw. We've had Agile and Kanban pushed on us before, and it's never stuck. We never got anything positive out of it. It only ever had negative effects on performance. Is it just to help very poor communicators? People who can't be bothered to talk directly, so they need to waste everyone's time? We don't do meetings. We don't need them. If someone needs a status update, they ask the person working on it directly. Building software just isn't as difficult as these workflows try to pretend it is.

kshahkshah 2y ago
The most valuable process I’ve ever instituted as a manager is design review. Absolutely hammering a design has proven to me to be the best way to ensure people have absolute clarity on the end state and have thought through the flow, copy and other-than-happy paths through the software. “Grooming” is just breaking down things from there. Sprint planning is a formality. Ten-fifteen minutes. I guess my point is you’re right, the rituals aren’t important in a high context team. The work is really figuring out what you’re building. Like really really figuring it out.
- RaftPeople 2y ago
  > The most valuable process I’ve ever instituted as a manager is design review. Absolutely hammering a design has proven to me to be the best way to ensure people have absolute clarity on the end state and have thought through the flow, copy and other-than-happy paths through the software. 100% agree. You can change a design on the whiteboard rapidly and with practice you can really eliminate a lot of problems with a relatively small investment of time. We just had one where a small group was stretching a bit in what they could take on, they ran into some issues and afterward commented "ok, I see what you're saying, we needed to work through that flow in more detail for a couple hours to avoid that week of pain".

coffeefirst 2y ago

The problem isn’t sprints. The problem is treating them like deadlines. Stop doing that. Treat anyone who does with derision. Without the pressure to make your stupid charts look pretty it’s just a two week planning cycle, and that’s fine.

randerson 2y ago

I've delivered many successful software projects on small teams without Agile or any other other formal methodology. At two separate startups this helped grow us large enough to hire new executives who promptly inflicted "Agile" on us. (As in a plethora of tools and processes and roles. Evidently they didn't read the manifesto). Agile sucked all joy out of the profession for me. Both times, development speed slowed, budgets soared, bugs went unfixed, and the teams lost sight of the big picture of what they were building. Yet the executives stood by their decisions because they now had a sense of visibility and control, not realizing the true cost of that.

moominpapa 2y ago

Does anyone else suspect that agile, whatever its stated intentions, has been coopted as a smokescreen for micromanagement? 20 years ago I worked on a large non-it related project that was slipping and I was tasked to call at the end of each day every team working on the project to ascertain the progress they had been made that day. It made me very unpopular as there was a tacit lack of trust in the process. Back then I feel, it just was not done to make skilled workers explain themselves on a daily basis. I suspect the younger generation have been cowed and normalised to a much higher level of scrutiny leading to creativity and joy being sucked out of the working day.

nineteen999 2y ago
A _suspicion_? Plenty of us saw it coming ...

cedws 2y ago

I hate sprints. Developers are not machines. We don't crunch through work like an assembly line worker. We don't work at a consistent rate. Sometimes, shit happens you couldn't possibly predict. Sometimes, you want to go work on something else for a while. Sometimes we can't accurately say how long something is going to take until we're half way through. I just don't understand the point of boxing yourself into a set of work for X weeks when you could just use Kanban and pick up/put down work when needed.