Talk:Agile software development

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Micromanaging?[edit]

Old fart here. I have spent 42 years in the mainframe industry, both as an all-round business analyst, database designer and developer and (last 10 years) database administrator. I retired in September, but found retirement a bit dull, so I have started up as a consultant. And now I have found that literally every company is going Agile. We're doing "standups" every morning, we have sprint planning sessions every two weeks, we have refinement sessions, we have PI's (program increments) consisting of 5 two-week sprints, and every PI – i.e. every 10 weeks – there is a two-day planning session with the whole IT department, 40–45 people. So, they are basically burning money, at least in my view; having 40–45 people in a two-day planning session consumes as many manhours as one person can do in about four months.

And now that I read about Agile, it says that the Waterfall model was criticized for "micromanaging". Eyeroll. I guess it could be, but that depends on the project leader. Agile appears to be micromanaging by design.

I'm an impatient person and I'm used to rolling up my sleeves and just do what's needed, and I don't know how long I can stand this.

Agile is a fad. It will go away.

This is a comment to the cn tag I just put on the article.

HandsomeFella (talk) 11:00, 21 June 2022 (UTC)[reply]

Software dev has been agile for a long long time. Scrum is new, and I too find it to have a hefty taint of micromanage via daily intimidation. I've yet to hear of its value or justification, particularly onerous in the wrong hands: Agile/scrum means we work in isolation. Looking at what it does, daily, it gets engineers to speak (presuming they don't) and if you're really lucky, someone addresses the blocking, but not seeing the purported scrum master doing so. 149.32.192.43 (talk) 19:25, 6 October 2022 (UTC)[reply]
Scrum is not new. Have you not read the article? Both agile and scrum came up to be at about the same time, in mid 90's. Unless you are arguing that Agile is older than that. Then I would ask you to elaborate on that. 181.221.20.233 (talk) 14:23, 17 November 2023 (UTC)[reply]
At Meta, we weren't "Agile" but the use of meetings and overmanagement are as you described. I am one of those people where you can just tell me the problem and I'll go take care of it. So you can imagine my frustration when our policy was to have multiple meetings planning out the solution before anyone does anything, then we finally go to enact the solution and find out one of our assumptions was wrong, so back to the drawing board with more meetings. Plus you the people in the meetings are often managers and nontechnical people who don't really know what's going on, but we are all supposed to plan this together somehow. So my impression is that these overmanagement methods are part of a general push for "inclusion" which effectively means that the person whose best for the job (the expert) can't just solve the problem before including lots of other people who only slow things down.2405:9800:B650:C3C0:AC8A:AD67:68D1:6DE (talk) 09:23, 6 February 2023 (UTC)[reply]
Agree. And not only is it micromanagement, it's stealth authoritarian, disguised in thick layers of fake friendliness and fake good humor. It probably stems from 1) a need for detail control (which managers in the IT industry can dream of, but will never have), and 2) a desire of making everyone replaceable, in order to avoid dependency on a few individuals, and being able to kick anyone anytime, and thus stave off requests for a raise. But guess what: people make the employer having to replace them continuously by quitting. It's what's happening here: four out of 45 people have quit the last 6 months, another one is leaving this week. I will leave at the end of March, but they don't know that yet. HandsomeFella (talk) 13:03, 6 February 2023 (UTC)[reply]

Doubts about a reference[edit]

Hi, I am very interested in technology and computer issues. In my spare time, I read about related topics and, if I think it is necessary, I help to improve some wikipedia entries. About the "Agile Software Development" entry, I added a reference and someone reversed it. It is a reference that provides information about what is talking in the entry and improves it. I think it was because I added the reference wrong: I put "Cite web" instead of "Cite news," and I wrote the date wrong (for example: 07/06/2023, instead of 7 June 2023). I've corrected it, and I think it's correct now. Anyway, if it is wrong, you can correct it by yourselves without deleting it, so we all help to improve Wikipedia! ¡Thank you so much!

The reference is this one: https://www.elconfidencialdigital.com/articulo/noticias/metodologias-agiles-era-inteligencia-artificial-entrevista-arie-van-bennekum/20230607181016584992.html OnePapaya (talk) 14:15, 13 June 2023 (UTC)[reply]

It is redundant with other references - providing no new information. Given that, and given that this is the English language Wikipedia and the reference is not in English, it should be omitted. This has nothing to do with date formatting. MrOllie (talk) 14:27, 13 June 2023 (UTC)[reply]

Less marketing speak?[edit]

Reading over this article a few times, and this whole thing feels less like a plain explanation of a software development process and more along the lines of a cult recruitment manifesto.

Key issues: Too many words to explain nothing, Long run on paragraphs that aim to make the eyes glaze over. Should the entire manifesto be even printed within the article instead of just being left as an external link? An absurd amount of hideous buzzwords complimenting the look as a cult manifesto. The porthole portal of links in the middle of the article, spinning potential readers about into a traffic circle of useless information.

Trying to summarize for a more concise article: Agile is a hope & pray type philosophy towards development schemed up by people who don't know software development. It relies on being a constantly moving target with irresponsibly short goals, and overrelies on kissing the butt of a potential customer by overcommunicating with them daily. If left to their own devices, Agile developers would skip many of the standards and testing required of them by ISO and other such associations. Documentation is considered a devil of the details and other people should document the code made in 24 hours on a 7 hour coffee bender. 2601:540:C700:42DF:76C8:5F43:53F1:5C95 (talk) 06:49, 27 July 2023 (UTC)[reply]

Confusing table perhaps showing non-tabular data?[edit]

The table titled "Home grounds of different development methods" starts off being tabular, with each row seeming to address one feature of the development environment—criticality, developer experience, etc. But at the fourth row it goes off the rails, with the first two columns addressing the number of developers and the third column mentioning (again) requirements. The fifth row mentions culture in the first two columns and "Extreme quality" in the third.

Essentially it would seem impossible to add row labels to the table because it is unclear how one would label rows 4 and 5.

Perhaps it could be expanded with some blank cells so the nonsequitor entries in column 3 be in their own rows.38.23.161.163 (talk) 21:48, 16 January 2024 (UTC)[reply]

Duplicate/missing paragraphs[edit]

The paragraphs titled "Behavior-driven development", "Continuous integration", and "Cross-functional team" all contain the same text, which is a copy of the "Agile Testing" paragraph.38.23.161.163 (talk) 22:08, 16 January 2024 (UTC)[reply]