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

Coconut Headphones: Why Agile Has Failed

mikehadlow.blogspot.co.uk

Post reply on HN
Print view View original

101–110 of 133 posts

Re: Coconut Headphones: Why Agile Has Failed

#101

Post by vonmoltke »

bunderbunder wrote: post #82
vonmoltke wrote: post #70

Earlier quoted context omitted.

I think you are missing a couple, somewhat related failure modes. First, if the software project is part of a larger integrated hardware/software project, people above the project manager may be making promises of deliverables without consulting the program manager at all, thus creating externally-imposed deadlines that cannot be changed without rippling through to other teams, who may or may not be in your own compa…

Disclaimer: I've only recently decided to Stop Worrying and Love the Scrum, so my perspective on the subject may still be heretical. That said: I think these are not failure modes that can be laid at Agile's feet. They represent a situation that Agile quite explicitly does not even attempt to fix. A key part of the (for lack of a better word) Zen of Agile is that on anything above the smallest of scales, it's impossi…

If that is the case, then Agile just does not work for large, integrated engineering projects. You must make attempts at locking both feature sets and due dates because the progress of teams is interdependent and the flexibility each team has is highly variable. At some level of granularity there must be an established schedule that other teams can plan to. Its a basic part of systems engineering.

This is not to say these structures should be inflexible. There needs to be some flexibility in requirements and dates, and it is the responsibility of the program manager and systems engineer to make sure the project can bend without breaking. There must be limits on it, though, or the project will tear itself apart.

Re: Coconut Headphones: Why Agile Has Failed

#102

Post by MartinCron »

wpietri wrote: post #96
MartinCron wrote: post #87

The article closes with this idea: @sbellware we should bury agile, mourn the dead, and get on with establishing something that is designed to be resistant to being so easily undermined https://twitter.com/sbellware/status/443397344436817920 Which makes me wonder, is it even possible to create a "thing" (idea, movement, methodology, system, whatever) that is resistant to being undermined? I don't think so. It seems l…

The one big mistake I think the Agile people made is not trademarking the term Agile and then enforcing some standards. There was discussion early on, but for some reason it never happened. For Agile it would have been hard, because Agile isn't a methodology on its own; it's an umbrella for a bunch. Enforcing standards doesn't make it proof against being undermined, but it does make it harder. There's still a tradeof…

That's an interesting idea, but my first instinct is that the cynical developer response to "Agile(tm)" would be even more harsh than to just "Agile".

Re: Coconut Headphones: Why Agile Has Failed

#103

Post by bunderbunder »

exelius wrote: post #95
wpietri wrote: post #92

Earlier quoted context omitted.

I think you've mainly missed the point of his article, but let me address the last bit, about non-technical managers. The way to reconcile his view and yours is to have parallel engineering and product management structures. There are non-technical product managers, but there are no non-technical engineering managers. Every team has engineers and a product manager, but neither reports to the other. That way you get p…

If you have two parallel organizations that interact tightly but have no power over each other, you end up needing a mediator. This usually ends up being project management, or "the process". This is where you get the mixed bag in companies with mediocre talent levels -- usually they don't have anyone who understands the needs of both the engineers and the business. The level of process usually either chokes the engi…

I work in an team that's organized the way the parent describes, and there's no mediator needed. The engineering managers and product managers have a good working relationship and collaborate closely, so they usually have no problem reaching consensuses that work for everyone. The close collaboration means that each side is aware of (and can usually anticipate) the other side's needs and limitations, but the division of responsibilities ensures that the number of balls getting dropped is minimized.

The relationship most certainly does not need a mediator. Sticking a mediator in there would probably end up destroying the arrangement. If the two camps can't work together without one, a better solution is to figure out who it is that doesn't know how to play well with others and get them replaced.

Re: Coconut Headphones: Why Agile Has Failed

#104

Post by carsongross »

joshyeager wrote: post #71
carsongross wrote: post #16

To the extent that I've seen development methodologies work, they appear to mostly fix organizational barriers that get in the way of The One Thing That Actually Works[1]: hire a small group of extremely talented developers and product designers and then let them work. [1] Assuming your codebase isn't already a monstrosity. If it is... well, then nothing works.

How big is a "small group", in your opinion?

10 or fewer people.

Re: Coconut Headphones: Why Agile Has Failed

#105

Post by vanderZwan »

briantakita wrote: post #100
vanderZwan wrote: post #44

Earlier quoted context omitted.

I think you missed the part where he implied that what programming culture considers "good" software is nothing short of a near-perfect to perfect technical implementation. In other words: what the other guy called "shitty" is actually the average. See also the odd thing that most people consider themselves better than average, which by definition cannot be true.

I'd like the flip that thinking on it's head a bit. It's not about "average" or "better or worse" than average. The need to put yourself and others into some sort of ranking stems from the need to categorize everything into a hierarchy. I'm talking about something more binary. Good or bad. Progress or stagnation. The right or wrong side of history. I'm also talking about power. Who determines engineering practice. Th…

If you want to reduce a problem of this complexity to binary choices, be my guest, but I doubt it will get you anywhere useful.

Re: Coconut Headphones: Why Agile Has Failed

#106

Post by exelius »

bunderbunder wrote: post #103
exelius wrote: post #95

Earlier quoted context omitted.

If you have two parallel organizations that interact tightly but have no power over each other, you end up needing a mediator. This usually ends up being project management, or "the process". This is where you get the mixed bag in companies with mediocre talent levels -- usually they don't have anyone who understands the needs of both the engineers and the business. The level of process usually either chokes the engi…

I work in an team that's organized the way the parent describes, and there's no mediator needed. The engineering managers and product managers have a good working relationship and collaborate closely, so they usually have no problem reaching consensuses that work for everyone. The close collaboration means that each side is aware of (and can usually anticipate) the other side's needs and limitations, but the division…

I'm not saying it can't work that way -- just that it often doesn't if you don't have good people. Also, even if you have good people, when the product group is more or less a single silo and you have a dozen different engineering teams working on various modules of a product, communications get lost and balls get dropped and you need some sort of communication process that ensures at a bare minimum accountability (which usually ends up at Agile).

I know a lot of people would say "Well just hire better people," but that's often not realistic. It takes time to hire people, corporate HR processes are terrible at differentiating good developers from mediocre ones. In the time it takes you to hire people, you still need to ship product.

Re: Coconut Headphones: Why Agile Has Failed

#107

Post by bunderbunder »

vonmoltke wrote: post #101
bunderbunder wrote: post #82

Earlier quoted context omitted.

Disclaimer: I've only recently decided to Stop Worrying and Love the Scrum, so my perspective on the subject may still be heretical. That said: I think these are not failure modes that can be laid at Agile's feet. They represent a situation that Agile quite explicitly does not even attempt to fix. A key part of the (for lack of a better word) Zen of Agile is that on anything above the smallest of scales, it's impossi…

If that is the case, then Agile just does not work for large, integrated engineering projects. You must make attempts at locking both feature sets and due dates because the progress of teams is interdependent and the flexibility each team has is highly variable. At some level of granularity there must be an established schedule that other teams can plan to. Its a basic part of systems engineering. This is not to say…

Right. . . hence the sentence on the end about needing to use buffer space to handle the things that Agile never promised it could handle in the first place.

I'd point out that the same problem exists for every other software development methodology I've ever tried. The difference is that when they do slip deadlines, it tends to be a whole lot more surprising (and therefore damaging to the schedules of other teams) because their feedback mechanisms tend to result in poorer-quality progress tracking.

Re: Coconut Headphones: Why Agile Has Failed

#108

Post by bunderbunder »

exelius wrote: post #106
bunderbunder wrote: post #103

Earlier quoted context omitted.

I work in an team that's organized the way the parent describes, and there's no mediator needed. The engineering managers and product managers have a good working relationship and collaborate closely, so they usually have no problem reaching consensuses that work for everyone. The close collaboration means that each side is aware of (and can usually anticipate) the other side's needs and limitations, but the division…

I'm not saying it can't work that way -- just that it often doesn't if you don't have good people. Also, even if you have good people, when the product group is more or less a single silo and you have a dozen different engineering teams working on various modules of a product, communications get lost and balls get dropped and you need some sort of communication process that ensures at a bare minimum accountability (w…

Hum. Well I would say that if the product group is a monolithic silo interacting with a dozen engineering teams, that does sound like a recipe for trouble. The system I'm thinking of involves having at least one member of the product team for every engineering team.

That actually edges back toward my one serious complaint about Agile development: On the teams I've worked with, there's a bit too much value placed on generalism over specialism in team members' skill sets. Anything that's everybody's responsibility is effectively nobody's responsibility.

Re: Coconut Headphones: Why Agile Has Failed

#109

Post by bmm6o »

jasallen wrote: post #81
programminggeek wrote: post #61

This recent meme about agile is so dumb that I feel like I shouldn't say anything at all, but here goes anyway. I'll keep this as short as possible... Agile works fine for teams that embrace it. It's going to work totally different from team to team. The real point is to find the process that works best for your team to deliver software that meets the customer requirements and budget. Agile for a team of 1 or 3 is no…

> it's not agile's fault. It's your fault. It's your team's fault That's what everyone has said about every dogma they've ever believed in, ever.

Sure, that's the easy answer. But some organizations have success with that methodology, so it's obviously not impossible to ship quality software with it. And many of those organizations used something else and switched to it, so they must think it's superior their previous methodology. Or really, I should be talking about their implementations of methodologies, since reality doesn't match the platonic ideal even in the best case; in the worst case it might be unrecognizable.

So do you disagree that there are a lot of ways to implement "agile", some of which will be more successful than others? Or do you think that there are some organizations for which agile (even well-implemented) will never be better than methodology X? (where X = ?)

Yes, it's easy to run into No True Scotsman and "ur doin it rong", but we're not going to advance the state by pointing out that it's hard to draw correct meaningful generalizations (we know that already).

Re: Coconut Headphones: Why Agile Has Failed

#110

Post by ebiester »

programminggeek wrote: post #61

This recent meme about agile is so dumb that I feel like I shouldn't say anything at all, but here goes anyway. I'll keep this as short as possible... Agile works fine for teams that embrace it. It's going to work totally different from team to team. The real point is to find the process that works best for your team to deliver software that meets the customer requirements and budget. Agile for a team of 1 or 3 is no…

That Is Why You Don't Do Estimates In Hours.

Relative estimates are much more reliable than absolute estimates. That's what fibonnaci sizing, etc. is about -- you can gauge effort relative to other effort.

Once you have an actual consensus of the complexity of tasks broken down, you can then apply that to the team velocity and make estimates.

Better is Arlo Belshee's system of getting everything to roughly the same size block. http://arlobelshee.com/planning-with-any-hope-of-accuracy/

Post reply on HN