7 ms·

What would be the alternative without sprints? What specifically about not using sprints would help the team if they lack good planners and people capable of s

by the_af 4y ago

What would be the alternative without sprints? What specifically about not using sprints would help the team if they lack good planners and people capable of seeing the big picture? Isn't such a team screwed regardless of how they allot work?

peteradio 4y ago
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")
mgkimsal 4y ago
A more fluid "here's what we're prioritizing next" approach. is that 'kanban'? (I think so?) Worked on a small group (2-3 people?) and .. 'agile-2-week-sprint-estimate-tickets-with-points' wasn't working well. This is 'startup/mvp' area, and we migrated to just a simpler task board. Owner moves tickets up and down in a "to do" queue, and someone (usually me) takes current 'to do' tickets, and does them and releases. The '2 week' time box wasn't really helping anything - we can 'release' multiple times per week. For larger teams working on established product, there's more value to the '2-week-sprint-give-points-to-tickets' approach that's more popular. Worked in a group a few years ago like that, and... while there were some issues, they weren't specific to sprints or agile, more just growing pains of that company.
- jerf 4y ago
  This is what we've been using for some years now, despite the general Scrum-y pressure in the organization I work in. (It is not a mandate, note we get no blowback for what we do as it is under our control, I'm just saying most of the rest of the teams definitely do something more Scrum-y.) I am a big believer in "true agile", since "Agile" (note capital letter) has become heavily corrupted. "True agile" can really be summed up as "try some different things, keep what works for you". My team has a large number of independent projects, more than one per person. Because of that we tend to have one person working on a given project at a time, as that is a cheap way to avoid coordination overhead if you are able to get away with it. What we found for "sprints" is that we couldn't plan anything with them, because the variance in how much time we were actually going to have to work on a project was too high. We might have the full two weeks to work on what we said we were going to work on. We might have a fire on another system that pulled that person away for literally 3/4ths of that "sprint". We might have an emergency feature request that could do the same thing. We found this variance to dominate the rest of our time planning, which resulted in our "sprint planning" being a bad joke. Nor could we just "git gud" at sprint planning, because the variance in the amount of time we had to spend on it was far, far too pathological. I do not present this as evidence that "Sprints" are bad for everyone, only that there are cases where they really don't based on my experience as well. This has been my personal working mode for most of the last 10 years, and they've never worked for me. We've switched to a much more Kanban style of planning, which gives us the flexibility to deal with our issues without wrecking all our plans. I personally take the brunt of a lot of the highest frequency switching in our team, and my primary goal is that on a given day, I am working on one project, with a secondary goal of trying to keep it chunked up by week. That latter often fails, but I definitely try to avoid switching projects mid-day. (Which also fails, sometimes due to fires, but I've noticeably improved on this metric in the past couple of years.) We've tried at least twice to switch to a more Sprint-y method of organization to better match the rest of the organization, but failed both times. I'm fine with the attempt, I'm just very glad we've also retained the flexibility to admit it was a failure, and that it isn't mandated from above that we must do the Sprint approach. The vast bulk of teams in the rest of the organization I work in does have 3-7 person teams all working on one particular system, and while nobody ever escapes from the possibility of fires, they have a lower variance on the impact on that for all sorts of reasons. (Most notable being that 3/4ths of a week for one person out of 3-7 is a lower impact than 3/4ths of a week out of what was effectively zero people, which means it was actively drawing against what was nominally another project's time. That's a really big difference.) Sprints work much better for them. I'm sure they fail them sometimes but they generally seem to work for them.

by the_af 4y ago

peteradio 4y ago

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")

mgkimsal 4y ago

A more fluid "here's what we're prioritizing next" approach. is that 'kanban'? (I think so?) Worked on a small group (2-3 people?) and .. 'agile-2-week-sprint-estimate-tickets-with-points' wasn't working well. This is 'startup/mvp' area, and we migrated to just a simpler task board. Owner moves tickets up and down in a "to do" queue, and someone (usually me) takes current 'to do' tickets, and does them and releases. The '2 week' time box wasn't really helping anything - we can 'release' multiple times per week. For larger teams working on established product, there's more value to the '2-week-sprint-give-points-to-tickets' approach that's more popular. Worked in a group a few years ago like that, and... while there were some issues, they weren't specific to sprints or agile, more just growing pains of that company.

jerf 4y ago
This is what we've been using for some years now, despite the general Scrum-y pressure in the organization I work in. (It is not a mandate, note we get no blowback for what we do as it is under our control, I'm just saying most of the rest of the teams definitely do something more Scrum-y.) I am a big believer in "true agile", since "Agile" (note capital letter) has become heavily corrupted. "True agile" can really be summed up as "try some different things, keep what works for you". My team has a large number of independent projects, more than one per person. Because of that we tend to have one person working on a given project at a time, as that is a cheap way to avoid coordination overhead if you are able to get away with it. What we found for "sprints" is that we couldn't plan anything with them, because the variance in how much time we were actually going to have to work on a project was too high. We might have the full two weeks to work on what we said we were going to work on. We might have a fire on another system that pulled that person away for literally 3/4ths of that "sprint". We might have an emergency feature request that could do the same thing. We found this variance to dominate the rest of our time planning, which resulted in our "sprint planning" being a bad joke. Nor could we just "git gud" at sprint planning, because the variance in the amount of time we had to spend on it was far, far too pathological. I do not present this as evidence that "Sprints" are bad for everyone, only that there are cases where they really don't based on my experience as well. This has been my personal working mode for most of the last 10 years, and they've never worked for me. We've switched to a much more Kanban style of planning, which gives us the flexibility to deal with our issues without wrecking all our plans. I personally take the brunt of a lot of the highest frequency switching in our team, and my primary goal is that on a given day, I am working on one project, with a secondary goal of trying to keep it chunked up by week. That latter often fails, but I definitely try to avoid switching projects mid-day. (Which also fails, sometimes due to fires, but I've noticeably improved on this metric in the past couple of years.) We've tried at least twice to switch to a more Sprint-y method of organization to better match the rest of the organization, but failed both times. I'm fine with the attempt, I'm just very glad we've also retained the flexibility to admit it was a failure, and that it isn't mandated from above that we must do the Sprint approach. The vast bulk of teams in the rest of the organization I work in does have 3-7 person teams all working on one particular system, and while nobody ever escapes from the possibility of fires, they have a lower variance on the impact on that for all sorts of reasons. (Most notable being that 3/4ths of a week for one person out of 3-7 is a lower impact than 3/4ths of a week out of what was effectively zero people, which means it was actively drawing against what was nominally another project's time. That's a really big difference.) Sprints work much better for them. I'm sure they fail them sometimes but they generally seem to work for them.