6 ms·

> incentivizes teams to build things in small, shippable components. Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that

> incentivizes teams to build things in small, shippable components. Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that fit into a single sprint. There's a reason I stopped bothering with Scrum a while ago, and this is high on the list.

lmm 6y ago
> Not everything can be broken down into chunks of work that fit into a single sprint. In my experience everything can be broken down if you spend five minutes actually trying to break it down. And the benefits are very much worthwhile.
- hinkley 6y ago
  How much brownfield work have you done? People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable.
  - lmm 6y ago
    > How much brownfield work have you done? 4-11 years depending on exactly what you'd define as "brownfield" > People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable. True but beside the point. The same point stands: you can always find a way to make a worthwhile improvement in two weeks - something that's useful on its own, even if it's also the first step of a much bigger improvement plan.
- mikro2nd 6y ago
  Consider, then, that your experience might be limited in ways that you're unable to see due to that experience-bias.
  - lmm 6y ago
    Unlikely. I used to go looking for tasks that couldn't be broken down; I'd get excited when someone would claim that their task couldn't be broken down. But they always could, and it was never even hard.
    - willcipriano 6y ago
      My task is to implement a model that takes advantage of unified field theory to simulate arbitrary bodies in spacetime, first the mathematical models behind it need to be created then implemented in software.
      - lmm 6y ago
        > My task is to implement a model that takes advantage of unified field theory to simulate arbitrary bodies in spacetime Sure, sounds straightforward enough. Start with simple cases (e.g. universe is a unit circle), you can definitely implement useful pieces within two weeks. > first the mathematical models behind it need to be created then implemented in software. That's not a real (i.e. user-facing) requirement.
        willcipriano 6y ago
        You should follow your own plan, a Nobel prize in physics awaits.
        lmm 6y ago
        There's no money in doing useful incremental pieces of physics (and precious little even for the big milestones), unfortunately.
betenoire 6y ago
"Shippable" is not equivalent to "done", in any way.
yetanta 6y ago
Not to put it bluntly but you can not do even small bits of work in 2-3 weeks? Sometimes your demo is nothing more than 'here it is in the log doing xyz' or 'I added this thing to this config file'. Not all demos are big flashy ordeals. The team I am on right now most of my demos look exactly like that. I can usually do them right after the standup. Our team allows it because we are mostly remote and talking to each other helps. I personally use scrum as a weapon to make sure management does not overload our teams. Those made up story points are a good way to say 'you have tasked us with 4 months of work in 2 days'. You have to know your manager too. You have to talk to them. Know what they are looking for. Some take a very hands off approach. Some want the nitty gritty details. For both of those a 'oh that is going to take 3 months' may sometimes work. But it does not give them actionable items to help you. The task broken down into some sort of chunked out work does. Sometimes you do not know. It is OK to admit that. That is when you make a discovery story. Make sure they are onboard with that story is to help you find out what is needed. Even then you will still learn along the way. I worked with one guy who wanted to task things down to 15 minute increments, 6 months from now. He kept failing. Because he was being too narrow. He refused to do story points. Because they were 'stupid' yet management kept piling more stuff on him to fail at. He was in every weekend and in until 9PM every night. Because he had no tools to push back. Give your management numbers and actionable items or they will assume everything is hunky dory.
ftio 6y ago
This doesn't require that things fit into a single sprint. It just incentivizes teams to ship their work in smaller chunks. If it helps motivate a team to divide some four-sprint piece of functionality into two shippable chunks that each take two sprints, I'd call that a win. Customers get something a bit faster even if it's not single sprint-sized.
- manquer 6y ago
  Reiterating what gp said , not all dev is like that, lesser you are doing IT and more comp science or any unfamiliar territory really it is harder to break down ahead of time . Many times I can’t tell you what tasks need to done let alone how much time is needed and break it into smaller chunks during planning phase. If planning has to work you should be familiar with what you are building , with poor information on the bug/ code / stack planning agile is just useless overhead . it works great for yet another CRUD app where you know the requirements to the dot and know exactly how to build or fix not always , most management fail to differentiate All the reasons in the TFA are also why it is hard to estimate , what and how much time will take .
  - jameshart 6y ago
    When you’re doing exploratory work, the discipline of stopping, examining what you have learned already, deciding whether the goal still makes sense, and correcting course and reprioritizing seems even more important to me. You don’t know what you will be doing more than a few days ahead? Then your sprint length should be a few days and at the end you recombine and replan. I mean obviously this only makes sense as a way of organizing a team who are trying to build something exploratory - that’s what scrum is meant for. If you are trying to pursue a solo research project within a team the rest of whom are doing scrum then... that’s not a problem agile can solve.
    - manquer 6y ago
      It is not just only research that is exploratory, even the kind of bug fixes the article talks about can be hard to predict. replication of an issue or understand a new module can be uncertain, race conditions or data specific issues are uncertain too. Identifying and solving something similar to [1] with a team is not simply possible when you plan with agile. I am likely going to go the next item once I mitigate the effect without bothering to dig deeper just because someone is clocking me on a timeline I committed. It kills all the joy and fun, work becomes boring, this is by design, it is hard to run an organization unpredictably. If only management trusted you to deliver without looking over shoulder constantly ( when the situation warrants it).. It is not only a engineer's gripe, it applies to management too, the board/ market forces them to be very short sighted, unless you are musk/jobs/buffet it is hard not to buckle to market pressure and invest in longer term opportunities. The point is not that planning is bad, it can do a world of good in many including unpredictable situations, it is more that blinding pushing a framework especially agile because it worked somewhere and everyone says so, or the manager can't be bothered or won't risk doing something different as the situation warrants. [1] https://cloud.google.com/blog/products/management-tools/sre-keeps-digging-to-prevent-problems https://cloud.google.com/blog/products/management-tools/sre-...
MattGaiser 6y ago
There is a reason that teams with mostly non-technical leadership deliver broken software as your choices are feature driven architecture with absurd glue or being asked "why isn't it done yet"?
ddingus 6y ago
Why would it be? For all the things that can be atomic like that, it's good practice. The bigger ones just take time, and aren't shown, until ready for use.
- caymanjim 6y ago
  It's an anti-pattern to simply not demo any progress until done. If you're doing agile right (loaded statement), the solution is to make sure everyone understands what's being done. If the audience is expecting all demos to show complete products, find a different audience to demo done-but-incomplete work. The idea is to get feedback before you've sunk six months into something that may not meet expectations.
  - legopiece 6y ago
    I totally agree. Having weekly demos where we showcase unfinished features has been, in my experience, one of the main avenues where we have learned of issues / conflicts / problems with those features at exactly the right time where we could still fix them. Not having demos of incomplete features would just hide the issues until they are released to the final customers, creating a problem you didn't have before, and making it much more complex to solve.
  - ftio 6y ago
    Yeah, I could've been more precise about what I meant by "demo day." In my comment, I was thinking about the broader, often companywide demo days that many companies hold. I wasn't talking about intra-team demos to, say, product owners.
    - ddingus 6y ago
      "can we sell it" demo day then. Makes perfect sense.
  - ddingus 6y ago
    That isn't what I got out of the comment. Progress gets quantized. Some quanta are small, easily shown, etc... other quanta are a bit bigger, less easily shown. There is a similar problem in manufacturing. Atomic releases. While making something, there are many subtle tweaks to the BOM. Changes, substitutions, removals, adds. Upstream people can make a real mess out of all that, and one way to prevent it is to only deliver releases that are resolved and intended for manufacture. "where is revision 4?" Doesn't exist, won't get manufactured, etc... "Use Revision 5 plz." For the case of insuring expectations get aligned, a mock up can be used. Deliberately used to generate a spec.

lmm 6y ago

> Not everything can be broken down into chunks of work that fit into a single sprint. In my experience everything can be broken down if you spend five minutes actually trying to break it down. And the benefits are very much worthwhile.

hinkley 6y ago
How much brownfield work have you done? People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable.
- lmm 6y ago
  > How much brownfield work have you done? 4-11 years depending on exactly what you'd define as "brownfield" > People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable. True but beside the point. The same point stands: you can always find a way to make a worthwhile improvement in two weeks - something that's useful on its own, even if it's also the first step of a much bigger improvement plan.
mikro2nd 6y ago
Consider, then, that your experience might be limited in ways that you're unable to see due to that experience-bias.
- lmm 6y ago
  Unlikely. I used to go looking for tasks that couldn't be broken down; I'd get excited when someone would claim that their task couldn't be broken down. But they always could, and it was never even hard.
  - willcipriano 6y ago
    My task is to implement a model that takes advantage of unified field theory to simulate arbitrary bodies in spacetime, first the mathematical models behind it need to be created then implemented in software.
    - lmm 6y ago
      > My task is to implement a model that takes advantage of unified field theory to simulate arbitrary bodies in spacetime Sure, sounds straightforward enough. Start with simple cases (e.g. universe is a unit circle), you can definitely implement useful pieces within two weeks. > first the mathematical models behind it need to be created then implemented in software. That's not a real (i.e. user-facing) requirement.
      - willcipriano 6y ago
        You should follow your own plan, a Nobel prize in physics awaits.
        lmm 6y ago
        There's no money in doing useful incremental pieces of physics (and precious little even for the big milestones), unfortunately.

betenoire 6y ago

"Shippable" is not equivalent to "done", in any way.

yetanta 6y ago

Not to put it bluntly but you can not do even small bits of work in 2-3 weeks? Sometimes your demo is nothing more than 'here it is in the log doing xyz' or 'I added this thing to this config file'. Not all demos are big flashy ordeals. The team I am on right now most of my demos look exactly like that. I can usually do them right after the standup. Our team allows it because we are mostly remote and talking to each other helps. I personally use scrum as a weapon to make sure management does not overload our teams. Those made up story points are a good way to say 'you have tasked us with 4 months of work in 2 days'. You have to know your manager too. You have to talk to them. Know what they are looking for. Some take a very hands off approach. Some want the nitty gritty details. For both of those a 'oh that is going to take 3 months' may sometimes work. But it does not give them actionable items to help you. The task broken down into some sort of chunked out work does. Sometimes you do not know. It is OK to admit that. That is when you make a discovery story. Make sure they are onboard with that story is to help you find out what is needed. Even then you will still learn along the way. I worked with one guy who wanted to task things down to 15 minute increments, 6 months from now. He kept failing. Because he was being too narrow. He refused to do story points. Because they were 'stupid' yet management kept piling more stuff on him to fail at. He was in every weekend and in until 9PM every night. Because he had no tools to push back. Give your management numbers and actionable items or they will assume everything is hunky dory.

ftio 6y ago

This doesn't require that things fit into a single sprint. It just incentivizes teams to ship their work in smaller chunks. If it helps motivate a team to divide some four-sprint piece of functionality into two shippable chunks that each take two sprints, I'd call that a win. Customers get something a bit faster even if it's not single sprint-sized.

manquer 6y ago
Reiterating what gp said , not all dev is like that, lesser you are doing IT and more comp science or any unfamiliar territory really it is harder to break down ahead of time . Many times I can’t tell you what tasks need to done let alone how much time is needed and break it into smaller chunks during planning phase. If planning has to work you should be familiar with what you are building , with poor information on the bug/ code / stack planning agile is just useless overhead . it works great for yet another CRUD app where you know the requirements to the dot and know exactly how to build or fix not always , most management fail to differentiate All the reasons in the TFA are also why it is hard to estimate , what and how much time will take .
- jameshart 6y ago
  When you’re doing exploratory work, the discipline of stopping, examining what you have learned already, deciding whether the goal still makes sense, and correcting course and reprioritizing seems even more important to me. You don’t know what you will be doing more than a few days ahead? Then your sprint length should be a few days and at the end you recombine and replan. I mean obviously this only makes sense as a way of organizing a team who are trying to build something exploratory - that’s what scrum is meant for. If you are trying to pursue a solo research project within a team the rest of whom are doing scrum then... that’s not a problem agile can solve.
  - manquer 6y ago
    It is not just only research that is exploratory, even the kind of bug fixes the article talks about can be hard to predict. replication of an issue or understand a new module can be uncertain, race conditions or data specific issues are uncertain too. Identifying and solving something similar to [1] with a team is not simply possible when you plan with agile. I am likely going to go the next item once I mitigate the effect without bothering to dig deeper just because someone is clocking me on a timeline I committed. It kills all the joy and fun, work becomes boring, this is by design, it is hard to run an organization unpredictably. If only management trusted you to deliver without looking over shoulder constantly ( when the situation warrants it).. It is not only a engineer's gripe, it applies to management too, the board/ market forces them to be very short sighted, unless you are musk/jobs/buffet it is hard not to buckle to market pressure and invest in longer term opportunities. The point is not that planning is bad, it can do a world of good in many including unpredictable situations, it is more that blinding pushing a framework especially agile because it worked somewhere and everyone says so, or the manager can't be bothered or won't risk doing something different as the situation warrants. [1] https://cloud.google.com/blog/products/management-tools/sre-keeps-digging-to-prevent-problems https://cloud.google.com/blog/products/management-tools/sre-...

MattGaiser 6y ago

There is a reason that teams with mostly non-technical leadership deliver broken software as your choices are feature driven architecture with absurd glue or being asked "why isn't it done yet"?

ddingus 6y ago

Why would it be? For all the things that can be atomic like that, it's good practice. The bigger ones just take time, and aren't shown, until ready for use.

caymanjim 6y ago
It's an anti-pattern to simply not demo any progress until done. If you're doing agile right (loaded statement), the solution is to make sure everyone understands what's being done. If the audience is expecting all demos to show complete products, find a different audience to demo done-but-incomplete work. The idea is to get feedback before you've sunk six months into something that may not meet expectations.
- legopiece 6y ago
  I totally agree. Having weekly demos where we showcase unfinished features has been, in my experience, one of the main avenues where we have learned of issues / conflicts / problems with those features at exactly the right time where we could still fix them. Not having demos of incomplete features would just hide the issues until they are released to the final customers, creating a problem you didn't have before, and making it much more complex to solve.
- ftio 6y ago
  Yeah, I could've been more precise about what I meant by "demo day." In my comment, I was thinking about the broader, often companywide demo days that many companies hold. I wasn't talking about intra-team demos to, say, product owners.
  - ddingus 6y ago
    "can we sell it" demo day then. Makes perfect sense.
- ddingus 6y ago
  That isn't what I got out of the comment. Progress gets quantized. Some quanta are small, easily shown, etc... other quanta are a bit bigger, less easily shown. There is a similar problem in manufacturing. Atomic releases. While making something, there are many subtle tweaks to the BOM. Changes, substitutions, removals, adds. Upstream people can make a real mess out of all that, and one way to prevent it is to only deliver releases that are resolved and intended for manufacture. "where is revision 4?" Doesn't exist, won't get manufactured, etc... "Use Revision 5 plz." For the case of insuring expectations get aligned, a mock up can be used. Deliberately used to generate a spec.