Agile at 20: The Failed Rebellion • Hacker News Board

Re: Agile at 20: The Failed Rebellion

#221

Post by greatgib » Sun, Jul 25, 2021, 12:59 PM UTC

ellen364 wrote: post #187

greatgib wrote: post #169

In my opinion and experience, the best functioning and delivering teams are the one doing Agile without even thinking or saying that they are doing Agile. It is team that are working intelligently with trust between members. Each member does it job, feels responsible and autonomous. Enough to do by itself everything needed for the project to succeed and with other members trusting him to be able to do what he needs t…

Agree completely. The tough part for me has been experiencing a team like that, then moving and having no idea how to help create a similar environment with my new team. Any tips?

In my opinion, to start with, you need to have "senior"/experienced members. Most junior still need to be taken care of before they could be blindly trusted on some topics.

Also, in my experience, most of cases like this happened in places were the management was kind of "absent" or "defective" in some way. For example when you have the next level of management hierarchy in another place/country. In such a case, often, the dev/engineers are considered autonomous and they are just trusted and expected to "take care" of all the technical things, with little supervision.

If you are already inside a team, I think that there is little to do to create a similar environment, except trying to get the maximum "power"/"position"/"space" from the company, and using that to organize yourself with the persons you are interacting with in your team.

Trust is the key element. But other members have to earn your trust, and on the other side, you should also ensure to worth the trust of your company by being reliable and deliver. Most of the time, even management will let you a lot of "space" if you are use to reliabily take over "loads" off of their shoulders.

The worst case scenario is when there are persons in management that have "bullshit" jobs like "scrum masters" where they have to do "something" to justify their work.

Otherwise, if you are in the lucky position of creating a team, the best thing is to try to have a multi disciplinary team with most of the people with a specific responsibility on some components of your system.

This is the exact opposite of saying that you have a an agile pizza team with all members that should be equal on all subjects and easily be interchangeable at will on whatever subject...

Re: Agile at 20: The Failed Rebellion

#222

Post by amrox » Sun, Jul 25, 2021, 1:03 PM UTC

p0nce wrote: post #164

eesmith wrote: post #87

Agile both succeeded and failed because it's defined as "not waterfall." Since no one does pure waterfall, everyone does Agile. Even this essay encourages that interpretation: "Everyone in this group had deep experience writing software, and they were all looking for an alternative to documentation-driven, heavyweight software development processes that ruled the day. " Did that "everyone" include Mac development in…

I don't buy the thesis that everydone was doing software development wrong until a few consultants gathered at a ski resort.

XP, Scrum and agile-adjacent Lean all pre-date the manifesto. The manifesto just tried to put all these ideas under one umbrella.

Re: Agile at 20: The Failed Rebellion

#223

Post by callmeal » Sun, Jul 25, 2021, 1:06 PM UTC

danparsonson wrote: post #170

forgotmypw17 wrote: post #90

Earlier quoted context omitted.

It wasn't particularly draining, because the large windows allowed a more relaxed pace, ensuring that nothing was missed, and a time for joking around. And it was not "16+ hours of meetings", but two days of taking a break from coding to do more social work, also having a 2-hour lunch together in the middle :)

Even a two hour lunch break still leaves more than six hours for a retrospective, so, honest question, what do you talk about? I'm used to retrospectives taking about 15-30 minutes, and even then we usually have to scratch around for things to talk about. How can you have six hours of things to discuss after three weeks of work?

>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.

Re: Agile at 20: The Failed Rebellion

#224

Post by dsr_ » Sun, Jul 25, 2021, 1:08 PM UTC

mmarq wrote: post #154

baxtr wrote: post #97

Earlier quoted context omitted.

It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.

The existence of coaches and scrum masters is the result of decisions of management, that see agile as a way of getting daily reports from the team through the daily standup. I don’t think that people who don't write or never wrote software should have a place in a software development team. We don’t allow scrum masters and agile coaches in hospitals and ask them to “improve the process”, because we know the only “im…

A fair number of hospitals have been taken over by MBAs. The result is generally more money for the administration, and cost-cutting elsewhere.

Since the purpose of a hospital is not to make money but to improve health-related outcomes, this is usually bad.

On the other hand, it turns out that focus on improving health-related outcomes by applying science and statistics works really well... and usually decreases costs, too.

Re: Agile at 20: The Failed Rebellion

#225

Post by dsr_ » Sun, Jul 25, 2021, 1:10 PM UTC

brnt wrote: post #218

jim-jim-jim wrote: post #159

Earlier quoted context omitted.

> We don’t allow scrum masters and agile coaches in hospitals Give it a few years.

My hospital had them 10 years ago. Leaving is, second to marrying my wife, the best decision I ever made. Hospitals are, much to my sincere regret, not able to attract much talent in IT. Mediocrity is the best you can hope for, and I wouldn't even count on that.

It is the same as the government IT problem: if you can make much more money in private practice, why would you work at a hospital or government? Selling software to the hospitals or government is a better deal.

Re: Agile at 20: The Failed Rebellion

#226

Post by temac » Sun, Jul 25, 2021, 1:25 PM UTC

> The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. [...]

The problem is: the manifesto states clear dichotomous preferences without nuance, and it certainly not for example states that it embraces well-maintained and useful documentation but that "[we value] working software over comprehensive documentation".

See? It is written "comprehensive".

Not "shitty".

And I even agree that maybe "comprehensive documentation" can be a dangerous concept if taken too far, but that's pretty much true for anything taken too far, and actually I have never seen a problem in this direction, but pretty much all the time and extremely often in the opposite way (I could say : a comprehensive lack of documentation...). So maybe de-emphasizing "documentation" was not that smart...

Either it was very poorly written or there is an attempt at rewriting history. At the end of the day, you can't just hand wave the shortcomings originating directly from the text by just stating "oh but we did not mean that, wasn't it obvious?" -- well... no! it was not!

Likewise for the other "values". They seem to have been written because of a perceived lack of balance (and maybe there are even again some adjustments to be made and they are not exactly intended to mean what is written...) in the personal experiences of the signatories, however there is no provision against balancing too much in the other direction, or against inappropriate applications in specific contexts (the "preferred values" are actually extremely context and project dependent)

So maybe people actually got what was written, or maybe the whole thing was so vague that they got random outcome from a mostly cargo cult application. And in a few case, intelligent practice in a good context, so good outcomes; but when that happens, would the successful team have done poorly with other preferences of "values" or with other stereotypical day-to-day practices (weird btw when processes are to be deemphased)?

> What do you mean you’re going to start building the software before you’ve gathered all of the requirements and estimated every piece of functionality? That’s insane!

Like, the significant software from the 80 or 90 was written like that (in inappropriate contexts)?

And when it was (again, in inappropriate cases), was the solution to settle on the four stated value preferences? Why? From where does that even come from? Where is the evidence? How can it be applied? Why can't I write precisely the opposite and say "see? here is my solution!" -- if not just because of the obviousness of some outcome: yeah not valuing working software enough will probably not lead to better working software. My point, however, is that stating that you value working software more cannot yield to actionable things in not completely dysfunctional environment, because whatever their current practices are everybody will say they want that and what they are currently doing has value to achieve that goal. And the other value preferences are highly contextual.

There is no silver bullet. Not in technical areas. Not in project management. Especially not when project management is not interested in the technic; that is: in the project, if the project is of a technical nature...

Re: Agile at 20: The Failed Rebellion

#227

Post by FredPret » Sun, Jul 25, 2021, 1:27 PM UTC

ipnon wrote: post #10

archeantus wrote: post #4

I really enjoyed this read. I’ve been grinding for so long in the huge corporation version of agile that I don’t even know what is what anymore. It was refreshing to hear their take on project managers, as it matches how I’ve been feeling recently. They schedule 7 checkpoint meetings per week and I’ve given up on attending, I just can’t do it anymore. I hope that we can move past agile into a new world that is free o…

This is how revolutionary Marxism functions. Nobody knows what the hell Marx wrote in those books, or what any of it means, but it cannot be argued in communist regimes that there is a system in place, and that the vanguard knows whats best. Replace Marxism with Agile, communist regimes with corporation, and vanguard with management, and you have the recipe for soulless employment.

Imagine a revolution with a retrospective

Re: Agile at 20: The Failed Rebellion

#228

Post by eecc » Sun, Jul 25, 2021, 1:29 PM UTC

smokey_circles wrote: post #127

outsomnia wrote: post #100

Earlier quoted context omitted.

You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.

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…

If developers were given Operational Research and a couple management classes during university training, the pretense that they are some kind of highly functioning idiots would evaporate overnight.

Problem is that the industry is full of untrained individuals who hustled their way ”fake it until you make it” and will use all their political and manipulatoy clout to justify their positions and fight back any attempt at effective process engineering.

Re: Agile at 20: The Failed Rebellion

#229

Post by steveBK123 » Sun, Jul 25, 2021, 1:32 PM UTC

dirkt wrote: post #57

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…

> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over resp…

The problem is most agile followers take "Responding to change over following a plan" to mean Don't plan. So you have 100+ person organizations running in a direction quickly for 2 week sprints to find out what the new direction they are going to run once they get there.

Re: Agile at 20: The Failed Rebellion

#230

Post by rgblambda » Sun, Jul 25, 2021, 1:33 PM UTC

brtkdotse wrote: post #129

yobbo wrote: post #125

Earlier quoted context omitted.

> As much as devs try to disagree, technology is not a goal in of itself Can you find one dev that has ever disagreed with this?

I can find a ton of devs paying lip service disagreeing, but the second they utter “we need to rewrite this in…” the facade falls apart.

When I hear “we need to rewrite this in…”, it's usually because someone isn't familiar with the language it's currently in and wants to switch to the old language/framework they like best. I don't think I've ever actually heard someone trying to advocate for shiny new x just because.