7 ms·

In defense of sprints, not everyone is the same. Deadlines for me are a strong motivation to get things done, whereas "no deadline, just do it at your own pace

by umvi 8y ago

In defense of sprints, not everyone is the same. Deadlines for me are a strong motivation to get things done, whereas "no deadline, just do it at your own pace until it's done" will cause me to procrastinate and get it done much more slowly. There is no silver bullet for software development process. It takes hard work and flexibility to optimize your team's work flow.

yebyen 8y ago
I've been reading "It Doesn't Have to be Crazy at Work" and they have a chapter about this. Deadlines are great! Estimates are terrible, and humans are terrible at estimating. Scope needs to be elastic to accommodate this fact of life. If the project is not done in the 6 weeks you set aside for it, just ship something anyways and move on. It was only worth 6 weeks when you planned on getting it done in 6 weeks, so why spend more? Go ahead and plan another sprint if it turns out what you were able to build in the time allocated wasn't enough, and you really need more. (Put it up against the other opportunities you have, and give them all a fair chance at those finite development resources, something else might also turn out to be more important.) Just don't spend forever and drag out the deadline, throwing off the timeline for whatever you had planned to do next, because you needed more time for the thing that underestimated how big it was, so it wasn't really possible to do that whole thing in only 6 weeks. The release that is reduced in scope might be totally insufficient, or, it might be just what your users needed! The knife also cuts both ways – if you're willing to accept that project scope can change in either direction, you can occasionally deliver things early too. I really like everything about this book.
- TheOtherHobbes 8y ago
  If you set aside 6 weeks and it takes 12, you suck at estimating. Not only are you likely to ship a broken product, but you also have no way of making intelligent business decisions about possible projects. Project A will bring in $X. You estimate 6 weeks. It takes 12. Project B will bring in $Y. You estimate 6 weeks. It takes 7. If X is similar to Y and you bet on the wrong horse, you've dented and/or sunk your cash flow for no reason. Saying "Humans suck at estimating" is nonsense. It's a skill that can easily be improved - usually at the cost of some up front planning - and there are plenty of resources to help you with that. The real problem with Agile is that it gives management an excuse to do no estimation at all. Some alpha-wannabe manager bangs their fist on a desk and says "I want this in three weeks". Instead of saying "You're insane" teams are pressured into trying to make up for someone else's laziness and lack of contact with reality.
  - jdmichal 8y ago
    You can also use modeling, which for a bunch of STEM people seems to almost never come up. Take projects you've done, do Monte Carlo simulations, and then start giving estimates with confidence bounds. Can also use things like Little's Law to determine lead times.
    - coldtea 8y ago
      That only works if you regularly get similar projects. Throw a new type of project or a new client with special needs, and bets are off, Monte Carlo or not.
      - jdmichal 8y ago
        Yea I've been down this discussion path before. I'll just refer you there, and you can feel free to chime in with any new thoughts. My general thoughts is that typical software engineering does not have drastically more degrees of project uniqueness than other engineering fields. https://news.ycombinator.com/item?id=17765399 https://news.ycombinator.com/item?id=17765399
        coldtea 8y ago
        >My general thoughts is that typical software engineering does not have drastically more degrees of project uniqueness than other engineering fields. I really doubt that. In construction for example, tolerances, materials, requirements, etc are know well before even a single brick has been laid, and if they are to even consider changing them mid-construction, detailed new plans about everything that changed is in process. That's almost never the case with software requirements. The same tools, processes and technologies are also used for decades or in some cases centuries totally unchanged. In software a domain (e.g. web programming) can be completely different every 5-10 years.
  - yebyen 8y ago
    It's not that we estimated 6 weeks and it takes 12. It's that we get a bundle of tasks up-front and are told "it's going to take 6 weeks" for reasons that are negotiated at a higher level than our pay-grade. It's my situation anyway. The core idea I took out of Agile is that once the high-level estimates are completed, the developers are meant to break them down into bite-sized tasks, put estimates on those, and prioritize them in a backlog with the project manager, customers, and any stakeholders. (In my case we're not building products to go to market with, I work in Higher Ed. We're building solutions for campus partners. So it's not really "Project B will bring in $Y," it's "Project will further our mission and better enable some common workflow." Not to go off-topic...) What's happening instead is, we get the high-level tasks and then break the projects down into bite-sized chunks, then estimate the parts, and are told "great, now make that fit into 6 weeks, because that's all you have." Developers don't estimate in hours or days, they use points or t-shirt sizes, because honestly, we do suck at estimating. It's not what you pay us to do. (I mean this honestly, it's really not. This is what they pay project managers to do, and they're literally a pay-grade above us. And they don't write code, though they may be good at math and judging t-shirt sizes. The better ones also know how to keep their poker face, when meeting with the customers. But if your project is slated to last only 6 weeks, chances are you won't even have access to a PM. You wouldn't want one if you could get one, since 6 weeks is hardly enough time to plan and later change course. What would they do?) T-shirt sizes are better than estimates at a sprint level too, because all you're really doing is horse-trading. If a feature is XXL according to the devs, maybe it moves to the back of the queue in favor of something that costs less and is worth more. That's what you do at Sprint Planning. Back to devs, we're experts at writing the features, and sometimes we can tell you how long it's going to take and get that right, ... and sometimes we can harmonize in concert with the project leadership, but that's not our core competency. It's just moving faster, and doing it better. Sometimes you find out that the specs are wrong after the project has already started, and it's going to take longer. We know that some projects are going to take a year, and some are going to take two. And those projects get project managers, and they are frequently delivered on time, with all of the promised features in them! Six weeks isn't an estimate, it's a budget. (And it's not a real budget, hardly even registers on the balance sheet. It's more like an experimental timeline.) The problem is, customers prefer that we blow the budget rather than delivering part of a product on-time, even if it might have turned out to be enough. They're not willing to put things in order of priority, take an honest look at what will take 6 weeks to deliver, and settle for that. They'd rather cut corners, and then we allow them to make those concessions. Only they don't really want concessions, so we wind up having to spend extra time papering over the gaps.
- deleted 8y ago
  [deleted]
wirrbel 8y ago
My issue with sprints is not exactly the rhythm itself. It's the sabotage of continuous delivery and operation (DevOps in the original idea).
- yebyen 8y ago
  Yes, this also. In my organization, we have a problem with "just ship something" because the cost of making a release is so high. We know this, so rather than ever "just shipping this part that's ready" we often drag projects out longer so we can "be really done with them." Only sometimes, we could really have been done with them, without necessarily finishing all of that pet feature which has thrown off the whole timeline, by being more complicated to implement than anyone was able to imagine upfront.
- matthewmacleod 8y ago
  I’m not sure I understand how they interact. My teams have always continued to practice continuous delivery totally independently of sprint boundaries - that is, released were totally independent of sprints.
  - wirrbel 8y ago
    Yes, that's how it should be and basically it sounds like you are then already doing a Kanban style working mode (and what purpose does the sprint rhythm than serve)? Scrum by the books usually implies that releases happen after the po or the customer has accepted the increment at the sprint review.
    - matwood 8y ago
      > (and what purpose does the sprint rhythm than serve) I find a good sprint rhythm stops the constant task shuffle. When business knows the dev team is mid-sprint it forces them to think about priority. We do CI/CD, and only big items (in reality UI/UX changes) wait until a sprint review to go out.
sodosopa 8y ago
I somewhat agree. When I had a content team, sprints made sense, since we adapted it to go in line with Advertising's publishing calendar. Development had to be done at a certain point and once we shipped the pieces, we published. On my old CMS team and with my current development team, we use kanban because it aligns with how we function. We get ad hoc tickets in our queue, we pass them through a triage lane, then they're picked up by data, dev and qa as they're completed and within the items allowed with our WIP. Waving a broad brush to say x is what everyone uses, will fuck everyone up. Neither agile, waterfall nor kanban are the ideal solutions for everyone.
brightball 8y ago
My rule for deadlines is that it must have a “Why?” associated with it. Deadlines with a Why are real. Usually tied to an event outside of the dev teams control. Anything that doesn’t have a Why next to it is essentially carrot dangling. You can have targets/forecasts when you expect to have something ready while making it clear that these are guesses, but if it’s not real then it creates real problems if you pretend that it is.
- t0mbstone 8y ago
  Usually the "Why" is always going to be some variant of, "The client wants this ASAP!", or "The client called and they are complaining about this bug". How would you force your manager into converting that "why" into one you would accept?
  - brightball 8y ago
    When dealing with clients, ASAP = Rush Rate. If it’s really needed that fast, they will pay extra for it. If it’s not, they will wait for the timeline that you can hit. All that said, client work is the one place where sprints serve a real purpose. The scope doesn’t expand because you finish early so there is a built in reward, agreed upon price for the scoped work, and a built in penalty.

by umvi 8y ago

yebyen 8y ago

I've been reading "It Doesn't Have to be Crazy at Work" and they have a chapter about this. Deadlines are great! Estimates are terrible, and humans are terrible at estimating. Scope needs to be elastic to accommodate this fact of life. If the project is not done in the 6 weeks you set aside for it, just ship something anyways and move on. It was only worth 6 weeks when you planned on getting it done in 6 weeks, so why spend more? Go ahead and plan another sprint if it turns out what you were able to build in the time allocated wasn't enough, and you really need more. (Put it up against the other opportunities you have, and give them all a fair chance at those finite development resources, something else might also turn out to be more important.) Just don't spend forever and drag out the deadline, throwing off the timeline for whatever you had planned to do next, because you needed more time for the thing that underestimated how big it was, so it wasn't really possible to do that whole thing in only 6 weeks. The release that is reduced in scope might be totally insufficient, or, it might be just what your users needed! The knife also cuts both ways – if you're willing to accept that project scope can change in either direction, you can occasionally deliver things early too. I really like everything about this book.

TheOtherHobbes 8y ago
If you set aside 6 weeks and it takes 12, you suck at estimating. Not only are you likely to ship a broken product, but you also have no way of making intelligent business decisions about possible projects. Project A will bring in $X. You estimate 6 weeks. It takes 12. Project B will bring in $Y. You estimate 6 weeks. It takes 7. If X is similar to Y and you bet on the wrong horse, you've dented and/or sunk your cash flow for no reason. Saying "Humans suck at estimating" is nonsense. It's a skill that can easily be improved - usually at the cost of some up front planning - and there are plenty of resources to help you with that. The real problem with Agile is that it gives management an excuse to do no estimation at all. Some alpha-wannabe manager bangs their fist on a desk and says "I want this in three weeks". Instead of saying "You're insane" teams are pressured into trying to make up for someone else's laziness and lack of contact with reality.
- jdmichal 8y ago
  You can also use modeling, which for a bunch of STEM people seems to almost never come up. Take projects you've done, do Monte Carlo simulations, and then start giving estimates with confidence bounds. Can also use things like Little's Law to determine lead times.
  - coldtea 8y ago
    That only works if you regularly get similar projects. Throw a new type of project or a new client with special needs, and bets are off, Monte Carlo or not.
    - jdmichal 8y ago
      Yea I've been down this discussion path before. I'll just refer you there, and you can feel free to chime in with any new thoughts. My general thoughts is that typical software engineering does not have drastically more degrees of project uniqueness than other engineering fields. https://news.ycombinator.com/item?id=17765399 https://news.ycombinator.com/item?id=17765399
      - coldtea 8y ago
        >My general thoughts is that typical software engineering does not have drastically more degrees of project uniqueness than other engineering fields. I really doubt that. In construction for example, tolerances, materials, requirements, etc are know well before even a single brick has been laid, and if they are to even consider changing them mid-construction, detailed new plans about everything that changed is in process. That's almost never the case with software requirements. The same tools, processes and technologies are also used for decades or in some cases centuries totally unchanged. In software a domain (e.g. web programming) can be completely different every 5-10 years.
- yebyen 8y ago
  It's not that we estimated 6 weeks and it takes 12. It's that we get a bundle of tasks up-front and are told "it's going to take 6 weeks" for reasons that are negotiated at a higher level than our pay-grade. It's my situation anyway. The core idea I took out of Agile is that once the high-level estimates are completed, the developers are meant to break them down into bite-sized tasks, put estimates on those, and prioritize them in a backlog with the project manager, customers, and any stakeholders. (In my case we're not building products to go to market with, I work in Higher Ed. We're building solutions for campus partners. So it's not really "Project B will bring in $Y," it's "Project will further our mission and better enable some common workflow." Not to go off-topic...) What's happening instead is, we get the high-level tasks and then break the projects down into bite-sized chunks, then estimate the parts, and are told "great, now make that fit into 6 weeks, because that's all you have." Developers don't estimate in hours or days, they use points or t-shirt sizes, because honestly, we do suck at estimating. It's not what you pay us to do. (I mean this honestly, it's really not. This is what they pay project managers to do, and they're literally a pay-grade above us. And they don't write code, though they may be good at math and judging t-shirt sizes. The better ones also know how to keep their poker face, when meeting with the customers. But if your project is slated to last only 6 weeks, chances are you won't even have access to a PM. You wouldn't want one if you could get one, since 6 weeks is hardly enough time to plan and later change course. What would they do?) T-shirt sizes are better than estimates at a sprint level too, because all you're really doing is horse-trading. If a feature is XXL according to the devs, maybe it moves to the back of the queue in favor of something that costs less and is worth more. That's what you do at Sprint Planning. Back to devs, we're experts at writing the features, and sometimes we can tell you how long it's going to take and get that right, ... and sometimes we can harmonize in concert with the project leadership, but that's not our core competency. It's just moving faster, and doing it better. Sometimes you find out that the specs are wrong after the project has already started, and it's going to take longer. We know that some projects are going to take a year, and some are going to take two. And those projects get project managers, and they are frequently delivered on time, with all of the promised features in them! Six weeks isn't an estimate, it's a budget. (And it's not a real budget, hardly even registers on the balance sheet. It's more like an experimental timeline.) The problem is, customers prefer that we blow the budget rather than delivering part of a product on-time, even if it might have turned out to be enough. They're not willing to put things in order of priority, take an honest look at what will take 6 weeks to deliver, and settle for that. They'd rather cut corners, and then we allow them to make those concessions. Only they don't really want concessions, so we wind up having to spend extra time papering over the gaps.
deleted 8y ago
[deleted]

wirrbel 8y ago

My issue with sprints is not exactly the rhythm itself. It's the sabotage of continuous delivery and operation (DevOps in the original idea).

yebyen 8y ago
Yes, this also. In my organization, we have a problem with "just ship something" because the cost of making a release is so high. We know this, so rather than ever "just shipping this part that's ready" we often drag projects out longer so we can "be really done with them." Only sometimes, we could really have been done with them, without necessarily finishing all of that pet feature which has thrown off the whole timeline, by being more complicated to implement than anyone was able to imagine upfront.
matthewmacleod 8y ago
I’m not sure I understand how they interact. My teams have always continued to practice continuous delivery totally independently of sprint boundaries - that is, released were totally independent of sprints.
- wirrbel 8y ago
  Yes, that's how it should be and basically it sounds like you are then already doing a Kanban style working mode (and what purpose does the sprint rhythm than serve)? Scrum by the books usually implies that releases happen after the po or the customer has accepted the increment at the sprint review.
  - matwood 8y ago
    > (and what purpose does the sprint rhythm than serve) I find a good sprint rhythm stops the constant task shuffle. When business knows the dev team is mid-sprint it forces them to think about priority. We do CI/CD, and only big items (in reality UI/UX changes) wait until a sprint review to go out.

sodosopa 8y ago

I somewhat agree. When I had a content team, sprints made sense, since we adapted it to go in line with Advertising's publishing calendar. Development had to be done at a certain point and once we shipped the pieces, we published. On my old CMS team and with my current development team, we use kanban because it aligns with how we function. We get ad hoc tickets in our queue, we pass them through a triage lane, then they're picked up by data, dev and qa as they're completed and within the items allowed with our WIP. Waving a broad brush to say x is what everyone uses, will fuck everyone up. Neither agile, waterfall nor kanban are the ideal solutions for everyone.

brightball 8y ago

My rule for deadlines is that it must have a “Why?” associated with it. Deadlines with a Why are real. Usually tied to an event outside of the dev teams control. Anything that doesn’t have a Why next to it is essentially carrot dangling. You can have targets/forecasts when you expect to have something ready while making it clear that these are guesses, but if it’s not real then it creates real problems if you pretend that it is.

t0mbstone 8y ago
Usually the "Why" is always going to be some variant of, "The client wants this ASAP!", or "The client called and they are complaining about this bug". How would you force your manager into converting that "why" into one you would accept?
- brightball 8y ago
  When dealing with clients, ASAP = Rush Rate. If it’s really needed that fast, they will pay extra for it. If it’s not, they will wait for the timeline that you can hit. All that said, client work is the one place where sprints serve a real purpose. The scope doesn’t expand because you finish early so there is a built in reward, agreed upon price for the scoped work, and a built in penalty.