This is why I hate agile, it's incredibly stressful. Daily stand ups to justify your last 24 hours, affirmations in said stand ups which must begin with "Yesterday I committed to... and did/did not achieve this because..." followed by "By this time tomorrow I commit to delivering....".
JIRA burn down charts dropped in our group chat to "remind us" to keep following the planned burn down line, looking for stories we can close out to try and sneak the chart to match the line and somehow try and catch up after they're closed. It's horrible.
Take for example your metion of standups: They are really valuable, and are not meant to "justify" your last 24h - but some managers think that this is the case, i.e. make sure your developers are not slacking and surfing on hacker news all day. Instead, one of the purposes is to detect blockages in any way. I mean if a dev takes very long for a task without it being justified (i.e. no other developer would understand why it would take so long), it might just be due to lack of skill and the dev might need some more training or senior assistance. It could also be that the task is more difficult than originally anticipated, in which case the team should possible act on it and change the scope etc. Sometimes it could also be a very eager junior dev, who just doesn't want to admit struggling with something out of pride or even fear etc. As a developer I can totally say, it actually takes quite some guts to come out in a group of devs and freely admit: "Hey, I struggle with that task, I don't know what I am supposed to do, or am not familiar enough to debug that code, can somebody help me on this?" - but admitting that you are not perfect is something lot of people struggle, especially juniors as they think they must be capable of doing everything.
Ahh, good old cargo cult Scrum.
I've seen a bunch of this when consulting. People use all the right terms, but nothing else really makes sense. There is a "daily standup" done sitting down and it lasts up to 45 minutes. There are "sprints" that last from 2 to 12 weeks with no deliverables. There is grooming, which is just chatting and maybe looking at Jira a bit.
Scrum can be done right, but it requires the WHOLE organisation to be trained to do it properly. Preferably by a very very very expensive Scrum Consultant so that even the C-staff put some weight in their words. (expensive == good)
99% of the time this is an underhanded way to implement micromanagement.
AFAIK not only was that never a claim/scope of agile, but rather the opposite is deliberately accepted with agile: You accept quite some overhead during development, plan for constant refactors, shift of scope etc. The justification is, that while waterfall in theory is the most efficient and productive, in practice you very often end up with a product that doesn't fit your customers/users need. So working 2years on a product that is thrown away in the end and started over is less efficient and more expensive than working 3years on it in an agile way and getting (mostly) what you want in the end.
Note that is the one of the reasonings of agile, I am not claiming that these statements and premises have actually proven true in the real world.
The downsides are that it opens up the team to feature-creep, introduced a pile of weird buzzwords, and can be massively wasteful if the team doesn't want it and it's forced on them.
Doesn't Waterfall incorporate feedback? In my memory and experience, it does.
My memory of learning Waterfall back in the early 90s is a bit hazy, but I distinctly remember that one of the advantages touted was that mistakes earlier in the process of developing software are cheaper to fix than mistakes later in the process (no matter what the process is).
Finding an error when drawing up the requirements is orders of magnitudes cheaper to fix than finding an error after piloting at the client.
As I remember it, Waterfall was taught (to me) as a way to avoid developing the wrong product, or a product that does not meet the requirements of the end-user (sound familiar?)
My SDLC textbooks from back then were filled with different ways to elicit requirements, because fixing broken requirements after the product was developed was (and probably still is) bloody expensive.
In the same way, fixing bugs during a test phase is a lot cheaper than after a deployment phase (hence various types of testing were introduced by the textbook).
Fixing bugs during a pilot phase is a lot cheaper than after a full deployment, hence piloting was in the textbook as well.
Agile aims to deliver features one sprint at a time. Waterfall aims to deliver the specified system as a whole or not at all. Which one works better is probably contextual, but I cannot see either one being unconditionally better than the other.
Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile. Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too.
Well that makes sense with my belief that WF aims to "deliver the system as a whole or not at all". There's no point in delivering an MVP G2A missile system that is not complete.
> Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too.
To be sure, CI/CD pipelines make the fixing of bugs in the code cheap enough to simply deploy when you can. However, bugs in the specification aren't going to be cheaply fixed after deployment, and these are much more common[1] and hard to get correct than any other type of bug.
[1] I.e. the code does exactly what the programmer intended it to, but what the programmer intended it to do is different to what was needed.
>Well that makes sense with my belief that WF aims to "deliver the system as a whole or not at all". There's no point in delivering an MVP G2A missile system that is not complete.
True! :)
Plus, the customer knew pretty much what they wanted from the start. Not much chance they watch the demo and then ask if it can be mounted to an airplane…
> To be sure, CI/CD pipelines make the fixing of bugs in the code cheap enough to simply deploy when you can. However, bugs in the specification aren't going to be cheaply fixed after deployment, and these are much more common[1] and hard to get correct than any other type of bug.
Yes, though in the agile model the idea is that the spec is just what the customer asked for two weeks ago (or whatever your sprint length is), after seeing how the program worked at that time. If there’s a misunderstanding and you correctly implemented the wrong thing, then the cost is at most the two weeks you spent on it.
You spend months dreaming up a design spec with plenty of timing diagrams, UML diagrams, classes, etc.
Then, it's reviewed, which means people read it and and try to make comments on it, then everyone pat themselves on the back because it's been 'signed-off'.
Then you start actually implementing it and you quick find out that, actually... And that's not even accounting for any changes on requirements that might have been asked in the mean time.
Feedback means actual, hard feedback, be it from the customer or reality.
Errors get more and more expensive to fix the further down the line they are found and that's exactly why hard feedback (which usually is either actual tests or customer feedback) should be obtained ASAP, which can be achieved through iterations.
>
> Then, it's reviewed, which means people read it and and try to make comments on it, then everyone pat themselves on the back because it's been 'signed-off'
I'm sure that happens, but I'm not commenting on what happens, I'm commenting on the Waterfall process as I remember it being taught in the 90s. What yysay above is definitely not what was taught.
> Feedback means actual, hard feedback, be it from the customer or reality.
Yeah, which is what the Waterfall process that I remember advocated: that the end-user be involved at all times, that the design be refined iteratively and quickly, and that the requirements.
I'm not sure where this misconception of what Waterfall advocates came from, but you're not the only one with it.
For instance, "Step 2: document the design" advocates extensive documentation upfront.
Of course there is feedback but the loop is very large and slow, and the paper emphasises that feedback ought "to be confined to sucessive steps", which, in addition is problematic when requirements change mid-way.
Agile is trying to solve a real issue with the waterfall model in general and, especially, when requirements are fluid.
No, by definition. Do you see a stream of water back to the beginning of waterfall in any waterfall on the planet? Nope.
[1] http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...
I did a few projects in waterfall style about 20+ years ago, but my memories are faint. Our PM used a UML modeling tool to model classes and relationships, then exported it into Java. We wrote a lot of useless documentation. I developed a good habit to write documentation immediately, when memory is fresh, to avoid the pain of writing it later.
You can actually tell that the methodology was developed for a different time period, when you would have to schedule time in order to run your program on the mainframe, instead of just hitting build on your machine.
Ex: Testing reveals a corner-case that was never accounted for in the design. You can't just re-code, you have to go back up and redesign, then code the new design, then retest.
Royce's recommendations to minimize these problems are a) more and better design, and b) more and better documentation
In contrast, the Agile approach is to try to slice the work into finer and finer tasks, so these same activities can span a few sprints. It works in the small, but loses the forest for the trees.
I'm not referring to real waterfalls[1], I'm referring to the Waterfall Software Development Process, which is an iterative process that requires almost constant feedback.
[1] Real waterfalls certainly do have the water returning to the top of the fall, only it's not as a stream and it's not immediate :-)
If you’ve never seen a project that wasted its entire time in the scoping and planning phase (and not produce anything), then you’ve never seen how bad waterfall can get.
With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. This means a longer lead time to working software and to any sort of feedback, and usually a waste of time in the docs/specs phase. Even trying to write a whole perfect spec before doing any coding prevents you from benefiting from the practical feedback that comes from actually doing.
For some types of software this works mostly fine, but others not so much. Hence why most methodologies since then have feedback loops and try to make then small.
IMHO sprints are not to pressure (though the name may not be well chosen in that respect) but to enforce small-ish iterations rather than spending 6 months developing something in isolation.
(see my reply above, for some context and why I might be wrong :-).
My recollection of Waterfall is that there is always an "acceptance" phase at the end of every "fall"[1] - IOW, there is a sign-off by the stakeholders that what's in the phase is correct.
So your requirements are engraved in stone, your test protocol is engraved in stone, and your UAT is engraved in stone, and your "pilot performance acceptance" is engraved in stone.
If it turns out there is an error in any one of the phases above then that error, and that error alone, is signed off on and goes through all the phases (or "falls"?) again. Since this is more expensive the further in the falls the error is, there is pressure to get as much sign-off as possible for any issue before that issue proceeds to the next phase.
[1] I like the word "fall" to describe each phase of waterfall :-) I'm going to start using it more often and see if it catches on.
No, Waterfall is bad precisely because of the inherent unpredictability of a given project.
Never in all of history was a large software project speced out and built on time.
Software lives in a dynamic environment, so the process has to be mutable.
Maybe the answer is not 'Agile', but it's definitely 'agility'.
If we set longer term term, rounded goals, but with smaller iterations, then there's a possibility, but not a big Waterfall.
Why we should use something else, more complex, instead of Waterfall, for a single sprint? Waterfall is good enough and predictable enough for a 2-week sprint.
Yes, the result of a single waterfall will be bad, we plan for that, but accumulation of knowledge will lead us to success.