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

261–270 of 320 posts

Re: Agile at 20: The Failed Rebellion

#261

Post by g051051 »

brundolf wrote: post #32
throwaway290232 wrote: post #18

Agile is a generic umbrella term that involves a vast array of complex, subtle knowledge and skills. It's like saying "Engineer", or "Chef". Each has a shared skillset, to be sure. But each category's members can't just work the same way at all jobs, and there's no book on how to be an Engineer or Chef everywhere. The Agile Manifesto is a failure at trying to make Agile happen because it can't tell you how to make it…

The product and engineering managers I've had in the past have generally been humble, acting as a touchstone of coordination for the folks on the ground rather than a controlling force. And the engineering managers have all just been former engineers who decided they preferred doing this kind of facilitation work instead of writing code. Maybe this isn't the norm?

In my experience, it most definitely is not.

Re: Agile at 20: The Failed Rebellion

#262

Post by g051051 »

TedDoesntTalk wrote: post #58
forgotmypw17 wrote: post #52

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFEREN…

This sounds soul-crushing and I hope never to work in such an environment.

> At the end of the sprint, we spent AN ENTIRE DAY on retro. Before the next sprint started, we spent AN ENTIRE DAY on planning.

I'm getting ill just thinking about this. Two whole days wasted every sprint!

Re: Agile at 20: The Failed Rebellion

#263

Post by denton-scratch »

baxtr wrote: post #161
denton-scratch wrote: post #146

Earlier quoted context omitted.

> Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand. I beg to differ. A dev team doing agile, with a team leader who is a manager/dev, can definitely self-organise. The team leader interfaces with non-dev management, removes roadblocks, and in collaboration with the rest of the devs sets the direction for a sprint. You need this team lader role to keep the…

> I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome. That’s a view in many large corporates. However, in product focused companies and many startups every developer has to have a customer focused mind. Every single day.

I think you'll find that view in any smoothly-running business with an eye on the future - not just large corporations. Unless the management are the devs.

We have to specialise at some point - not everybody that gets hired is going to be an ace industrial strategist. Few devs know how to qualify a sales prospect. If you have such people in management, then as a dev I don't want to do their job for them; they should set strategy and find good customers.

I guess we all have differing perspectives on this kind of thing; one's perspective is partly formed by one's experiences.

I'm not talking about startups - I never worked in one. But I've worked for quite a few companies with < 20 staff.

Re: Agile at 20: The Failed Rebellion

#264

Post by AndrewKemendo »

catmanjan wrote: post #42
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…

I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close

And in the process you have burned out the client who hired you so that they didn't have to make decisions.

"I thought this was your job" is something I've heard a few times from clients when we have sent over wire frames or beta applications.

Re: Agile at 20: The Failed Rebellion

#265

Post by lrdswrk00 »

pydry wrote: post #246
lrdswrk00 wrote: post #238

Earlier quoted context omitted.

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…

>They’re purposely ill defined. Yes they were. The cynical side of me says that this was because they were purposefully trying to create a rallying cry or something akin to a religion to better sell their wares and were unconcerned about the fallout that would ensue. The less cynical side of me says they did it because they came up with "extreme programming" and knew that a lot of it was kind of bullshit, disagreed w…

Who is they? The original authors have little to do with the administrative state that’s been wrapped around our agency.

Anarchy is no good.

Haha.

Your efforts are constrained by physical science, social objectives.

There’s plenty of structure to prevent anarchy.

But you would further impose problem solving constraints on others thought work.

Shit n hellfire; what a dumpster fire of a culture.

Would you say something as minimal as “E=mc^2” promotes anarchy? It hardly illustrates the full meaning of relativity.

Perhaps where you perceive emptiness and anarchy, others perceive correctness and order.

Like religion; one mans abstraction is another mans insanity.

Re: Agile at 20: The Failed Rebellion

#266

Post by AndrewKemendo »

xg15 wrote: post #185
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…

So then, what do you advise to do? Give up?

Develop product engineers to be better. Have empathy and communicate with the target customer more clearly and understand the landscape better.

That's pretty much all you can do. How you organize it only matters insofar as it makes your team effective - sprints, waterfall, XP whatever... is kind of a toss up and context dependent.

Re: Agile at 20: The Failed Rebellion

#267

Post by dccoolgai »

chrisan wrote: post #171
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…

I've found the opposite to be true. Management is what chases the quick buck and not the long term scalability of more money. When I first started we would be doing 1-off feature requests "because the client would _really_ like it". Everything was justified because money and because "we cant afford to lose that customer!" in our SaaS product. I saw our main product being neglected because we'd invest so much time in…

Doing 1 or 2 features at a time to make 1 client happy or win one deal is called consulting. Not that there's anything wrong with consulting: consulting can be quite lucrative and fulfilling but mistaking it for "product" work is responsible for some large X% of small/early startups failing.

Re: Agile at 20: The Failed Rebellion

#268

Post by jdlshore »

danparsonson wrote: post #235
callmeal wrote: post #223

Earlier quoted context omitted.

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

Six hours is longer than I would use for a regular retrospective, but 30 min is very short. The format you’ve described is fairly shallow. Check and Derby and Larsen’s Agile Retrospectives for ideas about what you might be missing.

Re: Agile at 20: The Failed Rebellion

#269

Post by felipellrocha »

ako wrote: post #153
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…

Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go. Agile tries to turn software development into a product design process rather than a product manufacturing process. Together with the client, iteratively you try to find the right solution and design for the customer problem. By being easy to adopt,…

> Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go.

Oh, man. I think you hit the head of the nail. One succinct phrase that describes the entire problem.

Re: Agile at 20: The Failed Rebellion

#270

Post by Jtsummers »

g051051 wrote: post #262
TedDoesntTalk wrote: post #58

Earlier quoted context omitted.

This sounds soul-crushing and I hope never to work in such an environment.

> At the end of the sprint, we spent AN ENTIRE DAY on retro. Before the next sprint started, we spent AN ENTIRE DAY on planning. I'm getting ill just thinking about this. Two whole days wasted every sprint!

Two whole days! Oh the humanity!

If those two days out of every two weeks are critical to a team hitting their deadlines, then the team is already fucked. If you can't stop, think, talk, and relax for a moment, then you're already behind or will be behind and you'll probably never catch up without risking burnout of the team and mass quitting.

Post reply on HN