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

231–240 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#231

Post by SmellTheGlove »

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

I'm going to tell you up front that I'm a CSPO (certified scrum product owner), and that I don't exactly know. I don't mean this sarcastically - it's more that I'm not sure what agile/scrum fix, versus where would _any_ process change naturally cause an org to address its weak points. Example -

For a while I was pretty into scrum - the company I was at transitioned from waterfall and it did give the appearance of faster delivery. In hindsight, I think what it really did was provide explicit authority to a decision-maker (me, or the PO in general), and build a culture of keeping docs updated regularly, and therefore status visible/known. Waterfall didn't break these things, but in the past we were slow to unblock things and nobody really knew where the work was unless they went and asked (and had someone do an adhoc update).

I'm now at an org where a team that isn't mine is trying to be pretty strict about scrum, doing all of the requisite incantations and such. The issue is, they have more management than they do actual developers on the team. Adding this process on top makes the management happy, but it hasn't done a thing to boost anything related to development. It's exactly the cargo cult behavior you describe, when IMHO agile is best thought of as a toolkit that you borrow from selectively to fix the things that need fixing. I think going all-in isolates engineers from the people and processes they're trying to help and reduces them to basically short order cooks pulling tickets off the rack. I get that it's meant to make them more efficient, but I think that isolating your most expensive people whose job description says "solve problems" instead of having them engage directly is the wrong move.

Mind you, I don't think I'm necessarily right about everything but I've seen enough broken shit to know I'm not totally wrong either. Now as a fairly senior leader, I discourage my teams from going all-in on agile and push them toward looking at their process, identifying what's broken, and fixing that (with agile principles or not). It's rare that layering on more process has a positive effect and I like folks to be thoughtful about those changes.

Re: Even with Agile and Scrum waterfall will sneak in

#232

Post by Jtsummers »

allturtles wrote: post #228
dec0dedab0de wrote: post #170

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. Doing that per issue is still basically agile. The prob…

The thing I don't understand about agile is that many projects require a year+ investment before anyone will use it. e.g. say you're building a competitor to Google Docs. How do you get any real user feedback after < a year of work by a substantial team of engineers? No one is going to want to use your prototype that barely does anything. Or worse yet, your backend that doesn't even have a UI yet, and also barely doe…

In that case you don't have a customer, you have to dog-food it. Most of the time when agile references a customer, customer feedback, and customer interaction it's actually the customer contracting the work. That is a different context than a startup or video game developer or others because there is a clear customer stakeholder who can provide feedback and validation from the start.

This gets to part of the problem in all these discussions. The context that the Agile Manifesto was written in was not in creating Facebook or Google, but in creating software for a defined customer who held a stake in the outcome (had invested capital, along with wanting/needing the results). Once written, something like your Google Docs replacement can get a customer stakeholder, but they won't have it at the start unless you line up early users (and even then, they probably aren't invested).

Re: Even with Agile and Scrum waterfall will sneak in

#233

Post by ljf »

cube00 wrote: post #11
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 C-suite only hear "fast delivery" and ignore the other parts while also demanding the waterfall parts that suit the ways they need to work such as committing devs to deadlines one financial year out when funding bids have to be submitted. There is something ironic about being ordered to estimate a 12 month work order while also being told make sure "it's agile" and delivered on time and on budget by ++currrentYea…

Faster delivery should always be corrected to 'faster to fail'

Re: Even with Agile and Scrum waterfall will sneak in

#234

Post by LadyCailin »

allturtles wrote: post #228
dec0dedab0de wrote: post #170

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. Doing that per issue is still basically agile. The prob…

The thing I don't understand about agile is that many projects require a year+ investment before anyone will use it. e.g. say you're building a competitor to Google Docs. How do you get any real user feedback after < a year of work by a substantial team of engineers? No one is going to want to use your prototype that barely does anything. Or worse yet, your backend that doesn't even have a UI yet, and also barely doe…

In this case, you do user research with mock-ups and other extremely low effort prototypes. But the work done in that regard is the same for agile and waterfall. If you truly do have a project where the MVP will take a year, and the prototypes would be useless until that year is up, then it probably doesn’t matter which methodology you use in that first year.

Re: Even with Agile and Scrum waterfall will sneak in

#235

Post by WesleyJohnson »

devversthro wrote: post #226
Confiks wrote: post #140

Earlier quoted context omitted.

> If you can't formulate actionable requirements, you're (...) not the domain expert Yes, fine. So there is no (true Scotsman) domain expert. Grandparent's point is also just that actually building the application and seeing how users interact with it is a valid method of analysis either in a prototype phase or actual evolving production software.

Is it valid tho? Deploying an app to get feedback is totally backwards. Make an interactive demo with no-code tools, record it and iterate on that based on stakeholder feedback.

You're paying your most expensive employees to build something twice, and initially in a lower-fidelity tool that won't quite mimic the functionality or the look the of the final product. So you end up with stakeholders that don't understand it's just an interactive demo, and start wondering why things don't quite work. That or they buy into the demo, you build the real solution and then they're questioning why it doesn't quite work the same, or looks different, because when does an interactive demo in a mockup tool every really get it 100% right?

Re: Even with Agile and Scrum waterfall will sneak in

#236

Post by dekhn »

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…

in my 30 years of software development, everything has been a combination of waterfall and agile and projects that attempt to adhere to one or other strictly end up failing.

Re: Even with Agile and Scrum waterfall will sneak in

#237

Post by allturtles »

Jtsummers wrote: post #232
allturtles wrote: post #228

Earlier quoted context omitted.

The thing I don't understand about agile is that many projects require a year+ investment before anyone will use it. e.g. say you're building a competitor to Google Docs. How do you get any real user feedback after < a year of work by a substantial team of engineers? No one is going to want to use your prototype that barely does anything. Or worse yet, your backend that doesn't even have a UI yet, and also barely doe…

In that case you don't have a customer, you have to dog-food it. Most of the time when agile references a customer, customer feedback, and customer interaction it's actually the customer contracting the work . That is a different context than a startup or video game developer or others because there is a clear customer stakeholder who can provide feedback and validation from the start. This gets to part of the proble…

In that case, I have never worked in the context for which Agile was intended, and neither, I suspect, have a significant proportion of all working software developers. That may explain many of the disconnects in these conversations.

Re: Even with Agile and Scrum waterfall will sneak in

#238

Post by regularfry »

rubidium wrote: post #86
boffinAudio wrote: post #61

Earlier quoted context omitted.

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

It's more subtle than that. What "agile" does (both Scrum and XP, historically) is _protect the delivery team_. With waterfall-style project management, early errors balloon but often don't surface as something that needs addressing until implementation and testing, so the delivery team gets all the stress for blowing out the project schedule.

Agile techniques both surface those errors early, so they're course-corrected quickly, and provide a set of clear rules for the rest of the organisation to abide by which should mean that the delivery team can't get overloaded into a deathmarch.

Re: Even with Agile and Scrum waterfall will sneak in

#239

Post by doctor_eval »

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…

When I studied the SDLC formally, many years ago, “iterative waterfall” was called the spiral model.

Waterfall is not iterative. That’s the whole point. You go over the waterfall once. If you’re iterating then, by definition, it’s not waterfall.

> you can certainly also complete a user analysis that produces requirements, which when fulfilled, solve the problem in its entirety for the user

This is almost always false, for any non-trivial project, within the usual commercial constraints of money and time.

Re: Even with Agile and Scrum waterfall will sneak in

#240

Post by Jtsummers »

allturtles wrote: post #237
Jtsummers wrote: post #232

Earlier quoted context omitted.

In that case you don't have a customer, you have to dog-food it. Most of the time when agile references a customer, customer feedback, and customer interaction it's actually the customer contracting the work . That is a different context than a startup or video game developer or others because there is a clear customer stakeholder who can provide feedback and validation from the start. This gets to part of the proble…

In that case, I have never worked in the context for which Agile was intended, and neither, I suspect, have a significant proportion of all working software developers. That may explain many of the disconnects in these conversations.

Well, that's not the only case it was intended for. But the language around customers is colored by that context.
Post reply on HN