4 ms·

Lately it feels like agile is where innovation goes to die :(

doctor_eval 6y ago
I agree. It’s sad. Agile principles are awesome, but by the time you run them through many company’s implementations of Scrum or SAFe or (God forbid) Jira, you may as well just do waterfall. I don’t think waterfall is necessarily bad, that agile is always right, or that there aren’t other good practices. But practicing waterfall and calling it “agile” is rarely going to end well for anyone.
- ayyy 6y ago
  Ah, not to worry. Modern agile is just waterfall, but with shorter timelines to maximize overhead costs and minimize productivity. It makes sense when you realize that we pay employees for days to elapse.
- donkeyd 6y ago
  Two weeks ago I heard a colleague say: "I'm a scrum master in a waterfall project". That was my last week at that IT consulting company and really confirmed my choice to switch to a career with more purpose.
  - cardinalfang 6y ago
    Is that a euphemism for unemployed?
- pjmlp 6y ago
  Waterfall is actually agile, if one bothers to read the original paper properly, regardless of its bad name.
  - cyberdrunk 6y ago
    The whole idea of waterfall as I know it is to have large-ish iterations (typically a couple months), which comprise of analysis, dev and testing stages. Is this different from what you have in mind?
    - pjmlp 6y ago
      That is page one of the waterfall document, there are other pages though. https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a-big-misunderstanding-from-the-beginning-reading-the-original-paper/ https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a...
- raihansaputra 6y ago
  I have a hunch that one of the reasons "Agile" becomes ruined is the complexity of the stack most teams are using. IIRC, the stories/tasks were originally meant to be able to be completed by anyone on the team with little help from specialists/others within a reasonable time (..including UI?). When the Frontend Engineer needs to wait on Design, coordinate with Backend (ex: discussing API), or even wait for the S3 bucket to be up, mini-waterfalls will be the easiest path to take.
- ClikeX 6y ago
  We do Scrum at my office. But really, it's just applying sprints to waterfall. We do get some shorter feedback loops to improve features before going live. But the whole scope is still set at the start of the project, and that scope needs to be completed at the end of it. And to be very honest. It doesn't work if the people in the team don't think Agile. Your team needs to be able to self-reflect and try to improve themselves just as they'll do with client work in a sprint.
  - crdrost 6y ago
    I mean it is a ️️hot-take but I don't regard scrum as any sort of subset of agile. Rather scrum emerged when big companies wanted to basically do what they were already doing, but call it agile. A framework emerged to teach these companies a “safe word” rendition of agile, don't worry it's only agile until you say “banana.” You cannot appoint somebody to the strange title of “scrum master” (which I guess makes the rest of us scrum slaves?) to lead a process of “daily scrum” where we look together at a kanban board and make sure that we are “sprinting” and then turn around to insist that you value “individuals and interactions over processes and tools,” which is ¼ of the Manifesto. You have voted with your intention and your vote was to value your process and tools over trusting the individual developers and letting them have direct interactions with your customers. Even the word “sprint.” I used to play Ultimate in one of the teams in the Dutch national league, it is a sprinting sport. The word “sprint” means exhaustion. It means stopping. If you jog around in Ultimate you lose, you have to rest, sprint, rest, sprint. If your model is “always sprinting” then do not tell me that you value “individuals and interactions.” And if you do value the latter please either (a) remove the metaphor “sprint” from your process or (b) add “rest weeks” after each sprint to “clean up” the mess you made! Anything else is lying to yourself. The phenomenon of estimating “story points” is even worse, no? It is intrinsically about processes and tools and the idea of a developer having a phone call or face-to-face with the client directly to see if this feature request is actually accurate, deciding that it is not, and trashing it to open a different request... it's not just “do we claim those juicy story points when this happens?” but also “was part of your measure of ‘complexity’ the complexity of determining that the Ask did not meet the Need?” ...And so the fundamental idea of estimating a “todo” does not fit well with agile, whereas you can estimate “in progs” and “done” just fine. And before you say “no by the time we estimate we should already know that we want the feature, devs should never have to talk to clients,” please be aware that this response explicitly abdicates another ½ of the Agile manifesto, “customer collaboration over contract negotiation” and “responding to change over following a plan.” The whole point of the Agile manifesto is that your kanban board is stale. Not because it's a kanban board, but because it is written down. Like one of the four principles (the last ¼ not covered in the above ¾) is explicitly anti-literary. This is sort of “no true Scotsman” of me but my read is that the moment Agile was systematized, it died a little on the inside. It was a “screw your systems!” reaction that then got steamrollered by the real world, where “bullshit jobs” and middle management reign even though they bespeak a bureaucratic feudalism rather than a lean-and-mean capitalism.
bigiain 6y ago
Nobody needs too "innovate" another stupid CRUD app though... I kinda feel all the _actual_ innovation is doing things that align with Agile's underlying principals of valuing individuals/working-software/response-to-changes over processes/documentation/plans - while all th3e people who _talk_ about doing "Agile" rarely follow those principals, and mostly just mean "We have meetings we call 'standups', and negotiated deadlines that we call 'sprints'".

I agree. It’s sad. Agile principles are awesome, but by the time you run them through many company’s implementations of Scrum or SAFe or (God forbid) Jira, you may as well just do waterfall. I don’t think waterfall is necessarily bad, that agile is always right, or that there aren’t other good practices. But practicing waterfall and calling it “agile” is rarely going to end well for anyone.

ayyy 6y ago
Ah, not to worry. Modern agile is just waterfall, but with shorter timelines to maximize overhead costs and minimize productivity. It makes sense when you realize that we pay employees for days to elapse.
donkeyd 6y ago
Two weeks ago I heard a colleague say: "I'm a scrum master in a waterfall project". That was my last week at that IT consulting company and really confirmed my choice to switch to a career with more purpose.
- cardinalfang 6y ago
  Is that a euphemism for unemployed?
pjmlp 6y ago
Waterfall is actually agile, if one bothers to read the original paper properly, regardless of its bad name.
- cyberdrunk 6y ago
  The whole idea of waterfall as I know it is to have large-ish iterations (typically a couple months), which comprise of analysis, dev and testing stages. Is this different from what you have in mind?
  - pjmlp 6y ago
    That is page one of the waterfall document, there are other pages though. https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a-big-misunderstanding-from-the-beginning-reading-the-original-paper/ https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a...
raihansaputra 6y ago
I have a hunch that one of the reasons "Agile" becomes ruined is the complexity of the stack most teams are using. IIRC, the stories/tasks were originally meant to be able to be completed by anyone on the team with little help from specialists/others within a reasonable time (..including UI?). When the Frontend Engineer needs to wait on Design, coordinate with Backend (ex: discussing API), or even wait for the S3 bucket to be up, mini-waterfalls will be the easiest path to take.
ClikeX 6y ago
We do Scrum at my office. But really, it's just applying sprints to waterfall. We do get some shorter feedback loops to improve features before going live. But the whole scope is still set at the start of the project, and that scope needs to be completed at the end of it. And to be very honest. It doesn't work if the people in the team don't think Agile. Your team needs to be able to self-reflect and try to improve themselves just as they'll do with client work in a sprint.
- crdrost 6y ago
  I mean it is a ️️hot-take but I don't regard scrum as any sort of subset of agile. Rather scrum emerged when big companies wanted to basically do what they were already doing, but call it agile. A framework emerged to teach these companies a “safe word” rendition of agile, don't worry it's only agile until you say “banana.” You cannot appoint somebody to the strange title of “scrum master” (which I guess makes the rest of us scrum slaves?) to lead a process of “daily scrum” where we look together at a kanban board and make sure that we are “sprinting” and then turn around to insist that you value “individuals and interactions over processes and tools,” which is ¼ of the Manifesto. You have voted with your intention and your vote was to value your process and tools over trusting the individual developers and letting them have direct interactions with your customers. Even the word “sprint.” I used to play Ultimate in one of the teams in the Dutch national league, it is a sprinting sport. The word “sprint” means exhaustion. It means stopping. If you jog around in Ultimate you lose, you have to rest, sprint, rest, sprint. If your model is “always sprinting” then do not tell me that you value “individuals and interactions.” And if you do value the latter please either (a) remove the metaphor “sprint” from your process or (b) add “rest weeks” after each sprint to “clean up” the mess you made! Anything else is lying to yourself. The phenomenon of estimating “story points” is even worse, no? It is intrinsically about processes and tools and the idea of a developer having a phone call or face-to-face with the client directly to see if this feature request is actually accurate, deciding that it is not, and trashing it to open a different request... it's not just “do we claim those juicy story points when this happens?” but also “was part of your measure of ‘complexity’ the complexity of determining that the Ask did not meet the Need?” ...And so the fundamental idea of estimating a “todo” does not fit well with agile, whereas you can estimate “in progs” and “done” just fine. And before you say “no by the time we estimate we should already know that we want the feature, devs should never have to talk to clients,” please be aware that this response explicitly abdicates another ½ of the Agile manifesto, “customer collaboration over contract negotiation” and “responding to change over following a plan.” The whole point of the Agile manifesto is that your kanban board is stale. Not because it's a kanban board, but because it is written down. Like one of the four principles (the last ¼ not covered in the above ¾) is explicitly anti-literary. This is sort of “no true Scotsman” of me but my read is that the moment Agile was systematized, it died a little on the inside. It was a “screw your systems!” reaction that then got steamrollered by the real world, where “bullshit jobs” and middle management reign even though they bespeak a bureaucratic feudalism rather than a lean-and-mean capitalism.

bigiain 6y ago

Nobody needs too "innovate" another stupid CRUD app though... I kinda feel all the _actual_ innovation is doing things that align with Agile's underlying principals of valuing individuals/working-software/response-to-changes over processes/documentation/plans - while all th3e people who _talk_ about doing "Agile" rarely follow those principals, and mostly just mean "We have meetings we call 'standups', and negotiated deadlines that we call 'sprints'".