Talk:Agile software development

Low Quality Article

This article is too unscientific. It mostly regurgitates non-scientific professional literature, while ignoring relevant research. I'm going to add some research. If any agilisits out there take offence at my changes, please read the research before reverting anything.Paul Ralph (University of Auckland) (talk) 12:49, 5 February 2018 (UTC)

Please note that this content has been moved (rather than deleted); it is not significant enough in its own right to warrant being in the lead / lede paragraph. Also, the link you posted is to content behind a paywall; it's a bit hard if other editors are challenged to read this before they can challenge this edit. As it happens, my masters research topic was whether Agile Transformation worked or not, in which I referenced a paper by Dingsøyr which argued that agile practices do in fact help. I will reach out to you offline to suggest meeting up to discuss (as we know each other). Davidjcmorris  Talk  02:23, 7 February 2018 (UTC)

I never said that agile practices were devoid of benefits. There is, for example, evidence that Scrum increases productivity. I said there's no evidence that they increase agility. There are no validated measures of team agility, and you can't demonstrate a causal relationship on a dependent variable you can't measure. The fact that all these practices are called "agile" without anyone ever demonstrating that they increase agility is possibly the most important thing you could know about agile. It's like pfizer selling "cancer drugs" that don't fight cancer, or "anti-virals" that don't kill viruses. It's a "productivity practice" that doesn't increase productivity. It is very common on Wikipedia to point out the lack of scientific evidence supporting a thing in the introduction. And you don't get to discount research that's published behind a paywall. Paul Ralph (University of Auckland) (talk) 21:11, 7 February 2018 (UTC)

Can you clarify:

* What are you meaning by agility? Common uses included: Hypothesis driven experimentation, trying out ideas on a small scale. Early delivery of value (whether to customers / end-users or to the product owner / development team). Fast feedback to uncover change early and avoid too much investment in scope not required. The ability to absorb change without causing additional cost, by dropping lower priority scope. Etc. There is evidence that this happens.

* What you mean by scientific evidence? As Popper and others have said, it is hard to scientifically prove a hypothesis; so a theory should stand until there is evidence that disproves it. There is, however, an abundance of research in this field, following a wide range of research methodologies. Which methodologies would you regard as scientific and which not?

Incidentally, the research was not questioned, but rather the insistence that people read it before challenging the edit. The offer to discus the article and points raised in person still stands (I have emailed you separately about this). Davidjcmorris  Talk  01:26, 12 February 2018 (UTC)

Your conclusion about testing being performed during development as an agility indicator is false. Often testing happens at the end, but doesn't indicate agility 1 way or the other. What people call "Waterfall" now-a-days also had testing in it at various points along the dev life cycle (why "waterfall" is a misunderstood/derogatory misnomer). — Preceding unsigned comment added by 2603:9001:2708:7091:6C87:D82F:9846:8ADD (talk) 16:40, 9 August 2019 (UTC)

I know this is a slightly old debate but the biggest problem with this article is the lack of clarity. The introduction simply won't be understood by the vast majority of readers as it's full of buzzwords and never actually states in simple terms what agile software development is. It doesn't need more research, it needs someone who understands the topic and can write well for a general audience to edit it into something more useful to the target audience (i.e. people who don't already know what agile software development is). — Preceding unsigned comment added by 2A02:C7D:6623:9500:C866:C739:C5A0:3ACA (talk) 09:58, 8 June 2022 (UTC)

"work moves through software development lifecycle (SDLC) phases—with one phase being completed before another can start"

Agree. This is a farce that agile seems to actually need, to exist as a counter method. I've not seen waterfall used in commercial nor defense. 149.32.192.43 (talk) 16:27, 6 October 2022 (UTC)

Micromanaging?

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)

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)

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 can't just solve the problem before including lots of other people who have no idea what's going on and only slow things down.

"Snowbird summit" listed at Redirects for discussion

An editor has identified a potential problem with the redirect Snowbird summit and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 December 14 § Snowbird summit until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Rusalkii (talk) 04:39, 14 December 2022 (UTC)

Semi-protected edit request on 17 December 2022

{{subst:trim|1=

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. RealAspects (talk) 08:11, 17 December 2022 (UTC)

Semi-protected edit request on 6 January 2023

Insert after "Arie van Bennekum": "(DSDM)" Nickdevoil (talk) 15:46, 6 January 2023 (UTC)

 Not done: please provide reliable sources that support the change you want to be made. ScottishFinnishRadish (talk) 15:56, 6 January 2023 (UTC)

In software development

In software development, agile (sometimes written Agile)[1] practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s),[2] adaptive planning, evolutionary development, early delivery, continual improvement, and flexible responses to changes in requirements, capacity, and understanding of the problems to be solved.[3][4] Popularized in the 2001 Manifesto for Agile Software Development,[5] these values and principles were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.[6][7]

While there is much anecdotal evidence that adopting agile practices and values improves the effectiveness of software professionals, teams and organizations, the empirical evidence is mixed and hard to find.[8][9] 103.255.145.74 (talk) 14:16, 8 January 2023 (UTC)