6 ms·

Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature fac

Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product won't prioritize refactorings, and sprints are too short for devs to sneak refactoring into the schedule.

anon1m0us 7y ago
I was explicitly told not to write unit tests because they took too much time, which required me to spend entire days retesting almost 100 scenarios when the business logic changed. Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.
- wpietri 7y ago
  As you've discovered, good automated testing is mandatory for iterative development. If execs tell you to do something unprofessional, it's ok to say no. Indeed, if we're going to think of ourselves as professionals, I think it's mandatory.
  - Chris2048 7y ago
    > if we're going to think of ourselves as professionals We need to unify around these principles, possibly revoke memberships for unprofessional behavior. One dev getting himself fired changes nothing..
    - wpietri 7y ago
      I'd love to see that kind of organizing happen. But one developer quitting rather than do bad work does change something. At the very least, it means that the developer can find another, better job. But it's also an opportunity for companies to learn. And for those who don't, good people refusing to prop up bad companies is a step forward. I'd also add there's a a lot that can happen between refusing to do bad work and quitting/getting fired. Saying no is the beginning of a negotiation. A negotiation that won't happen if we just say yes all the time.
- hinkley 7y ago
  All straight out of the TDD playbook. A lot of devs trap themselves by insisting they can write the tests after. Once managers know the code exists they want to use it, or move on to the next thing people are breathing down their necks for. And code written without tests is difficult to test so becomes a self fulfilling prophecy. In fact it’s such a reliable mechanism for self sabotage that I look at carefully at people who bring this on themselves and try to figure out if it’s naïveté, learned helplessness, or malice.
icedchai 7y ago
The biggest problem with Scrum is it lacks any sort of design phase. You do the minimum. Oh, it doesn't work quite right? We'll fix it in the next sprint... The "spiral" model is closer to a true iterated waterfall. I've seen it used successfully in more mature companies.
- taneq 7y ago
  It's like "build one to throw away", in that the goal is to rapidly explore the feature space and discover useful features, but what actually happens is that it's a trap and you won't throw away something that works no matter how poorly implemented.
  - diydsp 7y ago
    absolutely. If you ever see a group afraid to produce a prototype, it's because they're afraid management will try to ship it as a final product. The effective strategy is to build an oblique, fatally limited prototype, which can not possibly be mistaken for a shippable product. The bad prototype can only be used to test the hardest parts of an idea and must have major holes in it with no way of filling them. It should also have a largely fixed timeline to ensure it is put to bed before it gets "hamstered" into the shipping product.
    - postfacto 7y ago
      absolutely. If you ever see a group afraid to produce a prototype, it's because they're afraid management will try to ship it as a final product. I once had a manager who, on the subject of upper management wanting to ship the prototype, would say “the difference between dev and prod is one letter.”
- binaural 7y ago
  I completely agree here. Instead of understanding the volatility of the requirement(s) and designing for that, we refactor and react.
- wpietri 7y ago
Aeolun 7y ago
Scrum is unsuited to actually building a decent framework for you application. We tend towards 4 or 5 sprints in which nothing is completed, only to suddenly have a flood of completed things the next.
- wpietri 7y ago
  Then that's not an Agile process. That sounds more like mini-waterfall. It's perfectly possible to deliver small units of work weekly. One still gets frameworks while doing that. It's just that the work of making the framework happens over time, not up front. Which is good, because good designs are based on good information, and the beginning of the project is when you have the least information.
closeparen 7y ago
>I think it works well enough, for a few years. "Fortunately," hardly anyone in Silicon Valley plans to be working on the same codebase in a few years. There's a good chance the problem space won't be relevant anymore by then, and on the off chance it's still funded, the new team will rewrite it whether or not it's good. >sprints are too short for devs to sneak refactoring into the schedule. As I've gotten more senior, I've just gotten more brazen about doing this less sneakily.
- BlueTemplar 7y ago
  Is the Silicon Valley representative of software development though ? Because on the other hand we have professors telling us that the average (surviving?) software lifetime is 20 years...
  - pandapower2 7y ago
    This is just intuition but I suspect that the lifetime for software is u shaped. Much of it is very short lived but software that lasts more than 1-2 years is very likely to live for a decade or more. A lot of 6 month old code gets thrown away either because its been rewritten or because it didn't achieve its stated objective. Meanwhile a bunch of companies are relying on systems that were first created in the 90s because that software achieves its objectives and the cost justification for a rewrite isn't there.
    - z3t4 7y ago
      There are many 20 years and older code bases currently. But if you start a new code base today it might get rewritten many times in the next few years because software users no longer have the power to stay on an old version due to the SaaS paradigm.
dragonwriter 7y ago
> Scrum is iterated waterfall. No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iterations. > munching through backlog items fed to them by product managers. That's...not actually Scrum, as it implies that either the role of Product Owner is taken by a PM outside of the Scrum Team or that that the Scrum Team is not self-organizing, either of which is a significant (even if common) deviation from Scrum. > the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future Tech debt should manifest in reduced velocity which should be noticed, taken as a signal of a process defect, and addressed in the Scrub Team’s various inspection and process adjustment points. OTOH, if the Scrum Team is properly cross-functional and self-organizing instead of having a non-team-member imposed as Product Owner, then including appropriate restarting as components of completion of relevant backlog items shouldn't be a problem.
- wpietri 7y ago
  What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"? And could you point me to examples of people losing their Scrum certifications for not living up to that standard?
  - yellow_postit 7y ago
    This is the great con of scrum certification — you can always point to some team and say “well that’s not the official version of scrum”
    - wpietri 7y ago
      Which is a really impressive con. Generally the point of certification is to make clear you're getting the official version. E.g., doctors and lawyers self-police because they know it's harmful to have quacks running loose. But somehow Scrum has been able to keep making money despite not bothering with that.
deleted 7y ago
[deleted]

anon1m0us 7y ago

I was explicitly told not to write unit tests because they took too much time, which required me to spend entire days retesting almost 100 scenarios when the business logic changed. Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.

wpietri 7y ago
As you've discovered, good automated testing is mandatory for iterative development. If execs tell you to do something unprofessional, it's ok to say no. Indeed, if we're going to think of ourselves as professionals, I think it's mandatory.
- Chris2048 7y ago
  > if we're going to think of ourselves as professionals We need to unify around these principles, possibly revoke memberships for unprofessional behavior. One dev getting himself fired changes nothing..
  - wpietri 7y ago
    I'd love to see that kind of organizing happen. But one developer quitting rather than do bad work does change something. At the very least, it means that the developer can find another, better job. But it's also an opportunity for companies to learn. And for those who don't, good people refusing to prop up bad companies is a step forward. I'd also add there's a a lot that can happen between refusing to do bad work and quitting/getting fired. Saying no is the beginning of a negotiation. A negotiation that won't happen if we just say yes all the time.
hinkley 7y ago
All straight out of the TDD playbook. A lot of devs trap themselves by insisting they can write the tests after. Once managers know the code exists they want to use it, or move on to the next thing people are breathing down their necks for. And code written without tests is difficult to test so becomes a self fulfilling prophecy. In fact it’s such a reliable mechanism for self sabotage that I look at carefully at people who bring this on themselves and try to figure out if it’s naïveté, learned helplessness, or malice.

icedchai 7y ago

The biggest problem with Scrum is it lacks any sort of design phase. You do the minimum. Oh, it doesn't work quite right? We'll fix it in the next sprint... The "spiral" model is closer to a true iterated waterfall. I've seen it used successfully in more mature companies.

taneq 7y ago
It's like "build one to throw away", in that the goal is to rapidly explore the feature space and discover useful features, but what actually happens is that it's a trap and you won't throw away something that works no matter how poorly implemented.
- diydsp 7y ago
  absolutely. If you ever see a group afraid to produce a prototype, it's because they're afraid management will try to ship it as a final product. The effective strategy is to build an oblique, fatally limited prototype, which can not possibly be mistaken for a shippable product. The bad prototype can only be used to test the hardest parts of an idea and must have major holes in it with no way of filling them. It should also have a largely fixed timeline to ensure it is put to bed before it gets "hamstered" into the shipping product.
  - postfacto 7y ago
    absolutely. If you ever see a group afraid to produce a prototype, it's because they're afraid management will try to ship it as a final product. I once had a manager who, on the subject of upper management wanting to ship the prototype, would say “the difference between dev and prod is one letter.”
binaural 7y ago
I completely agree here. Instead of understanding the volatility of the requirement(s) and designing for that, we refactor and react.
wpietri 7y ago

Aeolun 7y ago

Scrum is unsuited to actually building a decent framework for you application. We tend towards 4 or 5 sprints in which nothing is completed, only to suddenly have a flood of completed things the next.

wpietri 7y ago
Then that's not an Agile process. That sounds more like mini-waterfall. It's perfectly possible to deliver small units of work weekly. One still gets frameworks while doing that. It's just that the work of making the framework happens over time, not up front. Which is good, because good designs are based on good information, and the beginning of the project is when you have the least information.

closeparen 7y ago

>I think it works well enough, for a few years. "Fortunately," hardly anyone in Silicon Valley plans to be working on the same codebase in a few years. There's a good chance the problem space won't be relevant anymore by then, and on the off chance it's still funded, the new team will rewrite it whether or not it's good. >sprints are too short for devs to sneak refactoring into the schedule. As I've gotten more senior, I've just gotten more brazen about doing this less sneakily.

BlueTemplar 7y ago
Is the Silicon Valley representative of software development though ? Because on the other hand we have professors telling us that the average (surviving?) software lifetime is 20 years...
- pandapower2 7y ago
  This is just intuition but I suspect that the lifetime for software is u shaped. Much of it is very short lived but software that lasts more than 1-2 years is very likely to live for a decade or more. A lot of 6 month old code gets thrown away either because its been rewritten or because it didn't achieve its stated objective. Meanwhile a bunch of companies are relying on systems that were first created in the 90s because that software achieves its objectives and the cost justification for a rewrite isn't there.
  - z3t4 7y ago
    There are many 20 years and older code bases currently. But if you start a new code base today it might get rewritten many times in the next few years because software users no longer have the power to stay on an old version due to the SaaS paradigm.

dragonwriter 7y ago

> Scrum is iterated waterfall. No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iterations. > munching through backlog items fed to them by product managers. That's...not actually Scrum, as it implies that either the role of Product Owner is taken by a PM outside of the Scrum Team or that that the Scrum Team is not self-organizing, either of which is a significant (even if common) deviation from Scrum. > the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future Tech debt should manifest in reduced velocity which should be noticed, taken as a signal of a process defect, and addressed in the Scrub Team’s various inspection and process adjustment points. OTOH, if the Scrum Team is properly cross-functional and self-organizing instead of having a non-team-member imposed as Product Owner, then including appropriate restarting as components of completion of relevant backlog items shouldn't be a problem.

wpietri 7y ago
What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"? And could you point me to examples of people losing their Scrum certifications for not living up to that standard?
- yellow_postit 7y ago
  This is the great con of scrum certification — you can always point to some team and say “well that’s not the official version of scrum”
  - wpietri 7y ago
    Which is a really impressive con. Generally the point of certification is to make clear you're getting the official version. E.g., doctors and lawyers self-police because they know it's harmful to have quacks running loose. But somehow Scrum has been able to keep making money despite not bothering with that.

deleted 7y ago

[deleted]