4 ms·

That's interesting, thanks. So a dev can be working on a feature over an open ended number of sprints? What is the significance of the sprint, then? We don't h

That's interesting, thanks. So a dev can be working on a feature over an open ended number of sprints? What is the significance of the sprint, then? We don't have "planning cycles" except for quarterly prioritization to realign on which features matter the most (exceptional features occasionally get prioritized outside the process). When you finish one project, you pick another that's interesting to you that's near the top of the priority list, with support from our Product team and Engineering Operations.

nicoburns 6y ago
Yes, absolutely. It's supposed to be a happy medium between everything being planned out months in advance with no flexibility on one hand, and constantly changing priorities such that developer workloads change beneath their feet before they get a chance to make significant headway. Your model sounds like it could be reasonably described as 4-week sprints.
- BrandonM 6y ago
  I really don't think so. We have processes that happen on a 4-week cadence, and about 10% of the engineering team rotates through duties in shepherding those processes. For all other devs, the experience is to pick up a feature, work on it for as long as it takes with periodic technical check-ins, complete the code review, and then pick up their next feature, completely independently of our 4-week release cycle. Is that still sprints?
  - nicoburns 6y ago
    I would say a key difference is the "completely independently". "agile" models tend to make the independent unit a small team (say 2-5 developers, along with designers, QA people and product people). And within that team it's generally considered best practice for everyone to eat least be keeping an eye on what the others are working on and be familiar enough with it that they could pick it up if need be.
lostcolony 6y ago
The goal of the sprint is -planning-. It has no effect on the devs doing work. If we estimate what can get done for a given time period, we can evaluate whether we're correct. Do it a few times, we get really good in estimating. We can try and estimate the future. As soon as new things come in that we didn't plan for, we know immediately that we're going to slip, and may even be able to figure out by how much, or what we have to drop to still hit the date (or if we need to evaluate if more people would be helpful; PM triangle here). Likewise if we learn our estimates are wrong, we can start predicting we're going to miss the mark, literally as early as humanly possible. Doing it this way is in response to longer term milestones; if you only estimate/evaluate once before delivery (if even that; oftentimes milestones are just "on time" or "behind", there isn't any acceptance that a date and set of features won't be hit, and it turns into a death march), you only get one chance to evaluate and respond. Likewise with two, three, etc milestones. Sprints just try to break the work up to do it more often, to try and recognize you're behind, sooner, and so can respond. They don't have to be two weeks; it's a tradeoff, the more measurements the faster you'll recognize you're off, but the more work it is just to measure. If you don't have deadlines that the rest of the org has to organize around, or to communicate to a customer, just a very clear set of priorities, and you just pull from the top from, you don't benefit from Scrum. Which is perfectly okay. Just, oftentimes businesses -do- need things by a given date, or need to respond in some way. Sprints just help give you evaluations to determine that you're on track. Or not.
balfirevic 6y ago
> What is the significance of the sprint, then? Among other things, releasing something on a consistent schedule. I hope you (and the rest of HN) will forgive me for making this little meme: https://i.imgflip.com/4g6z3o.jpg https://i.imgflip.com/4g6z3o.jpg
coffeefirst 6y ago
>So a dev can be working on a feature over an open ended number of sprints Sure. Ideally it would be broken up into tickets that fit inside individual sprints, but sometimes particularly hard problems are just going to roll over. That's fine and nobody should feel bad about it. I hated agile the first time I met it because the team had no autonomy and a bad culture. When you actually have the ability to treat your process like a tool, none of this is a silver bullet, but it's a fine tool.

nicoburns 6y ago

Yes, absolutely. It's supposed to be a happy medium between everything being planned out months in advance with no flexibility on one hand, and constantly changing priorities such that developer workloads change beneath their feet before they get a chance to make significant headway. Your model sounds like it could be reasonably described as 4-week sprints.

BrandonM 6y ago
I really don't think so. We have processes that happen on a 4-week cadence, and about 10% of the engineering team rotates through duties in shepherding those processes. For all other devs, the experience is to pick up a feature, work on it for as long as it takes with periodic technical check-ins, complete the code review, and then pick up their next feature, completely independently of our 4-week release cycle. Is that still sprints?
- nicoburns 6y ago
  I would say a key difference is the "completely independently". "agile" models tend to make the independent unit a small team (say 2-5 developers, along with designers, QA people and product people). And within that team it's generally considered best practice for everyone to eat least be keeping an eye on what the others are working on and be familiar enough with it that they could pick it up if need be.

lostcolony 6y ago

The goal of the sprint is -planning-. It has no effect on the devs doing work. If we estimate what can get done for a given time period, we can evaluate whether we're correct. Do it a few times, we get really good in estimating. We can try and estimate the future. As soon as new things come in that we didn't plan for, we know immediately that we're going to slip, and may even be able to figure out by how much, or what we have to drop to still hit the date (or if we need to evaluate if more people would be helpful; PM triangle here). Likewise if we learn our estimates are wrong, we can start predicting we're going to miss the mark, literally as early as humanly possible. Doing it this way is in response to longer term milestones; if you only estimate/evaluate once before delivery (if even that; oftentimes milestones are just "on time" or "behind", there isn't any acceptance that a date and set of features won't be hit, and it turns into a death march), you only get one chance to evaluate and respond. Likewise with two, three, etc milestones. Sprints just try to break the work up to do it more often, to try and recognize you're behind, sooner, and so can respond. They don't have to be two weeks; it's a tradeoff, the more measurements the faster you'll recognize you're off, but the more work it is just to measure. If you don't have deadlines that the rest of the org has to organize around, or to communicate to a customer, just a very clear set of priorities, and you just pull from the top from, you don't benefit from Scrum. Which is perfectly okay. Just, oftentimes businesses -do- need things by a given date, or need to respond in some way. Sprints just help give you evaluations to determine that you're on track. Or not.

balfirevic 6y ago

> What is the significance of the sprint, then? Among other things, releasing something on a consistent schedule. I hope you (and the rest of HN) will forgive me for making this little meme: https://i.imgflip.com/4g6z3o.jpg https://i.imgflip.com/4g6z3o.jpg

coffeefirst 6y ago

>So a dev can be working on a feature over an open ended number of sprints Sure. Ideally it would be broken up into tickets that fit inside individual sprints, but sometimes particularly hard problems are just going to roll over. That's fine and nobody should feel bad about it. I hated agile the first time I met it because the team had no autonomy and a bad culture. When you actually have the ability to treat your process like a tool, none of this is a silver bullet, but it's a fine tool.