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

261–270 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#261

Post by moksly »

baobabKoodaa wrote: post #251
moksly wrote: post #28

Most project models are sort of useless in the modern office environment. Waterfall is useless because nobody ever follows it. I agree that it’s sort of the “default” mode, but show me a project that didn’t go back and change something from a previous step. Agile stops working the moment you need to sign any form of contract with anyone, because nobody is going to sign a contract that doesn’t tell them what they are…

> Agile stops working the moment you need to sign any form of contract with anyone, because nobody is going to sign a contract that doesn’t tell them what they are going to get for X amount of money. Plenty of companies sign contracts like that, and it's not particularly controversial. Pay $X, get Y developers to work for T amount of time, with no guarantees what those developers are going to deliver.

Which companies? I’ve never seen anyone willing to do that in decades of contracting.

Maybe it’s just different here in Denmark, but people never buy things here without knowing what they buy.

Re: Even with Agile and Scrum waterfall will sneak in

#262

Post by corpMaverick »

ChrisMarshallNY wrote: post #214
felipellrocha wrote: post #179

Earlier quoted context omitted.

That might be its stated goal, i still haven’t seen a single shop that actually implements that. First thing that happens when implementing agile are estimations, and the justification for that is for “predictability”.

I do it properly, but I also usually work alone, or in very small teams. I have the luxury of setting the goals, and moving the goalposts, when needed (often). Waterfall is almost required, when you are crossing the streams. Merging separate workflows is a fraught process. You need to know what will be delivered, when. I spent most of my career, working for hardware companies, and saw this every day. Truly agile proc…

> You need to know what will be delivered, when.

It is valuable to have engineers who know how to decouple individual pieces to eliminate (reduce) these dependencies. These dependencies are almost guaranteed points of conflict and risk for the project.

Re: Even with Agile and Scrum waterfall will sneak in

#263

Post by tsimionescu »

boffinAudio wrote: post #89
pjc50 wrote: post #82

Earlier quoted context omitted.

> what problems Waterfall presented These are presented in the article. > Analysis, Specifications, Requirement These tend to be inadequate, incomplete, or .. > Qualification .. at this point the customer discovers that what they asked for does not actually solve their problem. You cannot do any kind of exploratory or innovative work in waterfall, because you can't specify that upfront. You can't easily co-evolve sol…

>> Analysis, Specifications, Requirement >These tend to be inadequate, incomplete, or .. >> Qualification >.. at this point the customer discovers that what they asked for does not actually solve their problem. I disagree. If you are properly isolating your work into an "Analysis" phase, you will properly flesh out the issues and the subsequent specifications and requirements will be complete - sufficient to the task…

If the Analysis has been done properly and we are sure that it has left no room for error, and if we demand similar quality from the Specification and other phases, then why do we need a Qualification phase at the end at all?

Conversely, if we accept that each phase is fallible so Qualification is crucial for any chance at a good working product, what is the recourse for errors in the Analysis phase? Basically if there was an error in the Analysis phase, we will, by definition, only find it in the Qualification phase, requiring us to scrap all of our work and start over from a new Analysis phase.

Re: Even with Agile and Scrum waterfall will sneak in

#264

Post by watwut »

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 reason everyone ends up doing waterfall is that it’s not the devs who you need to convince when selling agility

Nah, agile is pushed from top to bottom, whether developers want OT or not.

> Being agile means having no long term plan. If the C-suite can’t handle that, you’ll never be agile.

While the devs are mostly OK with no plan, they do tend to want some planning once it is completely absent.

What I see now is developers asking for damm analysis and documentation and C-suite not wanting to pay them. But it is really missing and we are wasting a lot of time due to not knowing the system.

Re: Even with Agile and Scrum waterfall will sneak in

#265

Post by ChrisMarshallNY »

corpMaverick wrote: post #262
ChrisMarshallNY wrote: post #214

Earlier quoted context omitted.

I do it properly, but I also usually work alone, or in very small teams. I have the luxury of setting the goals, and moving the goalposts, when needed (often). Waterfall is almost required, when you are crossing the streams. Merging separate workflows is a fraught process. You need to know what will be delivered, when. I spent most of my career, working for hardware companies, and saw this every day. Truly agile proc…

> You need to know what will be delivered, when. It is valuable to have engineers who know how to decouple individual pieces to eliminate (reduce) these dependencies. These dependencies are almost guaranteed points of conflict and risk for the project.

Tell that to a hardware manufacturer that is developing a camera, with firmware, three different processors, drivers, APIs, SDKs, host software, lenses, speedlights, marketing materials, packaging, distribution, documentation, etc., while coordinating manufacturing lines in three different countries, and engineering efforts in two.

It can get ... intense.

Re: Even with Agile and Scrum waterfall will sneak in

#266

Post by corpMaverick »

62951413 wrote: post #244
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 joined the industry only 20 years ago so missed the heyday of waterfall. I did witness the rise of the RUP though. And I must say that to jr developer me it was very educational despite its rather intimidating volume. There's one angle I don't see discussed in the last 10 years or so. There was a time when a lot of attention and literature was dedicated to software design. The whole OOP movement, design patterns, t…

I was never a fan of RUP. But it had the idea of adapting the process to the project. It gave you lots of choices.

With Scrum, every project is approached the same way, and no one thinks if it makes sense or not. McConnell´s "Rapid Development" also gives you alternatives for you to choose. Now days, it is Scrum or sometimes Kanban.

Re: Even with Agile and Scrum waterfall will sneak in

#267

Post by ziggus »

belter wrote: post #27
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…

You can't - Get Certified in Waterfall. - Claim to be a Waterfall Master. - Waterfall Standup sounds like a song.

Well, considering that Scrum Master certification can be done in a day, I'm not sure I'd be crowing about it.

Re: Even with Agile and Scrum waterfall will sneak in

#268

Post by rawgabbit »

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 any tasks required on the assembly line. But, the architecture Toyota uses, to enable this agility is limiting. For example, Toyota's TNGA architecture says there will only be five modular platforms to choose from; instead of the 100+ choices in the past [1]. Furthermore, Toyota is known for "boring" but reliable cars. It avoids all bleeding edge technology and prefers to make incremental improvements to its existing tech stack. That is to enable interchangeable workers; Toyota limits its car platforms and standardizes "cross cutting concerns".

Toyota Kaizen is diametrically opposite of agile in IT. Toyota standardizes, simplifies, and makes incremental changes to its tech stack. Agile in IT means ditching today's platforms/architecture/frameworks/toolsets and jumping on the latest fad du jour.

[1] https://en.wikipedia.org/wiki/Toyota_New_Global_Architecture

Re: Even with Agile and Scrum waterfall will sneak in

#269

Post by watwut »

Scarblac wrote: post #53
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.

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.

"The team" is not a living entity that can manage things. The team self managing means the most dominant person becomes dictator, until there is revolution or power struggle with another wanna be dominant. And occasionally mixed with "no one want to dominate" leading to incoherent direction.

Re: Even with Agile and Scrum waterfall will sneak in

#270

Post by tyingq »

kinbiko wrote: post #50
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. It's almost like scrum pre-dates the agile manifesto. (Which it does)

But the manifesto was written by many of the same people. The expectation that they would be compatible seems reasonable. And, the "Scrum Alliance" happened very shortly after the manifesto.
Post reply on HN