Live data from Hacker News

Agile Is Dead (Long Live Agility)

pragdave.me

101–110 of 117 posts

Re: Agile Is Dead (Long Live Agility)

#101
post #7

I found that no methodology works as well as getting the right people in and let them organise themselves. If you have the wrong people, it doesn't matter what methodology or process you bring in, you're screwed. On that basis, methodology isn't that relevant. I just watched a company apply SCRUM to apparently solve process problems and it just made things worse because the staff aren't disciplined or interested in w…

Amen.

I'll add one point:

6. Don't punish (for various forms of "punishment") the people who pro-actively do these things.

Re: Agile Is Dead (Long Live Agility)

#102

The author is quite defensive about the commercialisation around agile. I don't think this is warranted. I'm a developer, but I have described myself as an agile consultant in the past. This isn't out of cynically spotting an opportunity to make a buck. Its because I've spent a lot of time working in agile environments, learning the pitfalls and how to do it well, and want to share what I really and genuinely think i…

All of this is quite predictable if you just ask yourself what kind of people refer to their personal opinion papers as "manifestos".

Re: Agile Is Dead (Long Live Agility)

#103

So much of "Agile" is an attempt to "patch" the top-down, closed-allocation organization that is simply incapable of hitting technical high notes no matter how much it spends or how many people it hires. Since organizations are tough to change and all dysfunctions have champions (some deeply hidden) the "Agile" ends up having to make smaller and smaller motions while its desire for control, as the velocity in an irro…

I mostly agree, apart from the no future part.

There are plenty of companies putting out bad software, slowly but profitably. They occupy various niches where the people doing the selective hiring or being hired selectively just aren't interested in playing. Sure, they could be out-competed by an agile, well-staffed, disruptive new competitor. They could be, but they probably won't be.

Re: Agile Is Dead (Long Live Agility)

#104
post #53

Earlier quoted context omitted.

>> Of course, when implemented internally in a disfunctional organisation by people who are part of the problem, those issues will be swept under the rug and the problem will only get worse. I think that's the point. Agile/Scrum is often just window dressing. If you have a good team then it will give you some nice things like frequent interim releases and a better idea of progress. But if you don't have staff who are…

Which firms are those, in your opinion?

I think a lot of the federal contractors still have the legacy SDLC focus. Projects are huge with low margins and long timeframes. It's all about quality to keep the customer happy and not choosing the other guys.

Re: Agile Is Dead (Long Live Agility)

#105
post #102

The author is quite defensive about the commercialisation around agile. I don't think this is warranted. I'm a developer, but I have described myself as an agile consultant in the past. This isn't out of cynically spotting an opportunity to make a buck. Its because I've spent a lot of time working in agile environments, learning the pitfalls and how to do it well, and want to share what I really and genuinely think i…

All of this is quite predictable if you just ask yourself what kind of people refer to their personal opinion papers as "manifestos".

I understand your point, but in context it's a bit unfair. The manifesto was issued in 2001, when waterfall was still the default methodology at most businesses. They were indeed trying to break out of that mindset and felt they were doing something revolutionary (which, in fact they were).

Re: Agile Is Dead (Long Live Agility)

#106
post #16
post #3

Personally I find that this line "Responding to Change over Following a Plan" does much more harm than good. It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically". I would say that when you are within a project team it should emphasize the agile values but once you are on an organizational level where several project teams need to co-operate to d…

I think they worded it correctly. Notice it doesn't say, "Responding to Change over Making a Plan." Your version is horribly ugly. Theirs is succinct and poetic.

I think what the Manifesto was targeting was "blindly" following a plan. In those days, reqs were drawn up, a design spec'd, a plan written out and there tended to be considerable resistance to changing the plan. That's what they were aiming at.

Re: Agile Is Dead (Long Live Agility)

#107
post #102

Earlier quoted context omitted.

All of this is quite predictable if you just ask yourself what kind of people refer to their personal opinion papers as "manifestos".

I understand your point, but in context it's a bit unfair. The manifesto was issued in 2001, when waterfall was still the default methodology at most businesses. They were indeed trying to break out of that mindset and felt they were doing something revolutionary (which, in fact they were).

I worked on big government projects using military standards that more or less imposed the dreaded 'waterfall'.

What was our mantra? "Design a little, code a little, test a little".

Agile re-invented or popularized various ideas that had been around for a long time. As always, you adjust for the problem at hand. Royce, the so-called inventor of waterfall (he presented it as an obviously flawed concept, a straw man), argued for copious documentation. Documentation makes a lot of sense when trying to built a jet-liner, and is often a time and money sink if you are trying to write, say, research code for computer vision.

So, "revolutionary"? I dunno? Certainly many places had taken the deliberately flawed Royce model as the way to do things, and so there was a big change as far as that goes. But I can't recall a time where some form of iterative/evolutionary development method was not known about and practiced, or where decision making was favored over process.

To make this clearer - the Royce-ers patted themselves on the back, and then got hopelessly entangled with process. Yourdon came along. Wow, was that a great process - which everyone got entangled with. Then there was Booch..... And now, we have Agile. The details vary, to be sure, but the fundamentals remain the same. Some good ideas for approaching engineering a solution gets turned into conferences, endless books and training, independent consultants, certifications, requirements to be certified to win contracts, and on and on.

I'm old.

Re: Agile Is Dead (Long Live Agility)

#108
post #42

Earlier quoted context omitted.

Among the negatives of standups are: - Rarely the right information. Every person in the team have different needs for information. It is even harder to deliver the right amount and on the right level if your team includes designers, quality engineers, project/product managers. - Rarely at the right time. If your company culture includes flexible hours, no matter at what time you put the standup somebody will suffer.…

I find it really hard to understand how a quick, 5 minute meeting every day can hurt a team. > - Rarely the right information. You were doing it wrong: standups are not to give or receive information, just to inform the team what did you do yesterday, what are you doing to day and any blockers. > - Rarely at the right time. We schedule them 15 minutes before the first team member goes out for lunch (10:45 am), this f…

That all strikes me as being incredibly rigid for a process called "agile".

Re: Agile Is Dead (Long Live Agility)

#109
post #107

Earlier quoted context omitted.

I understand your point, but in context it's a bit unfair. The manifesto was issued in 2001, when waterfall was still the default methodology at most businesses. They were indeed trying to break out of that mindset and felt they were doing something revolutionary (which, in fact they were).

I worked on big government projects using military standards that more or less imposed the dreaded 'waterfall'. What was our mantra? "Design a little, code a little, test a little". Agile re-invented or popularized various ideas that had been around for a long time. As always, you adjust for the problem at hand. Royce, the so-called inventor of waterfall (he presented it as an obviously flawed concept, a straw man),…

>"Design a little, code a little, test a little".

That's not waterfall as used in the conventional sense. A key element of waterfall was/is: "Thus the waterfall model maintains that one should move to a phase only when its preceding phase is reviewed and verified."[1]

>The details vary, to be sure, but the fundamentals remain the same.

I disagree. Agile is distincly different at a fundamental level from waterfall. If you walk into a modern shop doing mostly agile with continuous delivery, you'll find that there is almost no process at all that maps directly to waterfall. Literally, not a single one: not design, not coding, not testing, not building, not deploying. They're all fundamentally very different. Coding is probably the one that comes closest and if the site uses TDD or pair programming, it will be clear how drastically different even that is. [1] https://en.wikipedia.org/wiki/Waterfall_model

Re: Agile Is Dead (Long Live Agility)

#110
post #45
post #20

Earlier quoted context omitted.

Actually I disagree. The large part (possibly not the intent) was about building a consulting empire around something utterly vague with multiple religious opinions about the best way to perform these manifesto actions. A vehicle for rats.

The original meaning of agile, the manifesto, was doing it right. The consultants jumped on the bandwagon and called themselves agile until it stuck. But I don't think the right response is to say agile is now bad, it's to reclaim the word from those who're misusing it.

> The original meaning of agile, the manifesto, was doing it right.

My impression of the original Agile project (C2), from reading their wiki, was that it was an attempt to make their customer feel really bad that they were incapable of lasting a week without changing the requirements.

Also, didn't the project fail? Though, in a way where it actually got partially deployed.

Post reply on HN