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

241–250 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#241

Post by regularfry »

spookthesunset wrote: post #219
bastardoperator wrote: post #217

The sooner people realize that agile and scrum are sales pitches with little substance the better off everyone will be.

I don't know if I agree with that. Rather than have every team on earth invent their own process from first principles, they provide adequate starting points on which to grow. Agile, Scrum and Kanban aren't perfect but they can get a team started. Good teams will take them as templates and tweak as needed.

If you look at Kanban specifically, you can tell if it's been implemented well because it's not just affecting the team. It's a tool to improve the entire value stream.

Re: Even with Agile and Scrum waterfall will sneak in

#242

Post by gumby »

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.

Bingo, and there lies its power — but only in the correct domain.

For consulting, where the customer doesn’t quite understand what they need and you need to work your way forward in an exploratory fashion (and for a limited period) it’s great. And that was the environment it was designed for!

You have a multi year engineering project? Really a waterfall, or a waterfall/spiral approach will work.

Subtasks handled by a small group can be agile, and that can make the whole thing more efficient, but that need not be the case.

A fetish for One True System is simply a cargo cult.

Re: Even with Agile and Scrum waterfall will sneak in

#243

Post by dstroot »

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…

https://www.halfarsedagilemanifesto.org/

Re: Even with Agile and Scrum waterfall will sneak in

#244

Post by 62951413 »

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 joined the industry only 20 years ago so missed the heyday of waterfall. I did witness the rise of the RUP though. And I must say that to jr developer me it was very educational despite its rather intimidating volume.

There's one angle I don't see discussed in the last 10 years or so. There was a time when a lot of attention and literature was dedicated to software design. The whole OOP movement, design patterns, the RUP, entire shelves of software architecture books. I'm inclined to call them systematic approaches to building software. I believe feature-driven development was the last such methodology aimed at developers.

Ever since Agile became popular around 2008 I have not seen anything comparable. The OOP school of thought lost its appeal without really being replaced with another well defined body of knowledge. Anything FP-related is extremely community-specific and nobody is really talking casually about, say, monad transformers. Any Agile methodology has very little guidance for developers in comparison with RUP/FDD. It's all about managerial concerns and time tracking.

But there's no question that software development is drastically different now. Using version control (even local one) was not a given in 1999. Unit testing with jUnit in 2001 was a major revelation. And shipping features constantly in SaaS got popular after 2007 or so.

Re: Even with Agile and Scrum waterfall will sneak in

#245

Post by geekbird »

xondono wrote: post #120
kinbiko wrote: post #50

Earlier quoted context omitted.

> To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. It's almost like scrum pre-dates the agile manifesto. (Which it does)

I know, but it’s not how it’s sold. The typical presentation is “we need agility => Scrum”. One would assume that if Scrum doesn’t fit the bill, one would discard it.

But, unfortunately, scrum has become synonymous with "Agile" in the corporate mind. Everything, including SRE and ops work, gets force-fit into Jira "Agile" (really FrAgile) methods and meeting-heavy rituals.

But scrum easily devolves to rapid cycle waterfall death marches. This has been going on for at least nine years that I know of. It sucks.

When a company says "We do Agile with Scrum" I wince and am very, very skeptical.

Re: Even with Agile and Scrum waterfall will sneak in

#246

Post by lmarcos »

Iv wrote: post #23
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 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 the most natural way.

Re: Even with Agile and Scrum waterfall will sneak in

#247

Post by tsimionescu »

xondono wrote: post #131
dtech wrote: post #81

Earlier quoted context omitted.

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.

* Individuals and interactions over processes and tools * Working software over comprehensive documentation * Customer collaboration over contract negotiation * Responding to change over following a plan And then you grab any Scrum guide and you’ll see: * roles and processes: (Scrum master, product owner,…) * tools: Scrum now is almost synonymous with Jira. * Documentation mandates: “how to write proper user stories”…

> And then you grab any Scrum guide and you’ll see:

> * roles and processes: (Scrum master, product owner,…)

> * tools: Scrum now is almost synonymous with Jira.

> * Documentation mandates: “how to write proper user stories”, “how you should name, split and classify tasks”,…

This is all perfectly in line with the Agile manifesto, as long as teams are empowered to customize all of them as they see fit.

For example, if the team decides that for them long daily scrums that are also an opportunity for code review is better, and so they spend 1h every day doing mostly code reviews during the daily scrum and are happy and productive with this, perfect: we valued people and communication over processes and tools. If, conversely, they get told that Daily Scrum must be a stand-up meeting taking 15 minutes or less, then they're not actually being Agile (someone is valuing the Scrum process more than people and communication).

Any team of people will follow a process and use some tools to do so. Scrum is a half decent starting point for a team moving to Agile, as are Kanban or XP or others. Ultimately you have to start with some process, then keep tweaking until the team, management, customers etc are all happy.

Having no process at all (how do we decide if we should work on X?) is a tool for disaster. Having a very rigid process (don't talk to Jim directly, wait till Daily Scrum), or following tools slavishly (I can't work on this until you log a ticket and pull it in the sprint), is as well.

Re: Even with Agile and Scrum waterfall will sneak in

#248

Post by globalise83 »

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?

Fine if you are a one-person team working on a small project, but when you have a team of several people doing uncoordinated frontend and backend changes simultaneously, chaos can often ensue. Also a lot of 'urgently needed' changes don't survive the few days until the start of the new sprint, so you would actually waste a lot of time chasing wild geese if you are just jumping straight in every time. Two weeks maximum wait (with a week or less very likely) seems like a reasonable tradeoff to me.

Re: Even with Agile and Scrum waterfall will sneak in

#249

Post by Sparkyte »

They have different purposes and should totally both be used but not onto of each other.

Agile should always be toward application development and the life cycle of rinse repeat improvements on code.

Waterfall should always be used to track initiatives goals with completed deadlines. Things that can be seen to a completed state.

Agile is about micro managing. Waterfall is about progress tracking.

It is about using the tool for the right job not trying to do everything with one tool. You can open a bottle with a screwdriver but should you?

Re: Even with Agile and Scrum waterfall will sneak in

#250

Post by cmrdporcupine »

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.

I worked a couple of teams that were using Extreme Programming back in the day (early 2000s) and took a lot of lessons from that. Then in the intervening years I worked on teams that didn't have much of a process at all, and when I came back onto teams that were attempting agile, it was in the form of Scrum, and I just... to me it just doesn't click. It's not the agile I was taught, it's just a formula applied without much thought. Usually just a Pivotal Tracker type system + daily standups, going through the motions. I see no point in it.
Post reply on HN