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

301–310 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#301

Post by aahortwwy »

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.

> done properly

"You're doing it wrong" is not a compelling argument.

A competent, motivated, invested, and empowered team don't need any particular methodology to succeed. Methodologies are adopted precisely because many people don't do things properly much of the time. A methodology which doesn't account for this and doesn't self-correct when done improperly isn't worth a whole lot.

Waterfall done properly produces great results. Agile done properly produces great results. Both of them produce bad results when done poorly. Proponents of one tend to compare their methodology done properly to alternative methodologies done poorly. That's a pointless conversation to have.

Re: Even with Agile and Scrum waterfall will sneak in

#302

Post by raihansaputra »

rawgabbit wrote: post #268
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…

I feel this is true, but more to the philosophical point. I remember reading an article where the Toyota factory employees are giggling because the American companies that try to study them are so obsessed about the actual manufacturing process instead of the central idea. To me, the central idea in Kaizen revolves around trust and flexibility instead of efficiency and "metrics" tracking.

This creates what seems to be opposing practices while in actuality is consistent. They abstract platforms, but have SWAT-like teams to provide custom tooling for the assembly workers for incremental improvements (Directly on the floor, 1y timeline). Every worker are encouraged to improve the process at least 2 times a month.

Another example of flexibility > efficiency is the Toyota practice of having flexible factories that's responsive to demand (to cover for peaks of certain models) instead of every factory has to be a hyper-efficient factory for select models[1]. Having buffer and flexibility (spare capacity) > fragile efficiency.

Software development can't map to assembly line, of course. Agile (the manifesto) maps very closely to the initial principle of trusting the developer and customer/user/domain expert and being flexible (deliver incrementally and iterate many times). Derivatives like Scrum seems to miss the point from me.

If you're interested to see how it works day to day in a modern manufacturing company, take a look at FastCap and their YouTube channel[2]. It seems obsessive around incremental improvements, but I think the Software industry need to take note and develop our own way to make the SDLC be less painful.

[0]: https://www.youtube.com/watch?v=o5GzHHE3udU

[1]: https://www.thedrive.com/tech/26955/inside-toyotas-takaoka-2...

[2]: https://www.youtube.com/watch?v=EqtKKkastWk

Re: Even with Agile and Scrum waterfall will sneak in

#303

Post by wheelinsupial »

Kim_Bruning wrote: post #168
boffinAudio wrote: post #121

Earlier quoted context omitted.

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

Wait a minute, you're a proponent of iterative approaches? In modern parlance most people put under the heading "waterfall". Can you specify which book/process/document(s) you are using in your day-to-day? This could be very interesting in future discussions with clients, to say the least!

You might be interested in [1]. Supposedly it has the diagram that became known as the "waterfall" diagram. I don't think the author is advocating for what we normally associate with waterfall, though, as there are some additional steps they advocate for. They start with a simplified model, criticize it, and then add some more complexity to the model.

Also to note, the paper is titled "Managing the Development of Large Software Systems."

The author outlines 5 steps they believe need to be used to improve the success of a project. One step is called "do it twice" in which the author advocates the development of a prototype well in advance of delivering the final product. I think this is iteration. It's not indefinite iteration, but it's definitely not showing the big bang single release waterfall approach either.

It also advocates to involve the customer throughout the process instead of only at the end.

The summary says to refer to Figure 10 as the process that incorporates the author's steps. This final diagram is pretty far from the simplified and flawed waterfall picture that has been pulled from the front of the document.

[1] http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...

Re: Even with Agile and Scrum waterfall will sneak in

#304

Post by Kim_Bruning »

wheelinsupial wrote: post #303
Kim_Bruning wrote: post #168

Earlier quoted context omitted.

Wait a minute, you're a proponent of iterative approaches? In modern parlance most people put under the heading "waterfall". Can you specify which book/process/document(s) you are using in your day-to-day? This could be very interesting in future discussions with clients, to say the least!

You might be interested in [1]. Supposedly it has the diagram that became known as the "waterfall" diagram. I don't think the author is advocating for what we normally associate with waterfall, though, as there are some additional steps they advocate for. They start with a simplified model, criticize it, and then add some more complexity to the model. Also to note, the paper is titled "Managing the Development of Lar…

Thank you!

Re: Even with Agile and Scrum waterfall will sneak in

#305

Post by pramodbiligiri »

ankurdhama wrote: post #60
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…

> Almost always, your customer doesn't know what they want - they think they do, but they don't I honestly don't understand this statement. Could you provide an example to elaborate on this point? I have read it at so many places but it sound more like the fashionable thing to say. The "need" have a starting point, may be a very high level problem statement, and then through analysis, back and forth question answerin…

Let’s say the high level problem statement is that a company needs to add a Search feature to their Store Inventory product.

Here are some questions that can arise during this course of this project:

1. What fraction of customers are asking for it, and how badly? How do you know their judgment is correct? What if people who aren’t asking for it may also go on to love it?

2. How deep and fast do you want the Search functionality to be?

3. How much time and money are you willing to invest in it? What if you find out after a month of work that Search is much harder than it looks?

4. Let’s say you discover there’s a bug in the indexing system which leaks personally identifiable information even though it’s supposed to hide it. Will you postpone the project till the bug is fixed, or work around it somehow?

It’s nearly impossible to answer these kind of questions right at the start of the project.

That doesn’t mean there aren’t projects where all the requirements are known upfront in precise detail. Usually that correlates with the associated technologies being very mature and their capabilities well understood by the people involved.

Re: Even with Agile and Scrum waterfall will sneak in

#306

Post by endymi0n »

the_other wrote: post #281
endymi0n wrote: post #256

Earlier quoted context omitted.

Fully agree, agile is fine. The real problem is that Scrum is not agile at all: Scrum is a fat "process" that enforces "following a plan" (regular, rigid meeting structure), "creating comprehensive documentation" (user stories, specs, mocks, task board) and "contract negotiation" (estimation meetings, planning poker). In that way, it's the exact opposite of the original agile Manifesto: http://agilemanifesto.org/ The…

> The real problem is that Scrum is not agile at all: Scrum is a fat "process" that enforces "following a plan" (regular, rigid meeting structure), "creating comprehensive documentation" (user stories, specs, mocks, task board) and "contract negotiation" (estimation meetings, planning poker). In that way, it's the exact opposite of the original agile Manifesto: None of those things are Scrum. Scrum talks about defini…

What you're describing sounds almost agile... joke aside, as I tried to point at, the original idea was pretty good, but it's certainly not what the snake oil people made of it and will sell you: https://www.scrumalliance.org/

The original Scrum also talks about servant leadership, when in reality in 99% of wannabe agile organizations, everything is just about enabling some manager's power trips.

I've found that most software development methodologies don't consistently work, mirroring https://news.ycombinator.com/item?id=15885171

Re: Even with Agile and Scrum waterfall will sneak in

#307

Post by baobabKoodaa »

moksly wrote: post #261
baobabKoodaa wrote: post #251

Earlier quoted context omitted.

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

I'm not at liberty to disclose company names, but I live in Finland and I can tell you it's normal here. It's basically equivalent to "renting" workers. I would be willing to bet that "rent-a-worker" industry exists in Denmark as well, and that it also includes IT work.

Re: Even with Agile and Scrum waterfall will sneak in

#308

Post by detaro »

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

It's totally normal to do software development contracts with agile processes, and well-understood how to structure them. Estimates also suddenly don't get better just because they're made fixed at the star, and at the same time agile doesn't mean "there is no plan where this is going at all".

Re: Even with Agile and Scrum waterfall will sneak in

#309

Post by ChrisMarshallNY »

dstroot wrote: post #243
iamflimflam1 wrote: post #30

Earlier quoted context omitted.

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…

https://www.halfarsedagilemanifesto.org/

I love that!

Thanks for sharing it!

- A refugee from the Corporate Machine

Re: Even with Agile and Scrum waterfall will sneak in

#310

Post by ineptech »

cpeterso wrote: post #275
ineptech wrote: post #221

Earlier quoted context omitted.

It really helps to use vague terms like S/M/L/XL or bike/car/plane or whatever. If you say an epic will take 6 months, it is very likely that in 3 months someone will ask for proof that you're halfway done.

But once you have abstract S/M/L/XL estimates for some tasks, what do you do with that information? How many S tasks are equivalent to 1 M task? If the team completed 3 M tasks and 3 S tasks last sprint, how does that help you plan for your next sprint? While story points have their own issues, at least tasks' relative size differences are clear and different tasks of different sizes can be scheduled.

You don't; you ease your executive/sales/etc partners into the new world where they get better software, faster features, and fewer outages, but they give up release dates and micro-managing the roadmap. Calling an epic "Large" instead of "237 story points" is a way of forcing yourself to accept that you only have a rough idea of how long it will take.
Post reply on HN