Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile at 20: The Failed Rebellion

simplethread.com

Post reply on HN
Print view View original

231–240 of 320 posts

Re: Agile at 20: The Failed Rebellion

#231

Post by temac »

smokey_circles wrote: post #127
outsomnia wrote: post #100

Earlier quoted context omitted.

You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.

The air quotes sell it. It's easy to blame management because developers and engineers haven't the foggiest idea what management actually does. Instead of engaging with that problem, they retreat to themselves where they hiss the name management in dark corners. Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand. I absolutely hate how accurate that is becau…

There is probably some truth in all of that (although I strongly disagree in some specific points), but also consider that if "management" is incapable to convey their own value, and to cooperate with "engineers" in a non-antagonizing way, maybe they share some of the responsibilities in the divide... esp. if they are supposed to be "management" and take care of rational things (business value being an obviously rational one...) while engineers are basically... playing with their toys?

I don't understand how your vision of things is not also contributory to a strong divide.

Re: Agile at 20: The Failed Rebellion

#232

Post by treeman79 »

avereveard wrote: post #213
ratww wrote: post #205

Earlier quoted context omitted.

I'm all for shitting on the JS ecosystem, but honestly there haven't been any noticeable shifts whatsoever in its ecosystem for at least 6 or 7 years now. Both React and Vue.js are now older than jQuery was when both were released. Same for Babel and Webpack. Typescript is older than all of these. SASS/SCSS also older than Typescript. Those are the only things you see in 99% of the frontend job descriptions out there…

They keep releasing versions that break backward compatibility forcing whole app rewrite left and right, that counts too

Had a year long project in Angular. Most of the time was spent rewriting the app and learning the right way “again”

Re: Agile at 20: The Failed Rebellion

#233

Post by felipellrocha »

dirkt wrote: post #57
AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over resp…

This reeks of “no true scotsman” to me. They claim is the manifesto, but the author even makes the claim that his process allowed engineers “a month of time without management intervention (a sprint length of 4 weeks). The author being one of the original signers and creator of scrum.

If that’s not following a plan over responding to change, i don’t know what is.

Re: Agile at 20: The Failed Rebellion

#234

Post by mgbmtl »

the_gipsy wrote: post #160
smokey_circles wrote: post #127

Earlier quoted context omitted.

The air quotes sell it. It's easy to blame management because developers and engineers haven't the foggiest idea what management actually does. Instead of engaging with that problem, they retreat to themselves where they hiss the name management in dark corners. Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand. I absolutely hate how accurate that is becau…

> Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand. Open source does self-organise, and manages to produce some products of exceptional quality. It’s just almost completely unsteerable. In a company, you can pretend to order people around. But the truth is that what really matters is how all the personal and political goals happen to align.

I think the difference is having a leader vs shepherds. Most open source projects have shepherds who do a lot of invisible work.

The project I work on has around 100 regular contributors, but also a few small teams, either volunteer or staff, who meet regularly and make sure things move forward in a coherent and sustainable way.

Re: Agile at 20: The Failed Rebellion

#235

Post by danparsonson »

callmeal wrote: post #223
danparsonson wrote: post #170

Earlier quoted context omitted.

Even a two hour lunch break still leaves more than six hours for a retrospective, so, honest question, what do you talk about? I'm used to retrospectives taking about 15-30 minutes, and even then we usually have to scratch around for things to talk about. How can you have six hours of things to discuss after three weeks of work?

>I'm used to retrospectives taking about 15-30 minutes, and even then we usually have to scratch around for things to talk about Depends on the size of the team. For a 2-3 week sprint, and and team of 10-12 devs, a six hour relaxed retro is just barely time enough.

That doesn't answer my question :-) Are you all regularly having terrible problems that need in-depth discussion? Are you all celebrating every success with its own party? Are your processes so wildly off the mark that you have to change everything every sprint? Is there something else you do in your retrospectives that I don't? For my current team (also around 10-12 devs, 2 week sprints) it's:

- what went well? we completed most/all of our tasks, cracked a tricky problem, received good feedback from somewhere - let's say 5-10 minutes of celebration

- what didn't go well? maybe a task was more difficult than expected, some new requirement added unexpected difficulties, some third party something didn't perform as expected - 10-15 minutes of commiseration and discussion, maybe more if there's something complicated, perhaps that requires further action

- what would you do differently? unless there are some procedural problems, I would expect almost nothing here; maybe someone has some new ideas about how to improve something, perhaps some aspect of the project isn't running as smoothly as it could - 5-10 minutes maybe

So about thirty minutes max across the whole team, usually less. What secret magic are we missing out on? Six hours??

Re: Agile at 20: The Failed Rebellion

#236

Post by temac »

pritambaral wrote: post #115
ipaddr wrote: post #89

Earlier quoted context omitted.

I get your point that someone rose from your ranks and you respect them over someone who who has a background in pm but not your product. That technical pm is a luxury and will move on at some point. You don't need him your team with a strong lead or more senior developers could work with a regular pm and get the job done.

> ... your team with a strong lead or more senior developers could work with a regular pm and get the job done. Let me show you where this slippery slope ends: Teams with a strong lead or more senior developers could work without any PMs and still get the job done. Oh. Wait a second. This happens all the time! Does this mean those teams achieved their success without any management happening? Or does it mean that tec…

If work activities is about titles, I hope yours is multiple lines long.

We are talking about what is the most efficient. One of the point of Agile was to attempt to lower the division of tasks (and I'm saying that even if I don't like the way it was attempted nor the overall effect 20 years later) because having a broader vision of things is more efficient than trying to communicate (to what I would add: IF the project scale is reasonable enough to do that...); thus: a little bit of PM tasks, a little bit of working with customer, etc -- at least more involvement than if crappy requirements were produced after crappy contracts were signed, and neither of them could be revised.

So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem? You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.

Re: Agile at 20: The Failed Rebellion

#237

Post by spamizbad »

I think one piece of the Agile origin story that’s missing is that it was heavily influenced by software contractors - people who worked on software that had a definitive “end”: either because it was feature-complete, it was time sensitive, or the client had a fixed budget.

Many of Agile’s problems arise when you begin to apply them to long-running products that undergo continuous cycles of improvements - stretching years rather than months.

Re: Agile at 20: The Failed Rebellion

#238

Post by lrdswrk00 »

pydry wrote: post #192
dirkt wrote: post #57

Earlier quoted context omitted.

> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over resp…

The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. I once had it used against me to justify not writing tests ("processes and tools!"). We had meetings about bugs instead. Seriously. Complain all you like about perversion, that was a perfectly valid interpretation coz those hallowed commandments are,…

They’re purposely ill defined.

The outputs they seek are emergent.

You also belittle scrum for becoming too specific.

Seems you’re still processing what to make of any of it.

Knowledge work is immaterial and should have no prescribed rails or all you get is run of the mill outputs.

It’s similar to business; billions have been spent investigating what technology or management style brought the biggest gains. The math quickly becomes so Byzantine there no meaningful conclusions.

No matter how detailed our consciousness will let us imagine, there’s still one reality ruled by physics. Esoteric math may be correct in that it has the order of operations right, but that truth doesn’t give it any real influence on physical reality.

Re: Agile at 20: The Failed Rebellion

#240

Post by ChrisMarshallNY »

tkiolp4 wrote: post #200
ChrisMarshallNY wrote: post #172

That is too bad. When I first read the Manifesto, I said “These folks got it!” I tend to work that way, now. Myself. Things get difficult in teams. Especially cross-disciplinary teams, and aggregate efforts. Much as we like to denigrate managers (DISCLAIMER: I was one) , they are necessary; and not as a “necessary evil.” Good managers can be amazingly effective and well worth it. Unfortunately, like in any vocation,…

> Good managers can be amazingly effective and well worth it. Good Xs (where X = developers, managers, designers, etc.) can be amazingly effective and well worth it. This is obvious. The vast majority of managers out there are average, and so they are a necessary evil. Compare this to the situation: the vast majority of developers out there are average (I include myself in this group )... and this is fine, they are n…

I don't see anyone as a "necessary evil." If they are necessary, then they are not evil.
Post reply on HN