Live data from Hacker News

Even with Agile and Scrum waterfall will sneak in

amazingcto.com

21–30 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#21
I find that waterfall comes with technical certainty.

Waterfall is disastrous with erroneous technical certainty, if the customer is convinced that the solution is technically clear and yet there is still uncertainty then what will happen is that a number of good components will be developed and delivered all of which are useless.

If you can communicate (you must) the uncertainty and the potential branch points in your project then one of two things happens:

- it stops (often) because the client does not have any appetite for risk. This is painful, but it is better than the car crash of a failed waterfall (which is what is going to happen). The opportunity cost for the team and you is very high here - kill it now and get something viable.

- you go to agile and make it stick.

As soon as you are certain about the solution the design is frozen and you can plan effectively for delivery. This is now waterfall and everyone is happy.

Re: Even with Agile and Scrum waterfall will sneak in

#23

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

Then another line : y = 1-t. "And this, is the amount of design freedom you have during the project. At the beginning, everything is possible but at the end, big changes can not be made."

"This is what we call the curse of project management."

It has really be enlightening. Make prototypes, be courageous enough to scrape entire designs, and when you have the resources for it : make a total reset for version 2.0 and redo v 1.0 correctly.

Of course, this is highly subject dependent. You don't build a bridge the way you build an experimental robot, but this explained well the interest of non-waterfall models.

Re: Even with Agile and Scrum waterfall will sneak in

#24
post #2

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…

> As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity.

This is why I hate agile, it's incredibly stressful. Daily stand ups to justify your last 24 hours, affirmations in said stand ups which must begin with "Yesterday I committed to... and did/did not achieve this because..." followed by "By this time tomorrow I commit to delivering....".

JIRA burn down charts dropped in our group chat to "remind us" to keep following the planned burn down line, looking for stories we can close out to try and sneak the chart to match the line and somehow try and catch up after they're closed. It's horrible.

Re: Even with Agile and Scrum waterfall will sneak in

#25
post #6

A version of this is Scaled Agile (SAFe) which somehow manages to combine the worst of both worlds. If you see your organization preparing to go SAFe, run!

I misread your comment and thought you wrote "best of both worlds" and embarked on a rebuttal! One of the places I am working at is now ditching SAFe, because they have recognised the issues. The process as implemented there both burns vast amounts of time and is widely ignored. OUTSTANDING!

Re: Even with Agile and Scrum waterfall will sneak in

#26
post #2

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…

> Agile doesn't magically make people more productive

AFAIK not only was that never a claim/scope of agile, but rather the opposite is deliberately accepted with agile: You accept quite some overhead during development, plan for constant refactors, shift of scope etc. The justification is, that while waterfall in theory is the most efficient and productive, in practice you very often end up with a product that doesn't fit your customers/users need. So working 2years on a product that is thrown away in the end and started over is less efficient and more expensive than working 3years on it in an agile way and getting (mostly) what you want in the end.

Note that is the one of the reasonings of agile, I am not claiming that these statements and premises have actually proven true in the real world.

Re: Even with Agile and Scrum waterfall will sneak in

#27

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.

Re: Even with Agile and Scrum waterfall will sneak in

#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 going to get for X amount of money. Its processes are sort of fine on the smaller scale because it breaks project tasks into neat to-do-lists, but it’s utterly useless for actual project management because estimates are a lie and delivering on time is what is required to drive a project successfully.

Then there is everything in between from the various stage-gate models to UP and what not, and they are all equally useless because nobody ever really follows them and because they can’t really apply to every type or project which is what organisations tend to want.

I haven’t worked in a FANG or whatever you call the big American tech companies, but I have worked in the European Public sector and it’s affiliated private sector companies for years, and nobody has a magic project model in my experience. In many ways the most successful companies tend to be the ones who simply use some sort of Kanban board and refrain from giving estimates in intervals lower than weeks. I fully understand why organisations waste resources on this area of course, I’ve been in the trap myself many, many times and I’ll likely end up in it again, but the simply truth is that every project manager or business process person that you have is one less developer, and these helper functions don’t really add anything to your value chain the moment they start making up work for the sake of having the “right” processes in place. The best way to handle project management is to hire good developers who know how to deliver projects that are build safely and maintainable. That’s not easy, but no amount of project management is going to make up for the lack of them.

And I’m not saying you shouldn’t need project managers or have an organisational strategy, but if you’re hiring more support staff for your developers than you would for the tradesmen you’d hire to build your house then I think that you’re doing management wrong.

We build an entire city hall, a process that took almost a thousand different employees from very, very, differently ones of work and we did it with 1 project manager, 1 architect and 10 lead engineers. We did it on time and under budget, and that is how we build our IT projects as well. It’s sort of waterfall, because it’s what we default to like the author gets into, but maybe that’s because it works?

Re: Even with Agile and Scrum waterfall will sneak in

#29
I'm just wrapping up an Agile project, truly agile, and it was actually quite fun. At the start they tried to get us to use Scrum and 2 week sprints and I pushed back. We had basically no fixed meetings except a weekly sync and a couple of weekly meetings with stakeholders.

In the first 2 weeks we were producing analysis of whether we should do the project at all and my week has been pretty much 20% meetings with product since then and it has been fantastic. We used JIRA but only as a log of tasks, sometimes we were asked to report up some more detailed estimates so we made a rought Gantt chart type plan, but otherwise we've been left alone. We've done the project in a way that truly matches the agile manifesto. And we're only a week or so past the original estimate in a 3 month project, so pretty on-track.

It just reinforces for me that Business Agile is a load of crap[0].

[0]: https://d22qefpbdavdoz.cloudfront.net/#agile-is-hell

Re: Even with Agile and Scrum waterfall will sneak in

#30
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 documentation

The problem with this is you now have people who don't like writing documentation claiming that agile says "You shouldn't write any documentation" or "I don't need to comment my code as the agile manifesto says you shouldn't"...

* Customer collaboration over contract negotiation

This does not say "you should not have a contract".

* Responding to change over following a plan

People interpret this as "We shouldn't plan anything. If you are planning then you aren't doing agile".

Post reply on HN