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

111–120 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#111

Post by zoomablemind »

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

What do Developers do before it's a green light for them to start the dig? What do Designers do before it's "their step"? What do they do afterwards? What about those in preceding stages?

Well, they might as well do whatever else next that falls on their seats, but sure everyone still cares to see the "final output", that is the developed and tested product. Yet it's inevitable for them to switch their context to something else meanwhile.

And this detachment is what makes Waterfall process often protracted and resistant to change. Not speaking that there's also a Customer somewhere in that pipeline, hoping to derive some value and feed some form of input.

Some industries/companies/teams/products may be just ok with waterfall or no methodology at all. Other situations may want shorter cycle or even parallel efforts to stay in line with demand/constraints/risks.

Also, there's a "working software" factor too. Call it a PoC/proto/early demo... It not only tests the ideas, it also motivates to keep going or offers assurances that it will be done "right".

If anything natural there is to any process is that most professionals want to do their jobs well and be proud of their effort, preferrably rewarded for the success and not singled out for blame of failures.

The question is then how to create such an environment to make that possible.

Agile on not, what cargo-cults it is the general lack on internal vitality in some industries/companies/teams/products. And as such it affects the very professional values on all levels, eroding the collective "care" about the result or even the process itself.

Re: Even with Agile and Scrum waterfall will sneak in

#112

Post by LaundroMat »

pmoleri wrote: post #76
littlecranky67 wrote: post #18

Earlier quoted context omitted.

The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn't know what they want - they think they do, but they don't and will only realize this after you finished development and have a visible system demo/field test. Additionally it is really hard for project management to get metr…

I consider fleshing out customer requirements part of the engineering process. You cannot expect the customer to properly communicate what they want/need. That doesn't mean Scrum, you have many other tools at your disposal, presenting the customer with scenarios to challenge their requirements, use interactive prototypes or even paper ones. All of them far cheaper than implementing the wrong thing. I agree about the…

I'm inclined to think a PoC (or whatever you want to call it) would be useful for some things: - a tangible and cheap way of showing the customer how you think you can solve their problem - getting concrete feedback on that solution (you're both talking about the in same, tangible thing) - using it as a foundation for the "big" project. Not its code, but the ideas behind its UX, flow, treatment of data, whatever is the main crux of the solution can be made tangible in a PoC and be used as a reference for the next step, ie making a production-worthy application - the PoC can also show that what the customer wants is in fact a bad idea.

Re: Even with Agile and Scrum waterfall will sneak in

#113

Post by pjc50 »

boffinAudio wrote: post #104
pjc50 wrote: post #85

Earlier quoted context omitted.

In startup land, it's often quicker to ship software than analyze, and this tends to win in the market. The "analyze" worldview assumes that the easiest and most accurate format for the output of an "analyze" process is some natural language text and maybe diagrams and a powerpoint or two. What if the friction of authoring software was reduced to the point that the easiest output of "analyze" was .. working software?…

>What if the friction of authoring software was reduced to the point that the easiest output of "analyze" was .. working software? Well, the software world is certainly working hard - on one side - to reasonably attain this goal, while another big portion of it actively resists this advancement in human social services, such that it represents. Perhaps that is the key thing to all of this: "Until all of us are using…

> actively resists this advancement in human social services,

> "Until all of us are using waterfall, many of us will have a hard time using waterfall.

Now you've lost me, I've no idea what you're talking about with the first statement and the latter just sounds like cultism? People have valid reasons for iterative processes!

Re: Even with Agile and Scrum waterfall will sneak in

#114

Post by boffinAudio »

yread wrote: post #97
boffinAudio wrote: post #89

Earlier quoted context omitted.

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

Of course no one is doing the Analysis properly. It's impossible. You plan how to implement something using a library method. But only in the qualification phase you find out that this method actually has a bug on your target platform or is incompatible with another part of your software.

I dunno, I've seen many, many examples of a properly done Analysis phase. But it does require a great deal of competence, a lack of hubris, and plenty of self-doubt/verification/validation on the part of technical contributors to make sure they do actually know what they're talking about .. a Qualifications step usually reveals the nature of this impact on the project - or lets just say, omitting this step is usually the first part of project failure.

Re: Even with Agile and Scrum waterfall will sneak in

#115

Post by boffinAudio »

Scarblac wrote: post #83
boffinAudio wrote: post #68

Earlier quoted context omitted.

Developers who fail to take responsibility for the full workflow, fail. Its not "Agiles" fault, although this is often used to justify the failure. Developers have got to realize that they are responsible for the full workflow from beginning to end , and only poor/low-quality developers will work to change that natural law - with negative effect.

Imo analysis needs domain knowledge, the developer can do it on their own but it won't be as good as when a domain expert does. A developer doing their own QA will have the same blind spots as during development. And of course, if he was also doing the analysis, he'll have the same blind spots as during analysis.

Yes, waterfall is a team activity, as all software is necessarily a social service. Developers that fail to understand this - or indeed, resist it as part of their cultural identity - usually get taught this lesson hard in the form of failed projects.

Re: Even with Agile and Scrum waterfall will sneak in

#116

Post by lbriner »

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, even if those are high-level "would this be possible?" * Everything is not expected to be done "just-in-time" "on a whim", it is simply a case of allowing the highest priorities to be looked into in much shorter cycles.

* "Dev whiplash". Nope, not here. Poor architecture and tech debt? I haven't seen any more in the agile projects I have worked on compared to old waterfall projects.

* Tens of people who don't have any role. Nope

* Non-dev/product running meetings? Nope. Shouldn't happen and if it does, it's nothing to do with agile (or waterfall!)

* Borderline abusive?

Re: Even with Agile and Scrum waterfall will sneak in

#117

Post by fer »

lbriner wrote: post #95
boffinAudio wrote: post #61

Earlier quoted context omitted.

Waterfall can be fast. In fact, done properly, it is the fastest technique of them all.

> done properly And herein lies the rub. If a project is more than 6 months to a year in duration, there is very little chance that what the customer now wants is what they wanted before. Requirements aren't created instantly on day 1 ready for dev, you could easily have several years of requirements, during which time people change, the world changes, the law changes, priority changes and then what? Even systems tha…

> If a project is more than 6 months to a year in duration, there is very little chance that what the customer now wants is what they wanted before.

Depends largely on the customer. Just do anything defence, related to aircraft, or industrial control systems, more often than not, requirements are set in stone, and modifications require approval and consequent fees.

Now, those industries throw a lot of money at actual R&D to know what requirements can be requested, which is very different from your usual software shop, where "R&D" is some brief talk during refinement or at most a dedicated user story to look into the subject.

Re: Even with Agile and Scrum waterfall will sneak in

#118

Post by LaundroMat »

boffinAudio wrote: post #101
ivanbakel wrote: post #84

Earlier quoted context omitted.

>This just indicates a failure to perform a proper Analysis/Specification/Requirements phase, with relevant qualifications steps. It doesn't matter if you're a Manager or a lowly Developer - if you can't adequately qualify the requirements and specifications, the analysis is simply not complete. But that view of requirements is not borne out by the reality for most projects. You're presuming that it's possible to gat…

If you can't formulate actionable requirements, you're either not the domain expert, or not communicating properly with the domain expert. What your service looks like now and what it looks like in five years are obviously two different questions, but a proper analysis will divide the issue between now and 5 years from now and come up with requirements that fill the gaps. This doesn't mean things get set in stone and…

"Software is a social service - rigid developers who cannot put on the user hat, are not providing the most intrinsic aspect of that service in their field."

All the more reason not to rely on the proper wearing of a user hat (how are you going to know, by the way?), but actually work with the users instead and spend time creating the necessary artefacts to capture their perspective as soon and as well as possible.

Re: Even with Agile and Scrum waterfall will sneak in

#119

Post by drran »

jollybean wrote: post #51
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…

??? It's predictability. You can plan the construction of a building, because the elements are known. If someone fails to deliver a bag of nails on time, it won't matter. If you add labour to a project, it will very ballpark accelerate linearly. 1 team, 10 houses = 10 weeks, 2 teams 10 houses, = 5 weeks. Ballpark. More developers do not mean the software will be finished more quickly. There are economies of focus in…

> 1 team, 10 houses = 10 weeks, 2 teams 10 houses, = 5 weeks. Ballpark.

Concrete needs 4 weeks to cure.

Re: Even with Agile and Scrum waterfall will sneak in

#120

Post by xondono »

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)

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.

Post reply on HN