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

291–300 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#291

Post by jdlshore »

dtech wrote: post #71
ankurdhama wrote: post #60

Earlier quoted context omitted.

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

it's an old and widely accepted truism. I don't know how much formal research had been done into it.

Formal research into software development techniques tends to be junk. It's very very hard to conduct a meaningful study of professional-scale development. The costs are too high, the confounding variables too many, and the industry demand too low.

Typically you'll get software researchers with no industry experience conducting studies on "subjects of convenience"—their undergraduate programming classes.

Re: Even with Agile and Scrum waterfall will sneak in

#293

Post by imbnwa »

clairity wrote: post #227
cube00 wrote: post #11

Earlier quoted context omitted.

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…

yes, non-agile organizations try to bolt on agile at the 'bottom' of the hierarchy, and that's a sure recipe for failure because of the significant impedance mismatch that causes. the c-suite wants to hand down directives, and the agile teams want to listen to the customer first, leading to conflicting interests. an organization has to be receptive to turning the marketing function upside down (product being one of t…

In my mind, this sorta proves that most companies should not have in-house engineering divisions and instead most of us should be working for software engineering firms much like actual architects. This would likely also solve the career development/engineering pedagogy problem that is so lamented since firms would have better control over time internally.

Re: Even with Agile and Scrum waterfall will sneak in

#294

Post by drunkpotato »

bregma wrote: post #75
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…

Coders just want to code. Waterfall means you have to wait before you code, and plan, and organize. Agile means you just start coding, and code and code and code until you leave and someone else has to clean up the mess. This is no different than most other activities in life. See the Stanford marshmallow experiment.

I think this is half of it. From my experience, the other half is that "agile" is a wonderful excuse for managers and product managers not to have to plan anything or commit to any priorities, and for software companies not to hire project managers. I don't think this is particularly agile's fault; no process can fix broken organizations, and most tech organizations are broken. Luckily the magic money machine papers over grotesque inefficiencies so we can all be gainfully employed without having to become real professionals!

Re: Even with Agile and Scrum waterfall will sneak in

#295

Post by aahortwwy »

ziggus wrote: post #259
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…

Wait, are you saying that you started a company without a clear idea of what your product is, and if a market exists for it? Is that common in the software start-up world? If so, I can see how you'd need Agile processes, just to keep your VCs from heading to your offices with torches and pitchforks.

This is the basic idea behind the "lean startup" methodology. Seed VCs are totally on board with this strategy.

Re: Even with Agile and Scrum waterfall will sneak in

#296

Post by aahortwwy »

lmarcos wrote: post #246
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…

> make a total reset for version 2.0 and redo v 1.0 correctly. That's how I usually work (in personal projects). I wonder what it would take to convince management to do the same. In theory it should "just" duplicate the budget of any given project (which doesn't sound totally wrong). It sometimes happens to me, though, that I need to reach v3 in order to go back to v1. I just feel this way of doing software to be th…

> I wonder what it would take to convince management to do the same.

Build the redo time into your estimates.

Non-technical management has no concept of what's involved in building software. They don't need or particularly want to know. They care about things being "done." You don't need to convince them of anything, you just need to consistently and reliably show progress in a way that they can comprehend.

It's very irritating to see no progress for a month, then see a demo of something that appears to do everything you asked for, then hear that it won't be "ready" (whatever that means) for another month because the whole thing needs to be redone.

It's very reassuring to see demos every two weeks, each one showing an obviously incomplete product, but with clear progress between each demo culminating in a completed and delightful product after two months.

The actual development process for the two scenarios above can be exactly the same, it's just how they're messaged.

This is "managing up."

Re: Even with Agile and Scrum waterfall will sneak in

#297

Post by tharkun__ »

marcus_holmes wrote: post #163
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.

this. I built a prototype, put it in front of the relevant users, gathered the next set of changes, and... have to wait for the next sprint to implement them (even though they will take about a day, tops) because we can't change a sprint halfway. How is this Agile?

There's nothing preventing you from throwing it into the sprint. But then you gotta exchange it for something else you promised the customer at the start of your sprint.

And agile doesn't just mean Scrum and sprints. If your primary way of working is what you described and you are able to get this feedback within hours then Kanban (another agile way of doing things) might suit you better.

Re: Even with Agile and Scrum waterfall will sneak in

#298

Post by tharkun__ »

spookthesunset wrote: post #220
felipellrocha wrote: post #179

Earlier quoted context omitted.

That might be its stated goal, i still haven’t seen a single shop that actually implements that. First thing that happens when implementing agile are estimations, and the justification for that is for “predictability”.

To me it the estimates themselves don't really matter. Everybody already knows if something is gonna be worked on or not (at least kind of). The value I find from estimates is they encourage the team to discuss how something is gonna be built. The best moments are when everybody estimates that something is "easy" except for exactly one person who says "this is super hard". Then there is a discussion about what the "e…

Exactly!

The issue is when organizations or bad POs or SMs subvert this and make it all about estimating everything exactly in story points where everybody has to be on the same page on the fact that 2 story point means 2 person days of work. And that is the only thing that estimations are used for at these places and every team has the same scale and get compared on how many points they deliver each sprint. And they press the teams for estimating ever smaller.

That is the kind of environment that most of the devs that hate Agile or Scrum are living in and it's no wonder they hate it. It's completely against the spirit of Scrum and agile so we can't blame them. Unfortunately they blame agile which was a try to make things better for them.

Re: Even with Agile and Scrum waterfall will sneak in

#299

Post by earleybird »

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…

The best reference I have so far is from 1970[0].

Waterfall is page 2. Reading past pg 2 you will see attributes of agile and various techniques described. The one thing that comes to mind is the blind men and the elephant[1].

Quoting from the wikipedia link (which quotes another):

O how they cling and wrangle, some who claim

For preacher and monk the honored name!

For, quarreling, each to his view they cling.

Such folk see only one side of a thing.

[0] http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970... [1] https://en.wikipedia.org/wiki/Blind_men_and_an_elephant

Re: Even with Agile and Scrum waterfall will sneak in

#300

Post by tharkun__ »

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.

Story points are relative measures (at least when you do it 'right').

What is so different from estimating things as 1/2/5/8 or S/M/L/XL?

S (or 1) is roughly half as hard as M (or 2).

M (or 2) is roughly half as hard as L (or 5). Notice how 2 is not exactly half of 5. Just roughly.

And so forth.

And the point is that you can't say how many S are exactly equivalent to how many Ls. Estimates tend to get less precise the larger they are. There's usually more uncertainty built into large estimates which means once you do the work it might be much faster or much slower because of things you didn't look at very closely when estimating. While small things are easier to have a complete overview of and the estimates are more accurate.

A recent example from my work. There was something the team unanimously estimated as L. I knew it was an S. I knew the code though and they didn't. I let them put the L estimate on it. When the sprint started and I had some time I did the task myself and it really was an S in the end. But that's fine. They 'priced in' the uncertainty. If one if them had done it, it might very well have taken them longer because if not knowing the code as well.

Post reply on HN