3 ms·

One thing that I didn't realize I loved about sprints until I went to a place without them is the guarantee what for the next two weeks, your priorities are set

One thing that I didn't realize I loved about sprints until I went to a place without them is the guarantee what for the next two weeks, your priorities are set, and aren't changing unless something very unexpected happens. Having a two week period with a decided set of work allows you to peacefully do this work isolated from incoming requests - unless they are critical, they will always be delayed to the next sprint. Without sprints, our direction and priority changed daily, with no ability to say "we haven't planned for this, please wait". The result was it was incredibly hard to get anything done, and attention was always scattered. I am happily back at a place that is doing sprints, and I am sure the problems at my previous organization were far bigger than not having them, but sprints do seem like a great tool to isolate the developer from exterior fluctuations. Granted, a great project manager can probably do the same thing.

addicted 6y ago
I think it’s interesting because the feature of the sprint you appear to like is that it completely removes small a agility. If you have constant and regular changes in priorities that appears to be an issue with whoever is doing the prioritizing/planning for your team and not a consequence of a specific process.
- gregkerzhner 6y ago
  The agility is still there, its just buffered a bit. This is really useful for concentrating. If you are in a small startup with obvious goals, I don't think you need sprints. If you are in a large organization and are constantly being pulled into different directions between new feature work, production bugs, and tech debt initiatives, having a buffer is pretty useful. Without sprints, when the next semi-important bug comes down from production, its pretty hard to justify that its more important than the feature you are building, or especially the tech debt cleanup you are doing. Everything tends to be "important" so if there is no culture of picking a set of work and sticking to it, attention is constantly distracted from one thing to the next. For me at least, programming is all about some momentum - its hard to get rolling but once you are, you can keep going. Sprints give me the room to have bouts of momentum, stopping every two weeks to adjust direction, and then starting up again. Without them, it feels more like pacman - darting and reacting rather than holding a steady direction.
- dentemple 6y ago
  > I think it’s interesting because the feature of the sprint you appear to like is that it completely removes small a agility. Ideally, at the end of a sprint you'll have a concrete deliverable. Because this deliverable is concrete and not ongoing, the team should (theoretically) be able to switch entirely to a different project (or priority) afterward when business circumstances demand it. That's where the "agility" comes in. If, on the other hand, the work is being produced as a continuous flow--without hard cut-offs--then there's no set point where the team can switch priorities without leaving behind a half-finished state. Obviously, YMMV on how this all shakes out in practice.

addicted 6y ago

I think it’s interesting because the feature of the sprint you appear to like is that it completely removes small a agility. If you have constant and regular changes in priorities that appears to be an issue with whoever is doing the prioritizing/planning for your team and not a consequence of a specific process.

gregkerzhner 6y ago
The agility is still there, its just buffered a bit. This is really useful for concentrating. If you are in a small startup with obvious goals, I don't think you need sprints. If you are in a large organization and are constantly being pulled into different directions between new feature work, production bugs, and tech debt initiatives, having a buffer is pretty useful. Without sprints, when the next semi-important bug comes down from production, its pretty hard to justify that its more important than the feature you are building, or especially the tech debt cleanup you are doing. Everything tends to be "important" so if there is no culture of picking a set of work and sticking to it, attention is constantly distracted from one thing to the next. For me at least, programming is all about some momentum - its hard to get rolling but once you are, you can keep going. Sprints give me the room to have bouts of momentum, stopping every two weeks to adjust direction, and then starting up again. Without them, it feels more like pacman - darting and reacting rather than holding a steady direction.
dentemple 6y ago
> I think it’s interesting because the feature of the sprint you appear to like is that it completely removes small a agility. Ideally, at the end of a sprint you'll have a concrete deliverable. Because this deliverable is concrete and not ongoing, the team should (theoretically) be able to switch entirely to a different project (or priority) afterward when business circumstances demand it. That's where the "agility" comes in. If, on the other hand, the work is being produced as a continuous flow--without hard cut-offs--then there's no set point where the team can switch priorities without leaving behind a half-finished state. Obviously, YMMV on how this all shakes out in practice.