4 ms·

Some of this is valid, but most is badly off-base. A lot of people confuse the sprint cadence with the natural functional milestones that emerge in any software

Some of this is valid, but most is badly off-base. A lot of people confuse the sprint cadence with the natural functional milestones that emerge in any software project. Nothing in agile requires you to finish a feature in one sprint; it only requires that you have demonstrable functionality. Developers always chunk their work into comprehensible pieces, and those pieces are almost always less than two weeks work, for the practical reason that a project much bigger than that is pretty difficult for an individual developer to hold in his or her head. The worst case scenario is that some kind of interim demonstrable milestone has to be found in a chunk that is projected to take longer than a sprint, but in practice that's almost never very hard to do for an experienced developer. We routinely divvy up functionality, it's part of the professional skillset. You seem pretty hung up on the story point thing. I've never experienced that much of an issue with it. In practice, the team does give greater weight to the opinions of people with special expertise. And no team I've ever been on has spent much time arguing about 1 or 2-point stories. The advantage of group pointing comes when you talk to the outliers; often someone in the group will think of an aspect that no one else did, and group pointing brings that out. Regarding the motivation of managers, maybe everyone is out to get you, but probably not. Most managers really just want to know the team's velocity, so they can project the likelihood of making future (very real) deadlines. They're not taking your sprint stats and showing them off in some secret manager's society.

mlthoughts2018 8y ago
I never said that two-week units (or any length of sprint) is treated as a complete deadline. Only that it’s treated as the cadence of work. For some types of work, it’s inappropriate to spend time on e.g. planning overhead every two weeks, regardless of how much work you partially completed. Sometimes you just need a month before you can say anything meaningful. For example, you say: > “The worst case scenario is that some kind of interim demonstrable milestone has to be found in a chunk that is projected to take longer than a sprint, but in practice that's almost never very hard to do for an experienced developer. We routinely divvy up functionality, it's part of the professional skillset.” But that is exactly the problem that happens all the time when you are e.g. working on a new statistical model. You may not even learn what the required demo functionality even is within two weeks. Often all you can say is, “we looked into this with a ton of effort, and it’s really hard, and we need to look into it more.” This happens very rarely with straight software engineering, and you can timebox it and then move on, or come back later. But it happens all the time with fundamental research. So when you’re on a team that is assigned nothing but fundamental research, the arbitrary two-week meeting overhead cadence is a huge time wasting nuisance, and trying to conform the work to some cookie cutter expectations about breaking up by points, or rolling a ticket over, really gets in the way, especially when people want the “velocity” of research output to produce the same graphs as the velocity of other types of teams. On the opposite end of the spectrum there can be alerting & monitoring teams, or helpdesk teams with very tight timelines, and for whom two week intervals are too long. The point is that all the glib simplifications you mention don’t apply to every team, and it hurts productivity to try to wedge every conceptual way of working into some one-size-fits-all box that prescribes exactly when to spend time on planning overhead and exactly what overhead everyone must use. > “Most managers really just want to know the team's velocity, so they can project the likelihood of making future (very real) deadlines” If you have discovered a way of recording velocity that has even a weak predictive efficacy for forecasting completion, please let me know. Across all software teams I’ve heard of, worked on, or collaborated with, the velocity numbers carry no forecasting efficacy whatsoever. Not even for ballpark estimates. I’ve literally had a manager come up to me and ask why Team A’s velocity looks “more linear” than Team B’s, or try to tell me they computed “t-stats” on one team’s velocity being bigger than another (they did not in fact know what NHST even was, only that some number popped out of a statistical test formula for population mean differences, and not even accounting for standard error). I’ve had managers ask me if I can “simulate” how many story points one of my engineers would have completed had he not been on vacation for a sprint, because with the reduced story points, the curve they plotted for their meeting had a dip in it that they didn’t want to have to explain. To me it just seems you’ve been exceptionally lucky with the types of middle managers who handle Agile data where you work. And I guess also out-of-this-world lucky with a team whose Agile story point based velocity has any informative predictive efficacy for deadlines.
- vannevar 8y ago
  But that is exactly the problem that happens all the time when you are e.g. working on a new statistical model. I've worked in software for 25 years and rarely had difficulty finding a good functional breakpoint where my software could be demo'd in some form. It definitely doesn't happen "all the time" in development. But it happens all the time with fundamental research. Nor does it happen all the time with research. I've run research on a scrum basis with 2 week sprints for 6 years with great success. It just isn't that hard to break work into reasonable pieces. If it is really hard, even after years of practice, then writing software is probably not a good career choice. Do we always get it right? No. Our percentage of 'green' sprints is around 70%. But that's enough to provide some stability in planning, and to be able to track our incremental progress without too many nasty surprises. If you have discovered a way of recording velocity that has even a weak predictive efficacy for forecasting completion, please let me know. Across all software teams I’ve heard of, worked on, or collaborated with, the velocity numbers carry no forecasting efficacy whatsoever. Not even for ballpark estimates. This is a fair criticism, but accurate software estimation is hard, period, agile or not. Velocity may not be useful for telling you when a project will be complete, but it's very useful in warning you when it won't be complete, which in practice is just as valuable. I won't defend anyone who applies deep statistical analysis on sprint velocity, unless they have a very large dataset to work with.
  - mlthoughts2018 8y ago
    > "It definitely doesn't happen "all the time" in development." It absolutely does in different business units. I'm glad this hasn't happened to you in your business units. That doesn't say anything about other types of business units. My experience is particularly in developing machine learning research that is both publishable and simultaneously directly useful for a performance-constraint business problem. In this area of work, the output of two weeks of labor is often nothing other than "I thought about this and here's what I learned... and I suspect we are no closer to anything usable." You string a few of these cycles together, and then things finally crystallize and you suddenly make a dramatic amount of progress very quickly. Then, after that point the problem becomes more like a standard engineering problem, with an iterative cycle to steadily bring a software system wrapping the research product into a deliverable state, and incremental progress is appropriate. You just seem to think only from your bubble, where the idea of incremental progress is almost always useful for you. But there are whole business domains where the idea of incremental progress is nonsense, and you have to dig into a problem in a deep and uninterrupted way for long periods of time before you can describe what's going on. Why would it be better to force people to shoehorn their work into a prescriptive model that requires you to give incremental progress, when that goes against the very nature of the work? Why not let the team customize it as needed. Maybe Person A doesn't need to check in for a month, but Person B is working on productionizing a new solution from two months ago, so Person B does need to check in more regarding incremental updates. Why not let them each have different planning cycles just using basic common sense and trusting them to do their work? I still don't see anything in your comment beyond just saying, "my work area has happened to never be like that, therefore Agile works in all situations." > "Nor does it happen all the time with research. I've run research on a scrum basis with 2 week sprints for 6 years with great success. It just isn't that hard to break work into reasonable pieces. If it is really hard, even after years of practice, then writing software is probably not a good career choice." Oh. I see. You're just trolling.

mlthoughts2018 8y ago

I never said that two-week units (or any length of sprint) is treated as a complete deadline. Only that it’s treated as the cadence of work. For some types of work, it’s inappropriate to spend time on e.g. planning overhead every two weeks, regardless of how much work you partially completed. Sometimes you just need a month before you can say anything meaningful. For example, you say: > “The worst case scenario is that some kind of interim demonstrable milestone has to be found in a chunk that is projected to take longer than a sprint, but in practice that's almost never very hard to do for an experienced developer. We routinely divvy up functionality, it's part of the professional skillset.” But that is exactly the problem that happens all the time when you are e.g. working on a new statistical model. You may not even learn what the required demo functionality even is within two weeks. Often all you can say is, “we looked into this with a ton of effort, and it’s really hard, and we need to look into it more.” This happens very rarely with straight software engineering, and you can timebox it and then move on, or come back later. But it happens all the time with fundamental research. So when you’re on a team that is assigned nothing but fundamental research, the arbitrary two-week meeting overhead cadence is a huge time wasting nuisance, and trying to conform the work to some cookie cutter expectations about breaking up by points, or rolling a ticket over, really gets in the way, especially when people want the “velocity” of research output to produce the same graphs as the velocity of other types of teams. On the opposite end of the spectrum there can be alerting & monitoring teams, or helpdesk teams with very tight timelines, and for whom two week intervals are too long. The point is that all the glib simplifications you mention don’t apply to every team, and it hurts productivity to try to wedge every conceptual way of working into some one-size-fits-all box that prescribes exactly when to spend time on planning overhead and exactly what overhead everyone must use. > “Most managers really just want to know the team's velocity, so they can project the likelihood of making future (very real) deadlines” If you have discovered a way of recording velocity that has even a weak predictive efficacy for forecasting completion, please let me know. Across all software teams I’ve heard of, worked on, or collaborated with, the velocity numbers carry no forecasting efficacy whatsoever. Not even for ballpark estimates. I’ve literally had a manager come up to me and ask why Team A’s velocity looks “more linear” than Team B’s, or try to tell me they computed “t-stats” on one team’s velocity being bigger than another (they did not in fact know what NHST even was, only that some number popped out of a statistical test formula for population mean differences, and not even accounting for standard error). I’ve had managers ask me if I can “simulate” how many story points one of my engineers would have completed had he not been on vacation for a sprint, because with the reduced story points, the curve they plotted for their meeting had a dip in it that they didn’t want to have to explain. To me it just seems you’ve been exceptionally lucky with the types of middle managers who handle Agile data where you work. And I guess also out-of-this-world lucky with a team whose Agile story point based velocity has any informative predictive efficacy for deadlines.

vannevar 8y ago
But that is exactly the problem that happens all the time when you are e.g. working on a new statistical model. I've worked in software for 25 years and rarely had difficulty finding a good functional breakpoint where my software could be demo'd in some form. It definitely doesn't happen "all the time" in development. But it happens all the time with fundamental research. Nor does it happen all the time with research. I've run research on a scrum basis with 2 week sprints for 6 years with great success. It just isn't that hard to break work into reasonable pieces. If it is really hard, even after years of practice, then writing software is probably not a good career choice. Do we always get it right? No. Our percentage of 'green' sprints is around 70%. But that's enough to provide some stability in planning, and to be able to track our incremental progress without too many nasty surprises. If you have discovered a way of recording velocity that has even a weak predictive efficacy for forecasting completion, please let me know. Across all software teams I’ve heard of, worked on, or collaborated with, the velocity numbers carry no forecasting efficacy whatsoever. Not even for ballpark estimates. This is a fair criticism, but accurate software estimation is hard, period, agile or not. Velocity may not be useful for telling you when a project will be complete, but it's very useful in warning you when it won't be complete, which in practice is just as valuable. I won't defend anyone who applies deep statistical analysis on sprint velocity, unless they have a very large dataset to work with.
- mlthoughts2018 8y ago
  > "It definitely doesn't happen "all the time" in development." It absolutely does in different business units. I'm glad this hasn't happened to you in your business units. That doesn't say anything about other types of business units. My experience is particularly in developing machine learning research that is both publishable and simultaneously directly useful for a performance-constraint business problem. In this area of work, the output of two weeks of labor is often nothing other than "I thought about this and here's what I learned... and I suspect we are no closer to anything usable." You string a few of these cycles together, and then things finally crystallize and you suddenly make a dramatic amount of progress very quickly. Then, after that point the problem becomes more like a standard engineering problem, with an iterative cycle to steadily bring a software system wrapping the research product into a deliverable state, and incremental progress is appropriate. You just seem to think only from your bubble, where the idea of incremental progress is almost always useful for you. But there are whole business domains where the idea of incremental progress is nonsense, and you have to dig into a problem in a deep and uninterrupted way for long periods of time before you can describe what's going on. Why would it be better to force people to shoehorn their work into a prescriptive model that requires you to give incremental progress, when that goes against the very nature of the work? Why not let the team customize it as needed. Maybe Person A doesn't need to check in for a month, but Person B is working on productionizing a new solution from two months ago, so Person B does need to check in more regarding incremental updates. Why not let them each have different planning cycles just using basic common sense and trusting them to do their work? I still don't see anything in your comment beyond just saying, "my work area has happened to never be like that, therefore Agile works in all situations." > "Nor does it happen all the time with research. I've run research on a scrum basis with 2 week sprints for 6 years with great success. It just isn't that hard to break work into reasonable pieces. If it is really hard, even after years of practice, then writing software is probably not a good career choice." Oh. I see. You're just trolling.