Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Even with Agile and Scrum waterfall will sneak in

amazingcto.com

Post reply on HN
Print view View original

161–170 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#161

Post by nautilius »

lbriner wrote: post #116
sornaensis wrote: post #40

In my few years working as a dev, I am absolutely convinced that scrum and agile are the worst possible development practices you can have from the perspective of a developer, even though they are sold as 'developer centric' or that seems to be the impression a lot of people have at least. It makes no sense at all to me to constantly have work interrupted with customer meetings that produce NO concrete specifications…

It makes a lot of sense, which is why a lot of people follow it. Your comment is implying that somehow 1000s of people around the world don't realise they are doing something stupid. You are portraying a poorly run implementation of agile as the only way and then destroying it. We call it a straw-man. * My development team are rarely interuppted with customer meetings * The meetings we have will always have outcomes,…

I'm sure "It makes a lot of sense, which is why a lot of people follow it. Your comment is implying that somehow 1000s of people around the world don't realise they are doing something stupid." is exactly the comment that agile proponents heard when suggesting that waterfall may not be the right thing.

(not arguing for one or the other, just pointing out that this argument does not mean anything).

Re: Even with Agile and Scrum waterfall will sneak in

#162

Post by tyingq »

boffinAudio wrote: post #10

I'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 ste…

I've been doing this a long time. As far as I can tell, it comes down to senior leaders in software development wanting to make some sort of success story to further their own careers. It's much easier to buy into somebody else's canned success story plan. Hence the popularity of stuff like "Scaled Agile". Which is funny to me, because in practice, it's heavier than old school MS Project and Waterfall development. Even the diagram they use to summarize the concept is laughably undecipherable and complex[1]. Same reason companies latch onto 6-sigma, Clifton strengths, TOGAF, Total-Quality-Management, and so on.

I do recognize there is some actual "good stuff" in there. I'm a fan of the textual agile manifesto.

[1] https://19yko92jjsfl3euk0g1esoja-wpengine.netdna-ssl.com/wp-...

Re: Even with Agile and Scrum waterfall will sneak in

#163

Post by marcus_holmes »

xondono wrote: post #9

To 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.

this. I built a prototype, put it in front of the relevant users, gathered the next set of changes, and... have to wait for the next sprint to implement them (even though they will take about a day, tops) because we can't change a sprint halfway. How is this Agile?

Re: Even with Agile and Scrum waterfall will sneak in

#164

Post by allo37 »

zogomoox wrote: post #6

A 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!

Last place I worked tried to do SAFe (I think? They kept repeating it and had all the branding on the presentations). To me it seemed like the idea was to replace a dedicated project manager (or team of them) with a week-long meetingfest every 8 weeks where all the different teams tried to self-organize based on what the business' objectives were.

Apart from the colossal waste of time of those week-long "PI-planning" meetings, it was OK I guess...

Re: Even with Agile and Scrum waterfall will sneak in

#165

Post by mytailorisrich »

lelanthran wrote: post #156
mytailorisrich wrote: post #93

Earlier quoted context omitted.

There is no such quick feedback. 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…

> 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' 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…

It's not a misconception, it's the way it is, including in the paper that has been quoted in this thread.

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.

Re: Even with Agile and Scrum waterfall will sneak in

#166

Post by ben7799 »

I started working prior to Agile becoming a thing but wasn't around for the entirety of the 1990s. I have seen both waterfall and agile products fail or succeed. I don't think the process is ever to blame when they failed or deserves much credit when they succeeded.

My take on it is both processes have their strengths and weaknesses and perhaps a product needs to start Agile and slowly morph towards Waterfall as it matures.

Agile is great for the pre-1.0 phase when no one is sure what exactly the market needs yet and you're working on a software product with low cost to acquire customers. If you're iterating over different ideas trying to triangulate what is going to sell, and you don't need to scale yet before you figure out if you can sell it, then Agile has a great role to play. This is kind of risky startup time for sure though.

But when your product has become huge, mature, and you're signing $1M+ annual contracts with enterprise customers and your new features are getting very complex Agile doesn't work as well at that point as the tech debt it creates become more and more punishing as the project size grows, and the complex features become more and more difficult to fit into sprints without causing disasters. If a feature takes 6 months it can be a disaster to force it into 2 week sprints that just build tech debt in the name of being able to demo.

I've been on the current product I work on for about 8 years and have watched it morph from a pre-1.0 Agile product to a $500M+/yr complex product. We've been lucky to have good management and the process has gradually changed as the needs of the product have changed.

My career has mostly been enterprise B2B software... the best process for B2C, B2B, aerospace, military, etc.. is not necessarily going to be the same.

One thing for sure though is Agile has largely become a religion and less so of a pragmatic process as time has gone on.

Re: Even with Agile and Scrum waterfall will sneak in

#167

Post by [deleted] »

tyingq wrote: post #162
boffinAudio wrote: post #10

I'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 ste…

I've been doing this a long time. As far as I can tell, it comes down to senior leaders in software development wanting to make some sort of success story to further their own careers. It's much easier to buy into somebody else's canned success story plan. Hence the popularity of stuff like "Scaled Agile". Which is funny to me, because in practice, it's heavier than old school MS Project and Waterfall development. Ev…

[deleted]

Re: Even with Agile and Scrum waterfall will sneak in

#168

Post by Kim_Bruning »

boffinAudio wrote: post #121
pjc50 wrote: post #110

Earlier quoted context omitted.

> > You cannot analyse how users will empirically interact with a product that does not yet exist. > I don't agree with this, as I believe it is very, very glib This implies that all A/B testing is worthless, which is .. surprising.

> > You cannot analyse how users will empirically interact with a product that does not yet exist. You can certainly refine the software over time (A/B testing, if you will) to more closely attain the ideal, which you may not have well defined at the beginning of the project if you don't perform an adequate review of the needs of the user. But you can certainly also complete a user analysis that produces requirements…

Wait a minute, you're a proponent of iterative approaches? In modern parlance most people put under the heading "waterfall".

Can you specify which book/process/document(s) you are using in your day-to-day? This could be very interesting in future discussions with clients, to say the least!

Re: Even with Agile and Scrum waterfall will sneak in

#169

Post by g051051 »

WJW wrote: post #87
Scarblac wrote: post #53

Earlier quoted context omitted.

In Scrum, the team should be self-managing. The Product Owner and Scrum Master are not managers or bosses, they're a customer representative and a secretary. I can see that working with "people over process". But then came certification, existing managers et cetera and that was lost.

Many (most?) of the early Agile promoters were owners or partners in a consultancy doing work for clients. These clients often couldn't really specify in enough detail what they needed from the software that was to be built. In that scenario, the structures of Agile make a lot more sense. These days, when a company decides to start using some form of Agile methodology (usually scrum) they need to do something with th…

> Many (most?) of the early Agile promoters were owners or partners in a consultancy doing work for clients.

This is a huge point that people who weren't in the industry back then completely miss: The people behind the Agile manifesto weren't trying to figure out how to improve software development as a whole...they were looking for ways to improve their consulting business. What works for them as consultants selling consulting services doesn't make any sense for a company dev team trying to develop software.

Re: Even with Agile and Scrum waterfall will sneak in

#170

Post by dec0dedab0de »

boffinAudio wrote: post #10

I'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 ste…

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.

Doing that per issue is still basically agile. The problem is when you do it per project, and try to get everything right the first time, and then it's months or years between analysis and qualification.

Agile really boils down to starting small and keeping your stake holders involved. It is an explicit acknowledgement that programmers are bad at estimating time, and that users don't know how to ask for what they want.

All the stuff people complain about is just companies buying snakeoil, and overzealous organizers justifying their own jobs.

Post reply on HN