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

271–280 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#271

Post by oraphalous »

gumby wrote: post #242
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.

> Being agile means having no long term plan. Bingo, and there lies its power — but only in the correct domain. For consulting, where the customer doesn’t quite understand what they need and you need to work your way forward in an exploratory fashion (and for a limited period) it’s great. And that was the environment it was designed for! You have a multi year engineering project? Really a waterfall, or a waterfall/sp…

> You have a multi year engineering project? Really a waterfall, or a waterfall/spiral approach will work.

I'm not sure a long time frame is a necessary condition for a successful waterfall project - but I am certain it is not sufficient.

What you need - long term project or not - is a rock solid understanding of business requirements. That means - no vague client demands, or startup style search for product / market fit - but a well established, and documented set of business processes that needs to be mapped to code.

I also believe such projects require a leader who has this understanding, but also a talent for product design such that they can recognise and articulate clearly how the product will meet requirements. They need to be able to convince stakeholders.

I do think such circumstances are rare for many organisations. But not so rare the prospect should be dismissed out of hand.

I agree with your final statement though I think the challenge for many orgs would be in having the self awareness to recognise which approach is best for them.

Re: Even with Agile and Scrum waterfall will sneak in

#272

Post by corpMaverick »

dstroot wrote: post #243
iamflimflam1 wrote: post #30

Earlier quoted context omitted.

Indeed - the principals of the manifesto are very easy to read: https://agilemanifesto.org/ and https://agilemanifesto.org/principles.html The problem is people take the main points and use them to justify their own wants and needs. These are the main points: * Individuals and interactions over processes and tools This does not say you should not have any processes and tools. * Working software over comprehensive doc…

https://www.halfarsedagilemanifesto.org/

Now I am curious about the background image. And a little disappointed that there is no principle page.

Re: Even with Agile and Scrum waterfall will sneak in

#273

Post by greatgib »

When I read in this article "but we build things that no one wanted in the first place or no longer wanted", then I know that this goes has not a clue of what he is talking about, but just want parrot buzz world.

Otherwise, I agree that waterfall and scrum both sucks!

Re: Even with Agile and Scrum waterfall will sneak in

#274

Post by the_other »

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.

> The whole thing is about processes, and tools (jira)… the complete opposite.

I don’t know how you can read the Scrum guide and get to that comment.

JIRA is not Scrum and vice versa.

The Scrum system is barely a system: 2 lists; 3 roles; 4 meetings; an exhortation to continually adjust (aiming at improvement); a recommendation you measure; guidance to include the “client” fairly often. That’s about it.

This JIRA thing is just one tool among dozens of optional options. Use scraps of paper if it suits you.

Re: Even with Agile and Scrum waterfall will sneak in

#275

Post by cpeterso »

ineptech wrote: post #221
fknorangesite wrote: post #212

Earlier quoted context omitted.

> First thing that happens when implementing agile are estimations I'm usually the first to chime in that all estimates are lies, but small estimates (i.e., per-issue, not per-project) easier than big ones.

It really helps to use vague terms like S/M/L/XL or bike/car/plane or whatever. If you say an epic will take 6 months, it is very likely that in 3 months someone will ask for proof that you're halfway done.

But once you have abstract S/M/L/XL estimates for some tasks, what do you do with that information? How many S tasks are equivalent to 1 M task? If the team completed 3 M tasks and 3 S tasks last sprint, how does that help you plan for your next sprint? While story points have their own issues, at least tasks' relative size differences are clear and different tasks of different sizes can be scheduled.

Re: Even with Agile and Scrum waterfall will sneak in

#276

Post by MikeDelta »

geekbird wrote: post #245
xondono wrote: post #120

Earlier quoted context omitted.

I know, but it’s not how it’s sold. The typical presentation is “we need agility => Scrum”. One would assume that if Scrum doesn’t fit the bill, one would discard it.

But, unfortunately, scrum has become synonymous with "Agile" in the corporate mind. Everything, including SRE and ops work, gets force-fit into Jira "Agile" (really FrAgile) methods and meeting-heavy rituals. But scrum easily devolves to rapid cycle waterfall death marches. This has been going on for at least nine years that I know of. It sucks. When a company says "We do Agile with Scrum" I wince and am very, very s…

And add DevOps to it, because then one can get rid of run == cost savings.

Re: Even with Agile and Scrum waterfall will sneak in

#277

Post by dragonwriter »

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.

> To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum.

You don't. I mean, literally, the relationship is inverted: Scrum predates Agile; the creators of the former later went on to contribute to the Agile Manifesto.

> Being agile means having no long term plan

No, it doesn't.

Re: Even with Agile and Scrum waterfall will sneak in

#278

Post by cpeterso »

boffinAudio wrote: post #109
drran wrote: post #80

Earlier quoted context omitted.

Agile is just 20-30 small waterfalls instead of big one. How small a waterfall needs to be to fail?

Honest opinion: Its not a matter of size. Its a matter of completeness . Agile or waterfall processes fail if you omit the Qualification step, or if you don't ensure that the analysis produces actionable requirements, or clearly formulated specifications that lead to requirements, user/technical/or otherwise.

That Qualification step was the challenge I had when working on scrum projects in the past. I might finish implementing a feature in the current sprint #1, but QA won't get to start testing until sprint #2. When QA inevitably finds bugs, when do I fix the bugs? Should I have reserved an unknown amount time in sprint #2 for bug fixing? Or should I schedule time in sprint #3 to fix those bugs? If so, then the separate implementation/QA/bug fixing stages are each adding extra latency.

Re: Even with Agile and Scrum waterfall will sneak in

#279

Post by phkahler »

>> Waterfall kills iterations because everything needs to be finished the first time for waterfall to work.

Well, if you look at some presentations on waterfall you see the big V and there are loops where testing feedback goes back to the left side. What happens is that A) some slides don't show that, and even if those loops are present, B) The V is flattened vertically into a timeline by some manager and the loops are lost.

Re: Even with Agile and Scrum waterfall will sneak in

#280

Post by CoolestBeans »

rawgabbit wrote: post #268
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.

>>> "Being agile means having no long term plan." I believe the angst against agile is it doesn't have a definitive viewpoint but is a reaction against what it sees as the evils of waterfall. Without definite processes, we get scrum. From my viewpoint, the issue is that scrum has a flawed understanding of Toyota Kaizen which it based itself on. Yes, in a Toyota factory, team members are expected to be able to perform…

The conservative Toyota you're describing is the Toyota that exists today, not the one that developed the Toyota Production System in the first place. Maybe they weren't bleeding edge but their engines had fuel injection, variable valve timing, and were computer controlled. Meanwhile the American automakers' idea of "futuristic" was putting LCD screens in the dash and making the cars talk when you left the door open. Through the 1980s and 1990s Toyota was putting out cars like the original LS 400 which embarrassed the German luxury automakers, the supercharged MR2, the turbocharged Supra, and high revving Celica, all while making cheap but great econoboxes. Its really in the 2000s where Toyota switches to an "only conservative cars" business model when the Toyota developed sports cars disappear, engines start staying mostly the same, and generations get longer.
Post reply on HN