4 ms·

How bout, plan enough then just build the thing until we agree its usable and correct. What the hell is the point of the short time framed boundaries? I'm not

How bout, plan enough then just build the thing until we agree its usable and correct. What the hell is the point of the short time framed boundaries? I'm not a fucking horse I don't need cadence OR blinders.

the_af 4y ago
That can be seen as a large enough sprint that encompasses "the thing". If, like in the scenario I was describing, the team lacks good planners, lead devs and people with the "big picture", what you are describing is a recipe for disaster. What will happen is that at the end of the long stretch, they won't have achieved much or worse, built the wrong thing. When done well, any iterative method is meant to provide early stakeholder feedback at each stage, provide some measure of progress, and have earlier warning signs that the wrong thing is being built. > What the hell is the point of the short time framed boundaries? It's easier to estimate a simpler and smaller thing than a larger and more complex thing. If you cannot achieve the small thing, you absolutely won't be able to do the larger one.
- peteradio 4y ago
  If developers x, y are developing UI and API endpoints and developer z is developing backend to a 10k+ page spec, 2 week sprints need not apply to developer z.
  - the_af 4y ago
    With sprints, the work of developer z would get broken up in more manageable chunks. The backend project would be very high risk otherwise. More in general, coordinating between related but separate projects is a hard problem in software engineering, and it's orthogonal to whether you use sprints, kanban, waterfall or whatever methodology.
    - peteradio 4y ago
      The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints?
      - Volundr 4y ago
        Agile means everything is up for being changed as makes the most sense, so in the (rare) event that you really have a task with 0 sensible deliverables you would indeed likely do longer sprints or no sprints. If that's not mutable because of some management mandate your not really doing Scrum, your doing "process inspired by Scrum" and saying you are doing Scrum. That said your description of "read and synthesize a 10k+ smorgasbord" is nowhere near descriptive enough to answer your question or have any kind of estimate on how easy/hard this work is. It could be anything from I'll have it done in a couple hours this afternoon to a year long effort by multiple devs. The best I can say is in the real world it's pretty rare to have a huge task that doesn't have sensible subtasks. In the case of ingesting a large mess of data like you are describing this could mean identifying and ingesting the data from system X, or processing event Y. These are steps the developers is going to go through anyway, and in many cases are even going to be deployable and useful on their own! Even if they aren't individually deployable they represent useful landmarks allowing for the understanding how work is progressing, readjusting estimates as necessary, and determining if the entire design needs to be reconsidered due to violated assumptions.
        peteradio 4y ago
        Bingo! It's nuanced and process shouldn't rule people. Unfortunately process often rules people and those shops will insist to their dying day that they are agile.
      - the_af 4y ago
        > The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints? I don't know, your problem statement doesn't allow me to formulate an answer. I suspect whatever the project, it can be split into a series of more manageable chunks.
shagie 4y ago
Plan enough is sometimes 3 months of work. "Here's all the stuff we need to do to create a MVP." After 3 months, its not done and you are trying to do the last 90% on a task you thought was already 90% done. The hard things were put off till the end and now the optimistic "it should be done in 3 months" is getting up to directors that you don't have anything that runs at all. The sprint forces a "this is what we're doing in these 2 weeks" with a deliverable at the end. If, at the end of the first sprint, you only got half the things done because of challenges, ok that's what it is. Next sprint you pick up only half as much work and you get that done. Now, the PM can look at all the work that needs to be done and the rate of work that needs to be done and the amount of work and realizes that instead of the initial "yea, we can do this MVP in 3 months" that you're closer to having it out in 8 months if everything remains the same rate. That is something actionable for project management to say "nope, can't have the MVP in 3 months with this scope" after only 4 weeks and the project can get canceled earlier. Sprints try to make management realize overly optimistic estimates and timelines and either have things get adjusted (staff, scope, or time) or have it canceled sooner. Having a sprint based project canceled after 4 weeks rather than embarrassed and dragging out at 12 weeks is good for the organization to not spend resources on things that won't get done in the required timeframe. The goal of the short framed boundaries is to force this decision sooner.
- groby_b 4y ago
  Hot take: If you take three months planning, either it's incredibly complex or you're holding it wrong. If your directors aren't able to recognize either case well before the 3 months mark, get yourself new directors. (Source: I am one of those pointy-haired monsters. The sinking feeling in your gut starts at the end of month one, the latest) And the third paragraph kind of lays bare the problem with sprints: The PM can only look at all the work that needs to be done if, well, there was a discovery phase to list all the work that needs to be done. That discovery looks suspiciously like planning. That's why agile focuses on continuous delivery of value. It's excellent for projects where it's hard to estimate the full scope, but there are many intermediate targets that are valuable to the customer. You go along until enough value is delivered, and then move on. Not all projects work like that. Some things only generate any value at the end of a long slog. Some things can be delivered incrementally but require a predictable end date. (Hello, Black Friday!) And so, you get to adopt methodology to the problem at hand. Sometimes, you really need to spend the planning up front. Sometimes it's enough to sketch it out on a napkin. Sometimes you can do things sprint-by-sprint. Sometimes, you have larger checkpoints and sprints in between. The idea that any single methodology works for every problem is an idea favored by the consulting industry, but not a reality. And it predates agile, by a lot - I've been a process consulting victim way back in the early 80s. (And the mass of miracle methodologies directly led to "No Silver Bullet")

the_af 4y ago

That can be seen as a large enough sprint that encompasses "the thing". If, like in the scenario I was describing, the team lacks good planners, lead devs and people with the "big picture", what you are describing is a recipe for disaster. What will happen is that at the end of the long stretch, they won't have achieved much or worse, built the wrong thing. When done well, any iterative method is meant to provide early stakeholder feedback at each stage, provide some measure of progress, and have earlier warning signs that the wrong thing is being built. > What the hell is the point of the short time framed boundaries? It's easier to estimate a simpler and smaller thing than a larger and more complex thing. If you cannot achieve the small thing, you absolutely won't be able to do the larger one.

peteradio 4y ago
If developers x, y are developing UI and API endpoints and developer z is developing backend to a 10k+ page spec, 2 week sprints need not apply to developer z.
- the_af 4y ago
  With sprints, the work of developer z would get broken up in more manageable chunks. The backend project would be very high risk otherwise. More in general, coordinating between related but separate projects is a hard problem in software engineering, and it's orthogonal to whether you use sprints, kanban, waterfall or whatever methodology.
  - peteradio 4y ago
    The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints?
    - Volundr 4y ago
      Agile means everything is up for being changed as makes the most sense, so in the (rare) event that you really have a task with 0 sensible deliverables you would indeed likely do longer sprints or no sprints. If that's not mutable because of some management mandate your not really doing Scrum, your doing "process inspired by Scrum" and saying you are doing Scrum. That said your description of "read and synthesize a 10k+ smorgasbord" is nowhere near descriptive enough to answer your question or have any kind of estimate on how easy/hard this work is. It could be anything from I'll have it done in a couple hours this afternoon to a year long effort by multiple devs. The best I can say is in the real world it's pretty rare to have a huge task that doesn't have sensible subtasks. In the case of ingesting a large mess of data like you are describing this could mean identifying and ingesting the data from system X, or processing event Y. These are steps the developers is going to go through anyway, and in many cases are even going to be deployable and useful on their own! Even if they aren't individually deployable they represent useful landmarks allowing for the understanding how work is progressing, readjusting estimates as necessary, and determining if the entire design needs to be reconsidered due to violated assumptions.
      - peteradio 4y ago
        Bingo! It's nuanced and process shouldn't rule people. Unfortunately process often rules people and those shops will insist to their dying day that they are agile.
    - the_af 4y ago
      > The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints? I don't know, your problem statement doesn't allow me to formulate an answer. I suspect whatever the project, it can be split into a series of more manageable chunks.

shagie 4y ago

Plan enough is sometimes 3 months of work. "Here's all the stuff we need to do to create a MVP." After 3 months, its not done and you are trying to do the last 90% on a task you thought was already 90% done. The hard things were put off till the end and now the optimistic "it should be done in 3 months" is getting up to directors that you don't have anything that runs at all. The sprint forces a "this is what we're doing in these 2 weeks" with a deliverable at the end. If, at the end of the first sprint, you only got half the things done because of challenges, ok that's what it is. Next sprint you pick up only half as much work and you get that done. Now, the PM can look at all the work that needs to be done and the rate of work that needs to be done and the amount of work and realizes that instead of the initial "yea, we can do this MVP in 3 months" that you're closer to having it out in 8 months if everything remains the same rate. That is something actionable for project management to say "nope, can't have the MVP in 3 months with this scope" after only 4 weeks and the project can get canceled earlier. Sprints try to make management realize overly optimistic estimates and timelines and either have things get adjusted (staff, scope, or time) or have it canceled sooner. Having a sprint based project canceled after 4 weeks rather than embarrassed and dragging out at 12 weeks is good for the organization to not spend resources on things that won't get done in the required timeframe. The goal of the short framed boundaries is to force this decision sooner.

groby_b 4y ago
Hot take: If you take three months planning, either it's incredibly complex or you're holding it wrong. If your directors aren't able to recognize either case well before the 3 months mark, get yourself new directors. (Source: I am one of those pointy-haired monsters. The sinking feeling in your gut starts at the end of month one, the latest) And the third paragraph kind of lays bare the problem with sprints: The PM can only look at all the work that needs to be done if, well, there was a discovery phase to list all the work that needs to be done. That discovery looks suspiciously like planning. That's why agile focuses on continuous delivery of value. It's excellent for projects where it's hard to estimate the full scope, but there are many intermediate targets that are valuable to the customer. You go along until enough value is delivered, and then move on. Not all projects work like that. Some things only generate any value at the end of a long slog. Some things can be delivered incrementally but require a predictable end date. (Hello, Black Friday!) And so, you get to adopt methodology to the problem at hand. Sometimes, you really need to spend the planning up front. Sometimes it's enough to sketch it out on a napkin. Sometimes you can do things sprint-by-sprint. Sometimes, you have larger checkpoints and sprints in between. The idea that any single methodology works for every problem is an idea favored by the consulting industry, but not a reality. And it predates agile, by a lot - I've been a process consulting victim way back in the early 80s. (And the mass of miracle methodologies directly led to "No Silver Bullet")