Even with Agile and Scrum waterfall will sneak in
amazingcto.com
Even with Agile and Scrum waterfall will sneak in
1–10 of 319 posts
Re: Even with Agile and Scrum waterfall will sneak in
#2Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity.
Re: Even with Agile and Scrum waterfall will sneak in
#3Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…
Agile (if the culture incentivises honestly) does have the benefit of feedback. Rather than a black-box which "could" be done in a month, you can instead see that the team on-average under-estimates by 10 days, has x stories left, so it'll likely be done in 2-3 months at this rate.
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.
Re: Even with Agile and Scrum waterfall will sneak in
#4Agile fails not because of the engineering side of the house but because the business can't "get it", and just ignores it...seen this too many times to count across many different biz domains.
Re: Even with Agile and Scrum waterfall will sneak in
#5Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…
I don't think it's any issue of individual raw productivity. It's about not wasting that work by focussing on building exactly what the customer wants as fast as possible.
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.
Re: Even with Agile and Scrum waterfall will sneak in
#6A version of this is Scaled Agile (SAFe) which somehow manages to combine the worst of both worlds. If you see your organization preparing to go SAFe, run!
Re: Even with Agile and Scrum waterfall will sneak in
#7The extremes were bad, not the essence of the idea. Stay lightweight and you can have the best of everything.
When anything is non-trivial to implement, i.e. it has dependencies, then it benefits from _some_ waterfall planning. Meaning to think before the work begins about the approach being taken, all of those dependencies, and who you need to engage and when... tada, you've made a GANTT chart in your head and are now waterfall because you put some thought into the dependencies and the order of execution.
Within that, each epic / task can be SCRUM or agile or whatever... all you really need here is an idea of a "definition of done", to prioritise the work so that you hyper-focus on just doing what needs to be done to get you to done. You probably want to continuously remind yourself of those priorities... tada, you've created an agile process.
The names are irrelevant, understand the essence of project / program management and do the least you can do execute on that.
It's when the processes become formal, tooled up, etc... this is when the worst creeps in. The status meetings for middle management, the reporting of time to project management tools. But no-one has to do this, lightweight project management can work without any of this stuff.
Re: Even with Agile and Scrum waterfall will sneak in
#8Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…
Agile (if the culture incentivises honestly) does have the benefit of feedback. Rather than a black-box which "could" be done in a month, you can instead see that the team on-average under-estimates by 10 days, has x stories left, so it'll likely be done in 2-3 months at this rate. 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…
> Agile (if the culture incentivises honestly) does have the benefit of feedback.
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.
Re: Even with Agile and Scrum waterfall will sneak in
#9To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum.
The whole thing is about processes, and tools (jira)… the complete opposite.
The reason everyone ends up doing waterfall is that it’s not the devs who you need to convince when selling agility, is the chain of command. Being agile means having no long term plan. If the C-suite can’t handle that, you’ll never be agile.
Re: Even with Agile and Scrum waterfall will sneak in
#10I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory.
There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated/verified with a Qualification step, and then it gets released to the end user/product owner, who sign off on it.
This is a natural flow of steps, and it always appears to me that the new-fangled developer cults are always trying to 'prove' that these aren't natural steps, by either cramming every step into one phase (we only do "Analysis" and call it Scrum) or by throwing away steps (Qualification? What's that?) and then wondering why things are crap.
Too many times, projects I've seen fail could've been saved if they'd just gotten rid of the cult-think.
Its nice, therefore, to see someone else making the observation that Waterfall is a natural process and all the other -isms are just sugar/crap-coating what is a natural consequence of organizing computing around the OSI model - something that has been effective for decades now, and doesn't need improvement-from-the-youth antics.