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

21–30 of 320 posts

Re: Agile at 20: The Failed Rebellion

#21

Post by undreren »

ChicagoDave wrote: post #17

The Finance department never bought into it. They needed to provide funding to product owner initiatives that aligned with the business and then just let go of the process. C-suite and finance people will never do that.

Agile is (maybe a bit oversimplified) about releasing as often often as possible.

Delivering sooner, not faster.

To do this, decision makers must be close to the team, and ideally a part of the team. Either managers are part of the team, or the team a given the authority to make product decisions.

Full time managers lose power and influence either way, and I think this is the real reason Big Corp never really bought into it except on paper.

Re: Agile at 20: The Failed Rebellion

#22

Post by xamde »

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…

Nice explanation. Amusingly, it explains why NO kind of informed change can happen in a hierarchical organisation.

Re: Agile at 20: The Failed Rebellion

#23

Post by emptysongglass »

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…

> And that's why things like "Agile", "DevOps", etc will fail.

I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about.

If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement it in this way over this other way do you really think I'm going to listen to them if it's clear they have no idea what the implementation details are let alone the tools? Of course not.

I'm making DevOps happen and I do that by knowing the tools and practices. I'm being given the power I need to make it happen. I earn the respect every day I come in and write the code or identify the weaknesses we need to shore up to move faster.

Re: Agile at 20: The Failed Rebellion

#24

Post by sz4kerto »

quickthrower2 wrote: post #8

It’s a very nice article. I’ve not seen agile done as originally visioned. Usually because the VP Engineering (or equivalent) and down wants to do it but the rest of the business isn’t interested. Also the pattern I’ve seen is over time businesses want more and more fine grained control over the engineering process, as if treating the team like replaceable workers doing well defined tasks (like Ray Croc I guess) lead…

Agile is not about "mean efficiency", this is a serious and widespread misunderstanding.

Agile is a risk management method.

You won't build things faster with agile in general. It's aim is to decrease the chances of spending 80 manyears on a project and then realising at the end that you've built the wrong thing.

Re: Agile at 20: The Failed Rebellion

#25

Post by beermonster »

chmod600 wrote: post #12

I'm not an expert on this subject, but I feel like "agile" could be summarized as "a process for actively incorporating feedback early and often". That doesn't mean you need points or tshirt sizes or constant status meetings. You just need channels of communication with the right people and a chance to adapt to what they say.

This is a good one line summary.

And it’s something that good devs will already be trying to accomplish anyway. There’s also the part about breaking stuff down into small parts so that small cycles of meaningful dev can be accomplished. But that’s mainly to be able to release small and often - another thing you should already be doing to incrementally update your app avoiding big releases. It also stands in the face of waterfall development, though I see lots of teams doing test at the end still, making it waterfally.

I also see too many agile teams that have iterations that never finish, get feedback in prod, create half complete features that are weird or don’t gel - all in the name of agile.

I think the kids that get it were already doing it as it’s common sense. The rest end up sticking an agile badge on their practices when it’s all but.

Re: Agile at 20: The Failed Rebellion

#26

Post by asplake »

chmod600 wrote: post #12

I'm not an expert on this subject, but I feel like "agile" could be summarized as "a process for actively incorporating feedback early and often". That doesn't mean you need points or tshirt sizes or constant status meetings. You just need channels of communication with the right people and a chance to adapt to what they say.

That’s not a bad starting point. There’s more than one kind of feedback though! No matter how regularly you reflect on the process, if you’re ploughing through an unchanging backlog it’s still going to be a mediocre experience. Worse if the strategy keeps changing and you have no influence over it. Those unfortunately describe the experience of many - sometimes well-meant but an imbalanced and process-centric Agile with ironically little regard for the people doing the work.

Re: Agile at 20: The Failed Rebellion

#27

Post by zorpner »

emptysongglass wrote: post #23
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…

> And that's why things like "Agile", "DevOps", etc will fail. I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about. If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement…

> I earn the respect every day I come in

How much of each dollar you make for the company with your hard work do you take home?

Re: Agile at 20: The Failed Rebellion

#28

Post by beermonster »

sz4kerto wrote: post #24
quickthrower2 wrote: post #8

It’s a very nice article. I’ve not seen agile done as originally visioned. Usually because the VP Engineering (or equivalent) and down wants to do it but the rest of the business isn’t interested. Also the pattern I’ve seen is over time businesses want more and more fine grained control over the engineering process, as if treating the team like replaceable workers doing well defined tasks (like Ray Croc I guess) lead…

Agile is not about "mean efficiency", this is a serious and widespread misunderstanding. Agile is a risk management method. You won't build things faster with agile in general. It's aim is to decrease the chances of spending 80 manyears on a project and then realising at the end that you've built the wrong thing.

Well, a fluidity thing. But yes that’s related to risk. Being able to change direction at the drop of a hat. Also working with poor requirements which is a fairly common working condition in a lot of shops.

Re: Agile at 20: The Failed Rebellion

#29

Post by andi999 »

If nobody does something there is a chance it doesn't work. The most problematic point to me seems to be point 3 'customer collaboration'. Does anybody know how to do that in real life? What does the sales team sell then? And more important how do you prevent feature creep from the customers side wanting more and more things during the process? To me I only see this working if you sell working time instead of a product.

Re: Agile at 20: The Failed Rebellion

#30

Post by beermonster »

undreren wrote: post #21
ChicagoDave wrote: post #17

The Finance department never bought into it. They needed to provide funding to product owner initiatives that aligned with the business and then just let go of the process. C-suite and finance people will never do that.

Agile is (maybe a bit oversimplified) about releasing as often often as possible. Delivering sooner, not faster. To do this, decision makers must be close to the team, and ideally a part of the team. Either managers are part of the team, or the team a given the authority to make product decisions. Full time managers lose power and influence either way, and I think this is the real reason Big Corp never really bought…

> Delivery sooner, not faster

Well delivering sooner with less in it.

Post reply on HN