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

121–130 of 133 posts

Re: Coconut Headphones: Why Agile Has Failed

#121

Post by EdwardDiego »

McP wrote: post #66

I found that in my team that agile worked brilliantly for us at first - we were working together to create features that customers loved. Then support queries came in for the features we developed previously. At first a couple of team members would split off and work on the existing features while the rest of us carried on working on the new hotness. As we increased the number of (quite diverse) features, the more di…

We have a team that is made up of 1 person from each of our three teams. It rotates on a weekly basis, and that team does the bug fixes / investigations / support queries that come in.

The advantage is that disruption to a sprint is amortised to a constant instead of being a variable. The weekly rotations ensure that people who are writing bugs aren't isolated from the fixing of them - it also maintains morale, being stuck on a bug-fixing team is a bit of a gulag for devs IMO.

Re: Coconut Headphones: Why Agile Has Failed

#122

Post by briantakita »

vanderZwan wrote: post #105
briantakita wrote: post #100

Earlier quoted context omitted.

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.

Thank you for giving me that freedom ;-,

It saves me from playing games that are not in my favor. It also helps me avoid & call out people's bullshit. Life is too short to play someone else's bullshit game.

Good luck being exploited or exploiting other people ;-)

Re: Coconut Headphones: Why Agile Has Failed

#124

Post by wpietri »

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 have seen a lot of companies work fine this way, so I disagree.

Re: Coconut Headphones: Why Agile Has Failed

#125

Post by wpietri »

exelius wrote: post #117
bunderbunder wrote: post #108

Earlier quoted context omitted.

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

Yeah; a lot of the solutions you see pushed here on HN don't really scale past a startup-sized company. A lot of times if you have a very large product, you have multiple engineering teams working on a layered architecture. For example, the product guys will hand off a requirement as a user story that describes "As a customer, I can push the green button and it orders a pizza sent directly to my desk." That user stor…

The problem with the approach you describe is the notion of a "front-end team". In my view, that's not a team.

In the kind of organization I describe, teams have business purposes and are cross functional. So in your example, there'd be a pizza-direct-to-desk team. In that case, you don't need centralized management of everything.

Plenty of organizations work this way. Spotify, which has done a number of talks on their organization, works just fine with cross-functional teams focused on individual purposes. I interviewed some team members at YouTube, and they had a similar structure.

Re: Coconut Headphones: Why Agile Has Failed

#126

Post by mcv »

EdwardDiego wrote: post #120
mcv wrote: post #73

Earlier quoted context omitted.

Different teams handle Scrum in totally different ways. On my previous project, it actually felt quick and light and agile. From one sprint to the next, we could switch to an entirely different sub-project, planning poker was quick, we never got around to backlog grooming, but somehow that wasn't a problem. We got lots of stuff done. My current project feels more sluggish. Long planning meetings where just one or two…

> My current project feels more sluggish. Long planning meetings where just one or two people decide on the story points. Somehow we never really get all our stories done in our sprints. This isn't a big problem, but it makes you wonder how we plan this, and why we plan this. When you raise this at retros, what sort of response do you get? I believe you can measure the health of a Scrum team by a) what issues get rai…

Good point. I have to admit I never actually raised this point in a retro. Also because it's pretty subtle, and the planning meeting is always after the retro, so I forget about it by the time we get to the next retro. I focus on the content of the sprint itself, not the meetings around it.

I hope to address this next time. Or maybe I should just point it out before then.

Re: Coconut Headphones: Why Agile Has Failed

#127

Post by SixSigma »

abalone wrote: post #32

He just vaguely blames everything on "non-technical management" without really offering a cogent argument why. When he does get to concrete points, one of them is "Short feedback loops to measurable outcomes create good software." And yet "two week iterations" he calls "agile nonsense". The overal tone is kind of "technical macho" to me.. like, Real Developers don't need management and if you slipped then it's becaus…

It would also suggest that someone who isn't a qualified doctor couldn't run a hospital. I continually run up against this attitude that programmers are somehow special and the rules of management somehow don't work with them.

The sentence should read "The core problem is that bad managers will usually fail, or at best be counter productive, whatever the methodology".

Re: Coconut Headphones: Why Agile Has Failed

#128

Post by collyw »

enraged_camel wrote: post #113
collyw wrote: post #37

Earlier quoted context omitted.

"No. Good software comes from understanding the needs of your customers and meetings those needs. Shitty developers have and will create awesome products just because they know what the users want and need." Depends what you class as "good software". My colleague left some code which "worked" and "met the needs" (at the time). I made a small change to the database it interacted with and it fell over. I had to go in a…

It was your fault. You made a modification to a production database without understanding the full repercussions. You brag about how your refactoring made her software better, but you are ignoring the fact that you got into that mess because of a failure to follow best practices and common sense.

Sure it was my fault she used functions within functions because she didn't know how to understand Pythons module system. It was my fault she had big nested hashes without any comments to explain the structure. It was my fault she had two variables "Indexes" and "indexes" in the same function. I must be the shitty coder, not her....

I at least try and make my code maintainable.

Re: Coconut Headphones: Why Agile Has Failed

#129

Post by collyw »

zb wrote: post #114
collyw wrote: post #40

Earlier quoted context omitted.

I got taught waterfall at university. Nowhere did it specify 18 month release cycles, just iterations, and going "back up the waterfall" if need be (critics of waterfall never seem to acknowledge that you can go back the way). To be honest I don't see how it actually differs from agile that much. Just less emphasis on documents up front.

The process you're describing is the Spiral Model, not the Waterfall. The major innovation of the Spiral Model was that you acknowledged that you would need to iterate - in the Waterfall days that was considered something to be embarrassed about. The major innovation of Agile was that you acknowledged that the various steps of the Waterfall/Spiral happen at the same time - in the Spiral days, that was considered some…

It was a while ago, but I remember spiral being taught with a big spiral diagram - looked kind of like a snail shell. And waterfall had arrows that could go back up the way if needed.

I also remember being taught that errors caught after the software had been implemented was 100% more costly to fix than errors at the design stage - I think that was the idea behind big(ger) design up front.

https://sites.google.com/site/ucscsadg12/system-domain

Re: Coconut Headphones: Why Agile Has Failed

#130

Post by wpietri »

collyw wrote: post #129
zb wrote: post #114

Earlier quoted context omitted.

The process you're describing is the Spiral Model, not the Waterfall. The major innovation of the Spiral Model was that you acknowledged that you would need to iterate - in the Waterfall days that was considered something to be embarrassed about. The major innovation of Agile was that you acknowledged that the various steps of the Waterfall/Spiral happen at the same time - in the Spiral days, that was considered some…

It was a while ago, but I remember spiral being taught with a big spiral diagram - looked kind of like a snail shell. And waterfall had arrows that could go back up the way if needed. I also remember being taught that errors caught after the software had been implemented was 100% more costly to fix than errors at the design stage - I think that was the idea behind big(ger) design up front. https://sites.google.com/si…

That "errors are more costly later" notion is true for waterfall, but not for, say, Extreme Programming.

It is basically true for waterfall because the feedback loops are broken. Think cooking, for example: if I cook all my meals for a year at once and put them in the freezer, I'll have to do a lot of research and planning. Otherwise, a single mistake could lead to me throwing out up to 1000 meals.

But if I just cook every meal as I go, I can tinker quite a bit, because the cost of failure is limited to one meal. Which is no problem; if I really screw up, I just pull the frozen pizza out of the fridge.

Extreme Programming in particular can be looked at as a set of methods to flatten the cost of change curve. Then if you add the Lean Startup approach on top of that, you end up testing your core hypotheses early on, so even major shifts in business direction end up being pretty inexpensive.

Post reply on HN