9 ms·

This article, as with much tech discussion I've seen in the past 5-10 years, seems to take sprints as a given. Are most devs here working in a sprint model? It

This article, as with much tech discussion I've seen in the past 5-10 years, seems to take sprints as a given. Are most devs here working in a sprint model? It sounds a bit soul crushing to me to be "continually sprinting". I'm so glad that our company doesn't have them—I think it's a significant factor in me grinding it out for 9+ years. We have feature releases every 4 weeks. If your feature is merged before QA, it goes out in that release. Otherwise, it gets delayed till the next release, and we don't make a big deal about it—several other features will still be in the release. I feel like it gives me a lot more agency and ownership of my work. I think it's the right amount of subtle deadline pressure, relying on my intrinsic motivation to get my feature shipped and move onto the next one. Or to have the freedom to determine that it's not ready yet and spend a little more time to avoid shoving out a pile of technical debt. I'm curious to see what I'm missing, though. Anyone love sprints? Anyone working in a non-sprint model and hate it?

alfalfasprout 6y ago
My team doesn't do sprints and honestly thank god. HN is pretty "product eng" focused and sprints do work better there... but for infra projects where the units of work often tend to involve more R&D, exploration, etc. I've found that weekly check-ins work best (scheduling ad-hoc sync when needed). You still get the benefit of a heads-up on what people are working on but you're not trying to shove tasks into arbitrary 2-3 week sprints. At the end of the day, "agile" wasn't originally the monstrosity that scrum-fetishists have turned it into. It was simply these few lines: "Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan"
- cpeterso 6y ago
  Sprints that don't ship something (i.e. "deliver user value") are just arbitrary timeboxes. They probably can just be progress checkins without all the overhead of Scrum ceremony.
  - stefanmichael 6y ago
    Arbitrary time boxes are what poor managers use to micro manage. I recently saw a team put under leadership of a poor manager and descend into never ending micro management under the guise of "milestones" which were just arbitrary time boxes determined by a tech lead. It also serves to pressure the tech lead "you said it would be done!" which thereby incentivizes the tech leads to pressure their team. It's really dumb, net loss for the company (burnout, higher turnover), and a total waste of time.
    - apple4ever 6y ago
      Oh man this describes my position to a T as the lead. Manager demands a date which forces me to push my team which they hate. Sigh.
- Sodman 6y ago
  1000% this! The key takeaway of Agile that a lot of people lose sight of, is that you should be doing whatever works for your team, not whatever you did at a previous company or read from a trendy blog post. By all means - try out anything you think will work for your team. If you're trying to plan out which individual stories your eng team will be working on 6 months from now, or you have a half-dozen "Sprint Retrospectives" with the same complaints every sprint from your team with no changes being made - you've probably made a wrong turn somewhere.
  - lovedev 6y ago
    +1
- apple4ever 6y ago
  Thanks side another perspective on infra teams. We do Agile and it's such a time waster for us. We spend 5 hours a week on ceremonies that could be condensed to two half hour meetings.
- danjac 6y ago
  Unfortunately "agile" is one of those lovely sounding ideas that were never going to survive contact with the real world of company politics and management. Perhaps in some places, in some small agencies and startups with strong tech-focused leadership it might yield some successes for a short time, until they start growing and hiring from the bigger companies. Then you end up with the same-old-same-old with more meetings and Jira.
- noarchy 6y ago
  "Individuals and interactions over processes and tools" It is precisely at this beginning point where most "Agile" teams fall flat on their faces. Instead, it is all about process, rather than said individuals/interactions. Scrum rituals are done because, well, everyone else does them, so that's considered "correct". Whether or not there is any value in the process is secondary.
  - brendoelfrendo 6y ago
    It's also the motivation from management to build process. Rather than agile being a toolbox you pull from because it's helpful, it becomes a suite of metrics that managers and executives can track. Thus everyone must use the full toolbox because their benefit is overruled by management's benefit.
  - closeparen 6y ago
    My company's leadership does not acknowledge or care about value delivered locally; it is all about cross-team collaboration. (If you get something done locally in 6 weeks, you wasted your time, while if you involve 4 other orgs so that it takes 30 weeks, everyone involved gets promoted). It seems local variations in development processes as the #1 blocker to more cross-team collaboration, so it is enthusiastically steamrolling them.
- hackerm0nkey 6y ago
  I've always wondered, how did it come to this? isn't having a standup every day a 'process'?
majormajor 6y ago
I think you might be assuming "sprint" to be some always-the-same-thing that it doesn't have to be. On one recent team, we did 2 week sprints with a couple releases per week (basically, one per feature that finishes and makes it through QA). The 2 week cycle was our planning/work prep cadence. If a feature isn't fleshed out by its owners and stakeholders prior to the start of the sprint, we're not going to ask any devs to pick it up during that sprint. If it is ready, we'll start to plan it, and estimate how long it will take, talk about debt-vs-speed tradeoffs, etc. I think I might dislike the model you describe because it seems potentially isolated around "my feature" vs "the rest of the team's feature," and because I think making the planning cycle 4 weeks instead of two might cause more planning pain for each release.
- BrandonM 6y ago
  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?
illogico 6y ago
Bob Martin put it best: "Software projects are marathons, and in a marathon you don't want to sprint." I do think it's useful to have some cadence for important meetings, but the arbitrary timeframe should not be treated as a goal or even something worth dignifying in and of itself. It's simply a tool, nothing more and nothing less, and we should expressly state its purpose and discard it in situations where it ceases to be useful. I actually do like the default Agile meetings, but I think they're usually implemented haphazardly. I would prefer standups at the end of the day so that they run no risk of destroying the context of a programming task or block me from starting my work day. I like IPM/sprint planning to refine stories and make sure they're ready to work. I like having a "definition of done" to create a shared agreement of what my commitments are and whether I've met them. I like retro to evaluate how we're doing as a team and to improve processes and working culture. I like technical retros to share learning and troubleshoot architectural problems and identify useful areas of research. All of these things are great when done well and for the right reason. All of them can be sources of misery when they are done ineptly or as mere formalities, with no underlying sense of purpose.
- rswail 6y ago
  Do standups just before lunch. People tend to work on different schedules, start/finish early, start/finish late, but most tend to have their "middle of the day meal" at around the same time. So instead of 9 or 10am, or 4 or 5pm, do it at the "natural" break time, eg 12:00-12:15. Two advantages, people that have got "into" the work flow in the morning need to break anyway, people that use the morning for "admin" and then afternoon for work can finish their housekeeping with the standup. Same applies at the next order of magnitude, start/finish sprints in the middle of the week, not the beginning or end. No one wants to sit in a review on a Friday afternoon. Retrospectives make sense at the end of the working week. Planning makes sense at the beginning.
- tootie 6y ago
  Instead of "sprints" I say "slogs". That keeps the team motivated.
- mns 6y ago
  > Bob Martin put it best: "Software projects are marathons, and in a marathon you don't want to sprint." As a both a runner and a developer, I find this quite funny and a bit wrong. The fact that we call them sprints can be a bit wrong or confusing if you put them in a different context, but what I can say is that almost every serious runner will constantly check their laps, be it miles, be it km, you will always look at your watch to see how you performed in your last km and if you are on track. That's what I see useful in sprints, the fact that you stop for a bit and see where you are, you have the time to discuss things that might have gone wrong and try to fix them before it gets out of hand. But in the end I can understand people who dislike the system, because I've worked with a lot of managers with no technical knowledge trying to manage technical projects.
gregkerzhner 6y ago
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.
gowld 6y ago
> We have feature releases every 4 weeks. If your feature is merged before QA, it goes out in that release. That's what a sprint is.
- BrandonM 6y ago
  We make basically no attempts to estimate how long a feature is going to take and then update those estimates along the way. An individual feature could take a few days to implement or several months (years even). Periodic check-ins are completely independent of the 4-week release cycle. Every 4 weeks, we release whatever has been merged in the last 4 weeks. One dev might have 8 independent changes in a release or 0. We typically have a handful of significant changes that land each release and a bunch of minor improvements. Still, there's not much effort to estimate when any particular feature might land. When a large feature is getting close to completion, the dev might choose to push a little bit to hit a particular release. There's not really any external pressure to do that, though. That's still a sprint?
  - srtjstjsj 6y ago
    Yes. A key idea of Agile (maybe Scrum specifically) thinking is that you release and retrospect/rethink often, instead of long-term working on unlaunched projects from an ancient plan. I guess if you skip the rethink part than you aren't doing sprints property. An insight of Agile is that your have to pick either a feature based release schedule or a time based release schedule, not both, which is impossible and that time-based is better.
rajacombinator 6y ago
The term “sprint” along with most of Agile nonsense is inane and misleading. I was skeptical of the entire process until recently when I’ve seen some benefits thinking about and practicing it as “method to efficiently parallelize and delegate tasks.” Good planning saves me and the team some cognitive load in determining “what’s next” constantly. And daily stand ups are still mostly useless but a good touch point when doing remote WFH.
tootie 6y ago
Sprints are training wheels for agile. Kanban is simpler and more productive. But only if your team has the maturity and discipline to work efficiently without deadlines.
- paulmooreparks 6y ago
  My teams did Kanban, but we definitely had deadlines. It was wonderful to see continuous flows of work and individual developers empowered to work independently.
lmm 6y ago
> We have feature releases every 4 weeks. If your feature is merged before QA, it goes out in that release. Otherwise, it gets delayed till the next release, and we don't make a big deal about it—several other features will still be in the release. Um, yeah, that's a sprint. That's exactly how it's supposed to work. Like you say, it's a good way to work. What do you think a sprint is? I've worked in non-sprint models - i.e. no regular time-based cadence - and found them harder. It's very easy for a feature to scope creep if you've not got any regular schedule, and it's harder to feel a sense of achievement if you're not releasing regularly.
- BrandonM 6y ago
  Everything I've read to this point seemed to describe sprints as chunking every task so that it takes no more than 1–2 weeks to complete (depending on the company's sprint length). I inferred that a dev would be expected to pick up and complete one of those task chunks each sprint. I have seen occasional references to tasks that last 2 sprints. I was contrasting with that model, though it sounds like I might not be accurately characterizing sprints. We've had some features that have taken over a year to complete, such as a major rearchitecture. The (generally senior) dev assigned to that task has a lot of latitude to break it up according to their judgement, submit individual parts on their own timeline, etc., all while minimizing bookkeeping and coordination with others. As long as they're continuing to make forward progress according to an initially vague, sensible, iterative plan, we tend to leave our established devs to their own devices. For newer devs and where multiple devs are collaborating on a feature together, we encourage at least weekly check-ins.
  - lmm 6y ago
    Ah, sorry, so you're saying it would be normal for a dev to take several of these 4-week periods between delivering anything? You're right, that's not scrum; not delivering anything in a given sprint shouldn't be a big deal (just re-estimate the remainder), but yeah, consistently having sprints where you don't deliver anything would be a cause for concern, and would suggest you're not breaking down your tasks enough. I definitely wouldn't want to work in a model where you're expected to just take as long as it takes. Integrating a branch that's been going for 6 months is a nightmare; even when it goes well it's immensely stressful. Reintegrating your work back into the rest of the system can easily feel like it's taking "the other 90% of the time" - or even be impossible, if someone else has changed the system in an incompatible way in the meantime. Even if you were regularly merging code changes to master, if you try to release 6 months of work when none of it's ever been deployed to production yet then there's always the sinking feeling that maybe it's all just going to break. Or worst of all, maybe it works perfectly the way you thought it was meant to, but you misunderstood the spec and so all your work is useless. I'm a bit confused by you talking about an "iterative" plan, because I don't see how you can meaningfully iterate if you're not delivering changes regularly - indeed "iteration" often gets used to mean the same thing as "sprint".
TheUndead96 6y ago
I've worked in these Agile teams for my entire career so far. I have begun to believe that standups, in the way that most companies conduct them, are against the interest of most developers. It feels like I need to justify my position every day, and that I am only as good as my last feature. Sprints are basically scientifically optimised crunch. It is like the last stretch of a project every 2 weeks. Just put in the extra energy "for the sake of the sprint". Pull all-nighters, just so that you can be told in your planning meeting that we are "agile", and the requirements are changing again. Disclaimer: These are subjective opinions, and I recognise that some developers thrive in this environment. Also, this is a comment on Agile in the wild, rather than in principle.
mihaaly 6y ago
We don't either and I do not get the fuss. It is just a very formal and robotic performance that cannot possibly address all the needs, cannot be the centerpiece of an organization, as it is pretended so many times nowadays. Including the so called sprints. The work we do differ in size and complexity and schedule and workforce requirement therefore our interactions adapt to the situation. And not the work adapt to a mechanistic interaction style. When we need frequent feedback we do frequent feedback. When we need deep group planing we do group planing periods. When we need intensive coding we do intensive coding with occasional follow ups. We track progress, we monitor workforce. When someone hit the wall that person cries for help and we do something about it - depends on the trouble what and how. In one position we used it but was sooo mechanistic and insufficient to address the varying needs that it died off quickly. I believe it cold be great for certain situations. Simple repetitive ones? But otherwise looks like yet another holy grail management method people hype for a while and might join the club of all other holy grail management techniques being praised to the heavens in their time throughout the history so the world was adjusted to those not the other way around. Then found yet another holy grail out of disappointment. Not to mention that seemingly no one knows what it is exactly and how it should be used, some do this was, some do that way. And so we are back to the adaptive management now. : ) It must be good for a certain set of situations but it is odd that this is a crucial bit in interviews if someone have experience in it or not, like if it was impossible to adapt to the management style of the task at hand and it would require special skills or capabilities requiring preexisting abilities or formal training....
ziml77 6y ago
I'm not doing sprints now, but we have stand-ups. I think the stand-up itself is a great way to keep people on track. Plus it gives management a much better idea of when to expect things to be delivered. I don't have a great opinion of sprints for a couple of reasons. I used to have a job that did sprints. Development was often rushed to fit the sprints which led to a high rate of defects. And now I'm working with a vendor that does development in sprints. When we ask them for changes, it adds a large amount of lag to actually getting them because we have to wait up to 2 weeks for them to reprioritize, and then at least 2 weeks for release.

alfalfasprout 6y ago

My team doesn't do sprints and honestly thank god. HN is pretty "product eng" focused and sprints do work better there... but for infra projects where the units of work often tend to involve more R&D, exploration, etc. I've found that weekly check-ins work best (scheduling ad-hoc sync when needed). You still get the benefit of a heads-up on what people are working on but you're not trying to shove tasks into arbitrary 2-3 week sprints. At the end of the day, "agile" wasn't originally the monstrosity that scrum-fetishists have turned it into. It was simply these few lines: "Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan"

cpeterso 6y ago
Sprints that don't ship something (i.e. "deliver user value") are just arbitrary timeboxes. They probably can just be progress checkins without all the overhead of Scrum ceremony.
- stefanmichael 6y ago
  Arbitrary time boxes are what poor managers use to micro manage. I recently saw a team put under leadership of a poor manager and descend into never ending micro management under the guise of "milestones" which were just arbitrary time boxes determined by a tech lead. It also serves to pressure the tech lead "you said it would be done!" which thereby incentivizes the tech leads to pressure their team. It's really dumb, net loss for the company (burnout, higher turnover), and a total waste of time.
  - apple4ever 6y ago
    Oh man this describes my position to a T as the lead. Manager demands a date which forces me to push my team which they hate. Sigh.
Sodman 6y ago
1000% this! The key takeaway of Agile that a lot of people lose sight of, is that you should be doing whatever works for your team, not whatever you did at a previous company or read from a trendy blog post. By all means - try out anything you think will work for your team. If you're trying to plan out which individual stories your eng team will be working on 6 months from now, or you have a half-dozen "Sprint Retrospectives" with the same complaints every sprint from your team with no changes being made - you've probably made a wrong turn somewhere.
- lovedev 6y ago
  +1
apple4ever 6y ago
Thanks side another perspective on infra teams. We do Agile and it's such a time waster for us. We spend 5 hours a week on ceremonies that could be condensed to two half hour meetings.
danjac 6y ago
Unfortunately "agile" is one of those lovely sounding ideas that were never going to survive contact with the real world of company politics and management. Perhaps in some places, in some small agencies and startups with strong tech-focused leadership it might yield some successes for a short time, until they start growing and hiring from the bigger companies. Then you end up with the same-old-same-old with more meetings and Jira.
noarchy 6y ago
"Individuals and interactions over processes and tools" It is precisely at this beginning point where most "Agile" teams fall flat on their faces. Instead, it is all about process, rather than said individuals/interactions. Scrum rituals are done because, well, everyone else does them, so that's considered "correct". Whether or not there is any value in the process is secondary.
- brendoelfrendo 6y ago
  It's also the motivation from management to build process. Rather than agile being a toolbox you pull from because it's helpful, it becomes a suite of metrics that managers and executives can track. Thus everyone must use the full toolbox because their benefit is overruled by management's benefit.
- closeparen 6y ago
  My company's leadership does not acknowledge or care about value delivered locally; it is all about cross-team collaboration. (If you get something done locally in 6 weeks, you wasted your time, while if you involve 4 other orgs so that it takes 30 weeks, everyone involved gets promoted). It seems local variations in development processes as the #1 blocker to more cross-team collaboration, so it is enthusiastically steamrolling them.
hackerm0nkey 6y ago
I've always wondered, how did it come to this? isn't having a standup every day a 'process'?

majormajor 6y ago

I think you might be assuming "sprint" to be some always-the-same-thing that it doesn't have to be. On one recent team, we did 2 week sprints with a couple releases per week (basically, one per feature that finishes and makes it through QA). The 2 week cycle was our planning/work prep cadence. If a feature isn't fleshed out by its owners and stakeholders prior to the start of the sprint, we're not going to ask any devs to pick it up during that sprint. If it is ready, we'll start to plan it, and estimate how long it will take, talk about debt-vs-speed tradeoffs, etc. I think I might dislike the model you describe because it seems potentially isolated around "my feature" vs "the rest of the team's feature," and because I think making the planning cycle 4 weeks instead of two might cause more planning pain for each release.

BrandonM 6y ago
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?

illogico 6y ago

Bob Martin put it best: "Software projects are marathons, and in a marathon you don't want to sprint." I do think it's useful to have some cadence for important meetings, but the arbitrary timeframe should not be treated as a goal or even something worth dignifying in and of itself. It's simply a tool, nothing more and nothing less, and we should expressly state its purpose and discard it in situations where it ceases to be useful. I actually do like the default Agile meetings, but I think they're usually implemented haphazardly. I would prefer standups at the end of the day so that they run no risk of destroying the context of a programming task or block me from starting my work day. I like IPM/sprint planning to refine stories and make sure they're ready to work. I like having a "definition of done" to create a shared agreement of what my commitments are and whether I've met them. I like retro to evaluate how we're doing as a team and to improve processes and working culture. I like technical retros to share learning and troubleshoot architectural problems and identify useful areas of research. All of these things are great when done well and for the right reason. All of them can be sources of misery when they are done ineptly or as mere formalities, with no underlying sense of purpose.

rswail 6y ago
Do standups just before lunch. People tend to work on different schedules, start/finish early, start/finish late, but most tend to have their "middle of the day meal" at around the same time. So instead of 9 or 10am, or 4 or 5pm, do it at the "natural" break time, eg 12:00-12:15. Two advantages, people that have got "into" the work flow in the morning need to break anyway, people that use the morning for "admin" and then afternoon for work can finish their housekeeping with the standup. Same applies at the next order of magnitude, start/finish sprints in the middle of the week, not the beginning or end. No one wants to sit in a review on a Friday afternoon. Retrospectives make sense at the end of the working week. Planning makes sense at the beginning.
tootie 6y ago
Instead of "sprints" I say "slogs". That keeps the team motivated.
mns 6y ago
> Bob Martin put it best: "Software projects are marathons, and in a marathon you don't want to sprint." As a both a runner and a developer, I find this quite funny and a bit wrong. The fact that we call them sprints can be a bit wrong or confusing if you put them in a different context, but what I can say is that almost every serious runner will constantly check their laps, be it miles, be it km, you will always look at your watch to see how you performed in your last km and if you are on track. That's what I see useful in sprints, the fact that you stop for a bit and see where you are, you have the time to discuss things that might have gone wrong and try to fix them before it gets out of hand. But in the end I can understand people who dislike the system, because I've worked with a lot of managers with no technical knowledge trying to manage technical projects.

gregkerzhner 6y ago

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.

gowld 6y ago

> We have feature releases every 4 weeks. If your feature is merged before QA, it goes out in that release. That's what a sprint is.

BrandonM 6y ago
We make basically no attempts to estimate how long a feature is going to take and then update those estimates along the way. An individual feature could take a few days to implement or several months (years even). Periodic check-ins are completely independent of the 4-week release cycle. Every 4 weeks, we release whatever has been merged in the last 4 weeks. One dev might have 8 independent changes in a release or 0. We typically have a handful of significant changes that land each release and a bunch of minor improvements. Still, there's not much effort to estimate when any particular feature might land. When a large feature is getting close to completion, the dev might choose to push a little bit to hit a particular release. There's not really any external pressure to do that, though. That's still a sprint?
- srtjstjsj 6y ago
  Yes. A key idea of Agile (maybe Scrum specifically) thinking is that you release and retrospect/rethink often, instead of long-term working on unlaunched projects from an ancient plan. I guess if you skip the rethink part than you aren't doing sprints property. An insight of Agile is that your have to pick either a feature based release schedule or a time based release schedule, not both, which is impossible and that time-based is better.

rajacombinator 6y ago

The term “sprint” along with most of Agile nonsense is inane and misleading. I was skeptical of the entire process until recently when I’ve seen some benefits thinking about and practicing it as “method to efficiently parallelize and delegate tasks.” Good planning saves me and the team some cognitive load in determining “what’s next” constantly. And daily stand ups are still mostly useless but a good touch point when doing remote WFH.

tootie 6y ago

Sprints are training wheels for agile. Kanban is simpler and more productive. But only if your team has the maturity and discipline to work efficiently without deadlines.

paulmooreparks 6y ago
My teams did Kanban, but we definitely had deadlines. It was wonderful to see continuous flows of work and individual developers empowered to work independently.

lmm 6y ago

> We have feature releases every 4 weeks. If your feature is merged before QA, it goes out in that release. Otherwise, it gets delayed till the next release, and we don't make a big deal about it—several other features will still be in the release. Um, yeah, that's a sprint. That's exactly how it's supposed to work. Like you say, it's a good way to work. What do you think a sprint is? I've worked in non-sprint models - i.e. no regular time-based cadence - and found them harder. It's very easy for a feature to scope creep if you've not got any regular schedule, and it's harder to feel a sense of achievement if you're not releasing regularly.

BrandonM 6y ago
Everything I've read to this point seemed to describe sprints as chunking every task so that it takes no more than 1–2 weeks to complete (depending on the company's sprint length). I inferred that a dev would be expected to pick up and complete one of those task chunks each sprint. I have seen occasional references to tasks that last 2 sprints. I was contrasting with that model, though it sounds like I might not be accurately characterizing sprints. We've had some features that have taken over a year to complete, such as a major rearchitecture. The (generally senior) dev assigned to that task has a lot of latitude to break it up according to their judgement, submit individual parts on their own timeline, etc., all while minimizing bookkeeping and coordination with others. As long as they're continuing to make forward progress according to an initially vague, sensible, iterative plan, we tend to leave our established devs to their own devices. For newer devs and where multiple devs are collaborating on a feature together, we encourage at least weekly check-ins.
- lmm 6y ago
  Ah, sorry, so you're saying it would be normal for a dev to take several of these 4-week periods between delivering anything? You're right, that's not scrum; not delivering anything in a given sprint shouldn't be a big deal (just re-estimate the remainder), but yeah, consistently having sprints where you don't deliver anything would be a cause for concern, and would suggest you're not breaking down your tasks enough. I definitely wouldn't want to work in a model where you're expected to just take as long as it takes. Integrating a branch that's been going for 6 months is a nightmare; even when it goes well it's immensely stressful. Reintegrating your work back into the rest of the system can easily feel like it's taking "the other 90% of the time" - or even be impossible, if someone else has changed the system in an incompatible way in the meantime. Even if you were regularly merging code changes to master, if you try to release 6 months of work when none of it's ever been deployed to production yet then there's always the sinking feeling that maybe it's all just going to break. Or worst of all, maybe it works perfectly the way you thought it was meant to, but you misunderstood the spec and so all your work is useless. I'm a bit confused by you talking about an "iterative" plan, because I don't see how you can meaningfully iterate if you're not delivering changes regularly - indeed "iteration" often gets used to mean the same thing as "sprint".

TheUndead96 6y ago

I've worked in these Agile teams for my entire career so far. I have begun to believe that standups, in the way that most companies conduct them, are against the interest of most developers. It feels like I need to justify my position every day, and that I am only as good as my last feature. Sprints are basically scientifically optimised crunch. It is like the last stretch of a project every 2 weeks. Just put in the extra energy "for the sake of the sprint". Pull all-nighters, just so that you can be told in your planning meeting that we are "agile", and the requirements are changing again. Disclaimer: These are subjective opinions, and I recognise that some developers thrive in this environment. Also, this is a comment on Agile in the wild, rather than in principle.

mihaaly 6y ago

We don't either and I do not get the fuss. It is just a very formal and robotic performance that cannot possibly address all the needs, cannot be the centerpiece of an organization, as it is pretended so many times nowadays. Including the so called sprints. The work we do differ in size and complexity and schedule and workforce requirement therefore our interactions adapt to the situation. And not the work adapt to a mechanistic interaction style. When we need frequent feedback we do frequent feedback. When we need deep group planing we do group planing periods. When we need intensive coding we do intensive coding with occasional follow ups. We track progress, we monitor workforce. When someone hit the wall that person cries for help and we do something about it - depends on the trouble what and how. In one position we used it but was sooo mechanistic and insufficient to address the varying needs that it died off quickly. I believe it cold be great for certain situations. Simple repetitive ones? But otherwise looks like yet another holy grail management method people hype for a while and might join the club of all other holy grail management techniques being praised to the heavens in their time throughout the history so the world was adjusted to those not the other way around. Then found yet another holy grail out of disappointment. Not to mention that seemingly no one knows what it is exactly and how it should be used, some do this was, some do that way. And so we are back to the adaptive management now. : ) It must be good for a certain set of situations but it is odd that this is a crucial bit in interviews if someone have experience in it or not, like if it was impossible to adapt to the management style of the task at hand and it would require special skills or capabilities requiring preexisting abilities or formal training....

ziml77 6y ago

I'm not doing sprints now, but we have stand-ups. I think the stand-up itself is a great way to keep people on track. Plus it gives management a much better idea of when to expect things to be delivered. I don't have a great opinion of sprints for a couple of reasons. I used to have a job that did sprints. Development was often rushed to fit the sprints which led to a high rate of defects. And now I'm working with a vendor that does development in sprints. When we ask them for changes, it adds a large amount of lag to actually getting them because we have to wait up to 2 weeks for them to reprioritize, and then at least 2 weeks for release.