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

81–90 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#81

Post by dtech »

iamflimflam1 wrote: post #30
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.

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…

It's the next paragraph after those bullets:

> That is, while there is value in the items on > the right, we value the items on the left more.

Also keep in mind the manifesto came as a response to a "document-first" software design method, where basically the complete product was documented, planned and contracted before the first code was written.

Re: Even with Agile and Scrum waterfall will sneak in

#82

Post by pjc50 »

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…

> 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 solutions by discovering what works and what doesn't. You can't even do A/B testing really, because every time you do your GANTT chart bifurcates.

There is a history of big, spectacular IT project failures, often commissioned by the public sector, but not always. The evolution of non-waterfall systems has been driven by trying to prevent or mitigate these failures.

Re: Even with Agile and Scrum waterfall will sneak in

#83

Post by Scarblac »

boffinAudio wrote: post #68
Scarblac wrote: post #46

Earlier quoted context omitted.

> 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. I've never worked at a place where all these things a…

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.

Re: Even with Agile and Scrum waterfall will sneak in

#84

Post by ivanbakel »

boffinAudio wrote: post #56
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…

>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. This just indicates a failure to perform a proper Analysis/Speci…

>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 gather the "ideal requirements" when the project first starts, with enough due diligence - and also, that those requirements are fixed.

In my current job, we're producing a service that has to court a handful of very large clients. Even if there was a well-defined idea of what the service should eventually look like in 5 years, a lot of feedback is required to discover how it should look now. Which client needs more attention? Where is the biggest opportunity for additional value? How are users actually using the service, ignoring what they said they were going to do with it?

That last part is the most important - requirements are in reality a feedback process for which the existing product is one input. You cannot analyse how users will empirically interact with a product that does not yet exist. Abstract analysis is no substitute for data.

Re: Even with Agile and Scrum waterfall will sneak in

#85

Post by pjc50 »

boffinAudio wrote: post #59
hamasho wrote: post #45

Earlier quoted context omitted.

Additionally, as a start-up, we rarely know what the product should be. We have a first vague idea of the product but don't know what it exactly is. Commonly, the ideal product is different from the initial design, and we only know that after the actual design, investigation and development. If it's the nature of software development, the development framework should be capable of design change in short terms. Agile…

"Agile" just means "analyse the situation until you have properly fleshed out specifications, great requirements that will solve the problem as described, and a proper plan for development". Still, "Analyze until Completion" doesn't need to be couched in fancy new-age terms that someone will get paid to teach everyone ..

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?

The absolute extreme example of this is of course SpaceX: classical control systems theory can't quite deliver a hoverslam landing that works first time, so they had to iterate by crashing rockets.

Re: Even with Agile and Scrum waterfall will sneak in

#86

Post by rubidium »

boffinAudio wrote: post #61
Iv wrote: post #23

Earlier quoted context omitted.

I was once explained the interest of quick iteration cycles (the main opposition, IMO, to a waterfall model) in a simple way: The teacher drew a very simple chart : y = t. "This is, in a given project lasting from t=0 to t=1, the amount of practical information that you have about how to design this project. At t=1.0, you have 100% of the information. When you start, you have about zero information about it, just gue…

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

This. If you properly understand the problem. If your team is compact enough to be in the same room. And your customer input during concept/requirement writing is high.

If you stray outside that, both waterfall and agile struggle… but waterfall has the potential fatal flaw of delivering a product no one wants (or doesn’t work).

This is why agile was introduced. There were software products being made that ended up just not working… so people saw that problem and tried to fix it with agile. But agile just fixes the “don’t deliver a product that doesn’t work” problem.

Re: Even with Agile and Scrum waterfall will sneak in

#87

Post by WJW »

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.

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 the people who were previously managing the team and so they often assign them the Product Owner role or something similar.

Obviously, the power balance between such a manager (who often retains power over raises and promotions as well) and a line employee team member is completely different than the power balance between a Product Owner as representative of a company and a team of consultants who together own their own consultancy business. Doubly so if the consultants have many more clients and don't exclusively depend on this one Product Owner to pay their bills.

Re: Even with Agile and Scrum waterfall will sneak in

#88

Post by Chyzwar »

There are even companies selling scrumfall consultancy known as SAFE.

In my experience, there are few problems with agile.

- scrumfall that is mostly cause by stakeholders wanting to have yearly roadmaps and KPI tied to delivery of increment. Plenty of organizations have separate engineering and product orgs that create this disconnect.

- groomorgy when teams spend more time on analysis than actual work. Driven by middle managers thinking that doing less is better than not finishing the sprint in time. Middle managers that do not understand tech or business but can track progress of tasks.

- cost-amnesia When feature is build over many increments is hard to estimate total cost and long term maintenance cost. You might have teams re-inventing a wheel and having a massive amount of slowly rotting code.

- conway-architecture. Because people think that agile is all about small independent teams, it naturally leads to service oriented architecture. In many places, SOA is a bad fit problem or organization. Small company with limited resources doing micro-somethings will create death trap.

- teflon-promotions You will have teams and projects doing terribly over a longer period of time, but in initially phase they delivered value. You will see people promoted in the organization based on early wins, even if they left behind dead bodies. It often encourages tech dept over long term maintenance.

I still feel that agile is great. Most of these problems are people problems, not agile itself.

Re: Even with Agile and Scrum waterfall will sneak in

#89

Post by boffinAudio »

pjc50 wrote: post #82
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…

> 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 of formulating a development/implementation plan. But if you don't take care to complete a proper analysis - then no, you won't formulate specs or req's properly, either.

The important thing is that the individuals involved know the value of a proper analysis - whether they are developers or managers or just paying the bills. Too often, software developers don't realize that they are really providing a social service, and thus they don't deliver proper analyses that can result in action. Alas, that is something other than a tooling/methodology issue and lays more in the motivations of the developer.

Its a lot easier to say you can't be responsible for the mess as a developer if you don't allow the mess to be adequately described, in the first place .. so the Agile vs. Waterfall debate is really more of an ethics issue than anything else.

Good developers do Waterfall Complete. Mediocre developers do it, and call it Agile. Terrible developers find excuses for not doing the key things, and end up with a failed project on their hands.

Re: Even with Agile and Scrum waterfall will sneak in

#90

Post by rubidium »

pjc50 wrote: post #82
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…

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

Your comment is the most accurate assessment of the history. It’s good for people to know.
Post reply on HN