Talk:Agile software development/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3

Testing in agile and waterfall

Nothing, in any development methodolgy, advocates testing after development. Developers are supposed to always test their work. About the only thing that agile does is make it obvious who is not testing their code earlier. Also, I know people like to think there is only agile and waterfall, but there are many other methods. http://en.wikipedia.org/wiki/Software_development_methodology All should be considered for every project as they each have unique attributes that solve problems in ways that fit the problem. — Preceding unsigned comment added by 76.97.227.185 (talk) 03:59, 16 May 2012 (UTC)



Mattford63 (talk) 16:04, 22 March 2012 (UTC)

This looks incorrect.

Simplicity- The art of maximizing the amount of work not done - is essential  — Preceding unsigned comment added by 64.129.150.234 (talk) 20:22, 25 September 2012 (UTC)

Neutrality

This article reads very much like a sales pitch and has very little in the way of tangible information. 195.46.249.229 (talk) 08:18, 27 February 2013 (UTC)

Can you be more specific? Can you specify what information is missing? Can you suggest sources for this information? Can you give examples of statements that are promotional in nature? --Boson (talk) 09:08, 27 February 2013 (UTC)

GSD links to Graphical Systems Design.

The intention was not refer Global Systems Development?

Wikihug — Preceding unsigned comment added by T marques silva (talk • contribs) 21:37, 11 April 2013 (UTC)

Need Proofreading

Please proofread this artical, you have some spelling mistakes. — Preceding unsigned comment added by 69.155.118.207 (talk) 8 July 2013

Could you be more specific? Are you, perhaps, referring to the non-US spelling analyse or to colocated, which is an alternative spelling of "co-located" (not collocated)? --Boson (talk) 19:46, 8 July 2013 (UTC)

Possible copyright violation removed

I've undone revision 554926628, which seems to have been copy/pasted from http://www.versionone.com/Agile101/Agile-Software-Development-Benefits/. Its associated image appears to have been removed already, and I'm notifying the author of the revision via talk page. --Mount Flatten (talk) 21:12, 2 July 2013 (UTC)

I'm with VersionOne and the use of the Agile Development Poster is approved as long as it links back to our site. The user, Rickard, made the poster blue and cited it as his own work. That needs to be removed, immediately. - VersionOne --Agilista (talk) 15:17, 20 August 2013 (UTC)

Development life cycle poster

Agilista 8/20/2013 - copyrighted material - VersionOne Agile Development Poster

The main image on this site is a direct copy of my company's original material. I want it taken down immediately.

VersionOne Agile Development Poster --Agilista (talk) 15:17, 20 August 2013 (UTC)

Actually, it is a derivative work based upon this image [1] that was uploaded by User:Dbenson on behalf of VersionOne and given a Creative Commons Attribution CC-BY-SA license. As such, you cannot simply ask that it be removed. I am currently working to add the proper attributions to the image description page, and will add it back to the article once that is done. --| Uncle Milty | talk | 16:31, 20 August 2013 (UTC)

Do we really need this poster at all?

Does the poster add anything useful to the article or is it merely a promotional poster containing a collection of vaguely relevant buzzwords, in an order that might reflect a particular development model, added by someone with a conflict of interest? --Boson (talk) 14:30, 21 August 2013 (UTC)

Well, it does look good, and in its present state it has no obvious ties to any one company. Buzzword-wise it is different from the original. --| Uncle Milty | talk | 16:16, 21 August 2013 (UTC)

I suppose it is somewhat pleasing aesthetically, but if we just want a sexy picture showing an agile model we can probably find something better. Rather than the graphic helping to understand the article, the more I look at the graphic, the more confused I am. Is the image supposed to illustrate something described in the article? The arrows (pointing toward 'DONE') suggest separate sequences of actions but what is the implied relationship between the words, e.g.

  • under "CONTINUOUS AND AUTOMATED"
    • build
    • workflow
    • profiling
    • deployment
    • sqale (?)
    • integration
    • testing

Is that supposed to be a sequence? Or is "integration" supposed to be in the middle?

The same applies to the other "rings":, e.g.

  • What is the relationship between "kiss" and "RELEASE" or "self-reliance" and "DAILY"?

Is the sequence suppposed to be repeated for each iteration? What about the values? Are they based on the agile manifesto? Do they represent some company's values? If "frequency" is a value, frequency of what? What is the Agile Release Train doing?

I'm also not very happy with the attribution details within the image:

  • Author: rickard.agile@gmail.com
  • Version 2.0, Original:VersionOne

--Boson (talk) 18:10, 21 August 2013 (UTC)

Response to the Poster Queries

I must say I am but surprised at some of the comments, but who am to judge :) So, let me answer some of the queries that have been raised.

More Copyleft than Right
I think Uncle Milty is correct. It is a derivative and even if it was copy righted, I am not sure that it's rights would hold up. After all it has been on Wikipedia since July 2010 for 3 years now, without the VersionOne logo and nobody I have heard about has raised any issues with it being copyrighted on Wikipedia.

Not only that but VersionOne seemly give this away for free (albeit it seems they data capture your email to send it to you, source) so, I am not sure where the monetary or brand damage would occur from an infringement. If any did exist which I am not sure it does.

While one could argue they are similar they could also equally argue they are clearly very different. For example the colours, fonts and labels are not the same. Some labels are, but then these are often labels like “testing” which could ordain any poster. As an example of proof check out the XP diagram which clearly shows the feedback look cycles: http://en.wikipedia.org/wiki/File:Extreme_Programming.svg So, even the cycles (rings) are not new concept to Agile posters in general. No one has ever complained about XP poster, well in this regards to the VersionOne poster anyway.

As far as I am aware the author has received no official correspondence from VersionOne or anyone really who has taken umbrage with this new version. Even if VersionOne did so, that imho could be a mistake as it would only look like “sour grapes” and highlight the new poster even more. Free press.

Also imho I am not sure that the Agile community would look favourably on a company taking on the little guy. Especially as also imho VersionOne are one of the leaders within their field of expertise. So, does Agilista represent the official line of VersionOne? And why have they not contacted the author so, he can gain free press? I think one could conjecture the answer.

But at the very least the new poster is not copy righted and is free for use for everyone on the Internet. Which means when it comes to choose between the two, if the VersionOne poster is indeed copyrighted with those restrictions then we should not have it on Wikipedia and use the new one for that reason alone. That is if Agilister is correct. But in my view it is Uncle Milty who is correct.

Value from an Agile Poster
A poster brings value of course as it can show concepts/buzzwords on one page of what could be involved within a subject. Clearly with the new poster it could be viewed that Agile Development as a representation of Software Development is complex. There is a lot involved.

The 'arrows' as they have been called are well known to be cycles of the feedback loop, which is a well known common concept within Agile. And are there is no order of relevance in the poster, which is important as there should not be. Hence it is not sequential by its nature. Also nothing is mandated so, as with Agile itself you take what you want or don't and do as you please. Think of it more of as a guide.

The words under "CONTINUOUS AND AUTOMATED" mean that these activities should be repeatable, reusable and automated. For example “testing” could be performed by lots people, but that is prone to error and cost increase, quality is improved by automating such an activity. And it is the Agile approach that has often been a proponent of this. It also highlights a difference in that the previous poster did not state that these activities (or even all of them) should be automated. Now one could argue that it was obvious, but I myself have worked at place where companies do not “get it” and continue to perform activities manually. I am sure I am not alone. By stating "CONTINUOUS AND AUTOMATED" it makes it clear and thus ensures the value add.

Sqale is actually referenced within Wikipedia itself and within an Agile context here: [[2]]

Integration in the middle I would view as being a mere coincidence. However it's a nice one as it lends to the concept of CI. A well spotted bonus :)

KISS concept in relation to Development is also on Wikipedia: [It Simple] And relates to Releases as the simpler you make them the less risk you take on. As is illustrated by a well known diagram on Wikipedia here: [[3]]. The change is small so, less Risk is involved within a Release. The diagram is from the DevOps page (also on the Poster and considered as part of the Agile approach).

I find it puzzling that the word frequency is queried as a value. In the Agile manifesto one of the principals clearly states:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Also you need your feedback loop to be frequent for it to be returned within a timescale that could be of value.

Self Reliance label is a new idea that I personally have not seen elsewhere. This in fact extends one of the principals stated as:
The best architectures, requirements, and designs emerge from self-organizing teams.

Even further by implying that organising yourselves is not enough, if you can be self reliant then dependencies are removed and you can increase the value of your delivery.

ART is an agile approach for Agile Portfolio management. It was I believe invented by Dean Leffingwell, however anyone can use it as the concept is fully published. They can also use it in anyway they want themselevs. For example here is a link to an article that is not from Dean or his people that talks about ART: train

I think the nice concept here is that the ART (the craft) goes in and the QED comes out. As we know QED also stands for "which had to be demonstrated" for as we know one of the major differences between Agile and Waterfall is that the Agile approach proves itself through demonstration and not predictive (which is often wrong) like Waterfall. Wikipedia link once again: [[4]]

I am not sure where the so called unhappiness with the attribution details comes from. One could conjecture that quite a few CC images do not even put the attribution on the image so, at least the poster has complied with the requirements. As it has not been stated what the unhappiness is about one could conjecture that the author could be unhappy that people just say they are unhappy but do not say way.

What's New? In the so called New Poster?
Actually one could say quite a lot.

The most major omission from the VersionOne poster that is in the new one for me is Production. Is not having Visibility of your release when live an Agile approach? A lot of the DevOps movement has pushed the view that Production is just as important as Development. So, this is new to the poster and adds value for me.

ART (expert craft) goes in QED (demo'ed proof) comes out.

The Done symbol. The target is to get things Done. Multiple arrows, could also mean Done Done. Very Agile.

Combining Burncharts into one icon, removing reducnecy of two icons from the original and adding the Pipeline icon to show that Agile teams do indeed plan (anti-agile myths like to view it as all ad-hoc).

Contentious Delivery rather than Accelerated Delivery. While its good to be fast the concept of CD is that the customer can pull the release whenever they need it as its ready to go. Very important for satisfying the 1st Agile principal: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

And I could go on with the rest, but for me the best part is that it is fully CC licensed and the CC logo is used on the Poster. Therefore we can all use it and there can be no arguments on restrictions. And that is clearest difference for me.

Poster Summary
In summary I find it strange that no one has said anything against the original poster in all this time, but as soon as a new evolved and copyleft version comes out, there seems to be a some activity of deterers. Yet the new one is supposedly more in the spirit of Wikipedia, CC and Agile than the previous one. Not only that but the talk page clearly states:

* This is not a forum for general discussion of the article's subject.

Yet this where we have ended up. For me it's simple, the idea and previous poster was never questioned before, the Agile community seem to like such posters, the new one is an improvement with new concepts and is freely available with no closed restrictions. Therefore imho it stands as is, a valid and viable contribution within the spirit of Wikipedia. — Preceding unsigned comment added by LazyFan (talk • contribs) 22:53, 26 August 2013 (UTC)

Content of the new poster and history (reply to above)

I don't think it is true that the previous poster was never questioned. It was first included as an external link, I believe here It was, in my view at the time, promotional and was removed several times, not just by me, e.g. here and here and re-inserted by Dbenson, who stated that he/she was not affiliated with VersionOne and that the poster was popular with developers; so I believe they got the benefit of the doubt and it stayed in. I don't remember the details. I think I was distracted by other topics. It was later added as a file. The image was later modified to remove the company name, here, with the edit summary "Change image: the previous hidden advertisement was really unaccaptable".

My problem with the content (I have not checked to see if all my objections also apply to the old poster) is that it does not add to the reader's understanding of the article content. As I said, it appears to me to be a jumble of buzzwords. I am not that worried about individual buzzwords (except perhaps the capitalization or lack thereof); most of them clearly have something to do with the topic. However, the diagram appears to be trying to show some sort of relationship or grouping of the concepts, as indicated by the arrows and "rings" but they seem to be a jumble. As LazyFan (talk · contribs) writes "The 'arrows' as they have been called are well known to be cycles of the feedback loop", but that, to me implies a sequence. So I am not sure how to understand "And are there is no order of relevance in the poster, which is important as there should not be. Hence it is not sequential by its nature". There is something that looks like a loop headed "DAILY"; in that loop there are words like "commits", "self-reliance", "collaboration" that appear to be in a sequence, as indicated by being placed in that order and accompanied by arrows. So again,why is "self-reliance" included in a loop that appears to be headed "DAILY"? Or is this supposed to be read as a collection of about 50 concepts (some bolded) in some sort of "random" order on a background of arrows. I still don't know what the diagram is trying to tell me. I am also not sure what is meant by "the 'arrows' as they have been called". What else would you call them? They have points on them. They all point in a clockwise direction. They look like arrows. They appear to show direction and sequence. It is only when you look at the words that the sequence and grouping do not make sense. --Boson (talk) 01:47, 27 August 2013 (UTC)

— Preceding unsigned comment added by LazyFan (talk • contribs) 11:15, 29 August 2013 (UTC)
I think you may have misunderstood my reference to sequences. There may be no (notional) "overall" sequence in agile development like that ascribed to the waterfall model, you can have iterations within iterations, etc. However, arrows represent time, meaning that within each cycle the activities are, at least notionally, performed in a sequence. I have no problem with the other diagrams you have linked to. For instance:
I am also not especially happy with the original diagram's use of arrows. For instance: at the bottom right, coming out of the process there is an arrow, labelled "Working Software". Eminently sensible! It shows that what comes out of the cycles is working software. But at the top left there is an equivalent arrow, pointing into the process; we expect it to show the input to the process, but it is labelled "Agility is ...". The new diagram is not really better: the arrow bottom right is now labelled "Quality Enhanced Delivery" (not sure if that is an improvement; it sounds more like something that comes out of a buzzword generator) and the arrow at top left, which we expect to show the input is labelled "Agile Release Train". I suppose that might all be OK if this were a diagram explaining a process described in detail in the text, with reference to the labels, but it is not.
--Boson (talk) 13:53, 29 August 2013 (UTC)

The reasons I was somewhat "unhappy" with the attribution on the poster were:

  • The method of attribution may also serve the goal of promotion by encouraging readers to contact the author. The inclusion of an e-mail address does not help to dispel any impression of promotion.
  • The use of the words "Version 2.0" might be understood to mean that this is a new version of an existing product, implying some connection between the producers, analagous to "Word 2.0, Original: Microsoft".
  • The words "Version 2.0" might be seen as a punning reference to the company "VersionOne" especially if this poster, or its author, is perceived as being in some way in competition with VersionOne or their poster. The idea of a battleground is encouraged by edit summaries like "replaced the poster that was there before, seems someone doesn't like competition".([5])

--Boson (talk) 23:13, 27 August 2013 (UTC)

  • I believe the email address is very discrete and tiny, I see it as only there for answering of any queries. And so, that the author does not hide away. I have used it to get answers to certain queries such as "what does gqm stand for?". Most won't care to contact the author and the authors full name is not supplied so, if it is promotion it is a failed attempt imho. Hardly self-credit boasting really. And as stated by correctly by Uncle Milty no company is getting any credit. In fact the only logo on there is the Creative Commons one. If anything it promotes that. It is attempting to be aligned with the wikipedia and CC approach and free for all.
  • The comment on the competition was by me because someone removed the poster with no reason and from a strange wiki id (a someone of persons unknown) which at the time I think had never made a change before. So, clearly a battleground act on their part as you say, and with no attempt of justification. I think the comment was fair under the circumstances.
  • I think you make a sailent point on the Version issue. But to be fair the problem is what to do? Make no reference? Say Original Version 1.0 from VersionOne? Which ever way it's done it could be viewed as very confusing. I think the issue of versioning here is that VersionOne is a difficult name to get around in regards to versioning. Can't really blame the author for what VersionOne the company have decided to brand themselevs. You should take up that cause with VerisonOne themselevs. As stated I rate VersionOne highly so, I shall leave the naming issues between VersionOne and yourself.
  • However I do think the author has made a mistake in attributing to VersionOne, imho while some parts look similar many do not and any that do, have been done before in other posters (such as the XP ones). Therefore the author should have registered it as a NEW image as for me it is new. New colours, New Fonts, New Labels, New Icons. One could say what about the cycles approach. But I would say you could say that about the XP diagrams as well. That and any other perceived similarities are hardly exclusive for copyright. It is not a copy, it is new. So, I think the author should republish with no attribs and possibly no email to keep you happy?
— Preceding unsigned comment added by LazyFan (talk • contribs) 11:15, 29 August 2013 (UTC)

Copyright issue

As regards the copyright issue, the potential problem I see is as follows:

  • The copyright of the original work apparently belonged to VersionOne.
  • Their Web site has a clear copyright notice.
  • There does not appear to be an OTRS message related to the poster.
  • The poster was apparently first uploaded and included by Dbenson (talk · contribs) claiming permission by email from VersionOne and apparently claiming to be acting with them ("Original uploader was Dbenson at en.wikipedia and VersionOne, Inc.")
  • Perhaps someone like Moonriddengirl (talk · contribs) can advise on the validity of the copyright permission based on an alleged email with unknown contents.
  • There was also a problem concerning correct attribution for the derivative works but as I understand it that is no longer an issue.
  • I do not know if the author's moral rights are an issue.
  • Since a user apparently claiming to be acting for VersionOne made a comment that looked something like a take down notice, I imagine it might be appropriate for an administrator to involve Foundation staff.
  • If we do not have valid permission for the old image, we do not have permission for the derived works.

--Boson (talk) 01:47, 27 August 2013 (UTC)

  • If permission isn't verified on the website or through WP:OTRS, we are not able to accept it. @Agilista:, you absolutely do have the right to request the removal of material to which you own the copyright. We can't actually remove it on this project because it's hosted at Wikimedia Commons and each project has its own administrators and processes, but you have a couple of options. Your quickest and best bet is likely to write to the volunteer response team from an email address that shows your association with VersionOne to explain that this usage was not authorized, although you can also send an official takedown request (this is generally a slower avenue). Please see Wikipedia:Contact us - Licensing. I have flagged the lack of formal permission on Commons, which generally will mean they will be deleted after a week unless proof of license is provided by VersionOne, but if you want to talk to the Commons community about whether or not there is any other avenue for requesting removal, you might want to leave a note at Commons:Commons/Village pump/Copyrights. --Moonriddengirl (talk) 00:31, 28 August 2013 (UTC)
  • For copyrights are we talking about the VersionOne poster on wikipedia? If so, I agree. As for the new Poster for me it is new and if people feel the derivation makes it invalid then the author should republish without the attribution. But then in my view VersionOne would miss out on being one of the great inspirations behind Agile evolution (but not the only one as clearly it is new). A shame. But at A poster would be allowed on wikipedia and be free for everyone and free of copyrights.
  • As an aside if now that a new poster has come out, VersionOne decide to enforce copyright on their image (not the new one) does this mean wikipedia can no longer display it? That would also be a shame as personally I like both of them for different reasons.
— Preceding unsigned comment added by LazyFan (talk • contribs) 11:15, 29 August 2013 (UTC)
In my view, the later image (File:Agile Development Poster 2.0.png) - as well as several other images - is quite obviously (directly or indirectly) derived from the original image (File:Agile-Software-Development-Poster-En.pdf):
  • The graphic elements, especially the arrows and the arrangement of the text are largely identical, except for a change in colour.
  • The headings ("Strategy", "Release", "Iteration", etc.) are the same (even the style is the same).
  • Though quite a lot of text has been added, most of the original text has been retained.
Republishing the later image without attribution would (in my opinion) merely compound any violation of copyright.
The derivative works were apparently created in good faith, since the original image appeared to have been published under a free licence. However, since the take-down comment above , ostensibly from someone representing the copyright owner, the copyright release under a free licence has been called into question. It now looks as if VersionOne were happy enough to have their original image displayed (possibly for promotional reasons) but were not happy about others creating derivative works, as would be required by a Wikipedia-compatible licence. So we need evidence of explicit permission for publication under an appropriate licence from the original copyright holder.
--Boson (talk) 12:37, 29 August 2013 (UTC)

Code vs. Documentation

This whole section is completely bogus. If Rakitin wants to make those remarks about the "Agile Manifesto" he can because the Agile Manifesto is completely vague, and frankly bull-shit. If you want to refute those claims you need citations! Further, this section states "... a lacking of documentation of various forms is seen as a major problem. In this respect, agile development is no different from other software development methodology." and cites the article titled "Architectural design and documentation: Waste in agile development?" in support of that. That is wrong. In the very abstract of that article it is stated "There is a problem with documentation and architectural design in agile projects.". This article is suggesting documentation tends to suck to the detriment in "Agile" projects. This article supports Rakitin views if anything. — Preceding unsigned comment added by 124.168.77.208 (talk) 12:57:24, 17 January 2014 (UTC)

I'm not sure if I fully understand the purpose of your edits to the article, but we seem to be agreed that the text that purports to refute Rakitin is not in line with Wikipedia policies. So I propose to remove the rest of the section following the first two sentences.
Any views, interpretations, or assessments need to be presented as such and correctly attributed.
This is done with respect to Rakitin's views. The following text, however, contains a number of unsourced and unattributed views, assessments or interpretations.
  • 'He continues to translate the above statement as: "We want to spend all our time coding. Remember, real programmers don’t write documentation." '
It is not clear if the text in quotation marks is intended to be read as a verbatim quote from Rakitin.
If so, it should be correctly attributed in the text.
If not, it would appear to be a (possibly biased or overstated) interpretation of his comments by a Wikipedia editor;
  • ' Yet a more thorough look reveals that this interpretation is over-simplified. '
This is a judgment written in Wikipedia's voice, which is unacceptable. If it is a view, it should be presented as such, it should be attributed in the text,and it should be appropriately sourced.
  • 'Agitating against all kinds of documentation is not what the Agile Manifesto intended. Instead, it wants to say that working software will be more useful and welcome than just presenting documents to clients in meetings (see above). '
This would also appear to be original research in the form of a Wikipedia-voice assessment of both the Agile Manifesto and Rakitin's interpretation of the manifesto . If it is a view that has been publicly expressed in reliable sources, it should be presented as such, it should be attributed in the text,and it should be appropriately sourced.
  • 'And indeed, a survey among software engineering experts found that documentation is by no means regarded as unnecessary or waste.. More than that, a lacking of documentation of various forms is seen as a major problem. '
The authors of the survey and the identity or affiliation of the "software engineering experts" are not given, so the views expressed are not adequately attributed. Unless it is documented that the view "documentation is by no means regarded as unnecessary . . . " is one expressed by representative proponents of agile software development, the argument could be seen as supporting or conflicting with Rakitin's views. In any case it appears to be original research (synthesis).
  • ' In this respect, agile development is no different from other software development methodology. '
I think we need a quotation indicating that the authors actually expressed the view that agile development is no different from other software development methodology in this respect, which I think would normally be understood to mean that agile methodology attaches as much importance to documentation as other methodologies).
Whether Rakitin's views are sufficiently noteworthy or are given undue weight is another issue, which should perhaps be discussed later. At first sight, the fact that they were published in IEEE Computer would suggest that they are relevant.
--Boson (talk) 18:09, 18 January 2014 (UTC)
This article supports Rakitin views if anything. -- No, misunderstood. It's opposing Rakitin's writing, and clarifying what Agile really means, just enough documentation, not no documentation at all, or documentation is rejected by Agile. Softzen (talk) 09:17, 24 January 2014 (UTC)
I see you have reverted my change but not addressed my policy concerns. To repeat just one point: Rakitin's views, expressed in a professional IEEE journal, are attributed, but this is followed by a rebuttal written in Wikipedia's voice. It is not a question of good or bad writing; it is a question of attribution etc. in accordance with policy. --Boson (talk) 12:15, 24 January 2014 (UTC)
My other point was whether Rakitin's opinion should be discussed at all. It was raised in a letter to the editor of IEEE Computing, not in a peer-reviewed article. The source should be reliable enough for verifying Rakitin's views, but it is not clear whether his views are being given undue weight, relative to his significance. Personally, I would be in favour of removing the whole section. Agile software development is adequately described without this section, which really just states that some people are cynical about it (or rather one particular point).--Boson (talk) 12:31, 24 January 2014 (UTC)
This section is valuable especially to beginners who are unfamiliar with Agile values and practices, by clarifying Agile's just enough and balancing philosophy. There have been misunderstandings on agile documentation for long. Please see Do Agile Methods Require Documentation? and case studies in the CIO mag,

Misapprehensions about agile still run rampant in IT organizations. Eugene Nizker, a former financial services CIO and current consultant, ticks off the most infamous ones: Agile teams do not plan. Agile teams skip design. Agile teams do not test. Agile means no documentation.

You'll find this issue of code vs. documentation isn't a trifle, and Rakitin's not alone. So I suggest keeping and expanding it. Softzen (talk) 13:19, 24 January 2014 (UTC)
whether Rakitin's opinion should be discussed at all -- Boson, I think Rakitin's cynical words are quite a good lead. You last edit has made it even clearer. Thanks! Softzen (talk) 13:39, 24 January 2014 (UTC)
On reflection, I think a section on this topic is important, and it has been improved by your additions. I think my main problem with it in its current state (and in particular in its previous state) is that it starts off with a criticism before explaining what agile "methodology" means, and then appears to rebut the criticism (in Wikipedia's voice) appearing to say: there is criticism, but the critics are wrong because (Wikipedia says) they haven't understood it. I think I would be happier if it were expanded and ordered the other way round:
  1. This is how some Agile proponents explain what "working software over comprehensive documentation" means: . . . .
  2. Some critics of Agile say this "mantra" is used to excuse not having good documentation . . .
. . . though not in those words.
That's not Wikipedia's voice, but facts and leading experts' views have been expressed. I don't think the new/normal order is necessary, as not every article or section should be written by one same template, the agile value has been explained somewhere above, and the current writing style (quote, then rebut) is quite good and natural, for me at least. Softzen (talk) 01:47, 30 January 2014 (UTC)
Both sides of the debate probably overstate the case, if we are looking for an objective appraisal, so I would be cautious about citing authors to support "this is true" rather than "this is one view". For instance Ambler's equating "JBGE" and "ideal" is subjective. Like other requirements, meta-requirements are not just about binary requirements. --Boson (talk) 16:33, 24 January 2014 (UTC)
I appreciate your rigorousness. Frankly, the reality is that much of the Agile content (e.g. statements about Scrum, XP, etc.) is now quite subjective, not strictly objective. Scientific researches and convincible evidences in this field are still few. However, it is justified and valuable to record industry experiences, facts and leaders' views to reflect the status quo, the issues and arguments, and what we have learned, as not every Wikipedia article needs to be a scientific paper without flaws. Softzen (talk) 02:52, 30 January 2014 (UTC)
I have no objection to recording " industry experiences, facts and leaders' views to reflect the status quo" but when there are differing (non-fringe) views they have to be expressed as views and attributed. I do not think it is acceptable to say, in effect:
  1. A says XYZ.
  2. He is wrong.
That is using Wikipedia's voice to state who is right.
In this case,
  1. we (earlier) present the Agile proponents' statement of what Agile software development is (more or less as fact);
  2. we then present Rakitin's criticism: "What they really mean is . . . ";
  3. we then present Wikipedia's statement of fact: "No they don't."
I understand that both Rakitin and Ambler are authors who also represent companies with an interest in the software development field. --Boson (talk) 12:37, 30 January 2014 (UTC)
I've added Jim Highsmith's quote We embrace documentation... to the above Agile values section. Become better? Softzen (talk) 04:07, 7 February 2014 (UTC)
The quote is useful, but it is not our business to state that this is "a clear and accruate interpretation of the agile values". I have reworded to remove the editorializing. --Boson (talk) 11:30, 7 February 2014 (UTC)
I have done some more condensing and rewording to address policy concerns. I think there is still a problem with the attribution of the Crystal quote to Cockburn. I couldn't find his name mentioned in the cited source, and it is not made clear where he wrote this. --Boson (talk) 12:20, 7 February 2014 (UTC)

NPOV?

This is like reading an ad for Agile. Things like: "Since then, the Agile Movement, with all its values, principles, methods, practices, tools, champions and practitioners, philosophies and cultures, has significantly changed the landscape of the modern software engineering and commercial software development in the Internet era"

Considering adding the NPOV template. Please discuss 188.207.125.243 (talk) 05:27, 18 June 2014 (UTC)

I am here for the same reason. The article is an insult. It not only reads like a brochure, it even is illustrated like one, and a brochure for management at that, not for computer-literate readers or readers that wish to become computer-literate. Lots of handwaving and little substance. Those illustrations are the doo on the icing. I am removing the local one at least till someone tells me what they are to convey: that a member of their staff has an engaging smile? That software workers sit around monitors? Do us a favour! JonRichfield (talk) 08:34, 24 July 2014 (UTC)

Introduction is odd

"Agile software development is a group of software development methods based on iterative and incremental development.."

By the manifesto, as referenced later within the article, Agile software development is a set of values that partially order aspects of software development. These values may indeed be used to categorise methods but it is wrong to give the impression that Agile software development can be defined as a group of (think concrete set) development methods.

The Guide to Agile Practices[1] also explicitly states that some agile approaches do away with iterations and that it is also possible to use iterative strategies which are not also incremental. It is clear that although typical, agile software development is definitely not based on iterative and incremental development. Polyhydra (talk) 12:35, 25 July 2014 (UTC)

Based on that Intro, are there any other methods than Agile? (please don't point to the Myth Waterfall method - I've never been anywhere that uses that, as it just doesn't make practical sense. ZhuLien 116.240.194.132 (talk) 03:49, 29 July 2014 (UTC)

Copyright policy

The article currently reproduces the complete text of the Agile Manifesto, including a copyright notice that is incompatible with Wikipedia copyright policy. The external links section already contains a link to the Agile Manifesto. The section on the manifesto should paraphrase the manifesto loosely or otherwise summarize its contents. --Boson (talk) 21:45, 24 July 2014 (UTC)

The Manifesto specifically says "© 2001, the above authors. this declaration may be freely copied in any form, but only in its entirety through this notice."

Since there is the note on the webpage, and I think the creators of the Manifesto want it widely spread, I don't have any problem in leaving it in its entirety (as required) in the article. It's useful to have the text inline, instead of having to click to read it. Clemwang (talk) 21:29, 28 July 2014 (UTC)

As I see it, we can reproduce material that
  1. is released in a form compatible with CC-BY-SA (which permits modification etc.) or
  2. is a fair use quotation (which would not normally permit quotation of the whole document).
The copyright holder explicitly states "but only in its entirety through this notice", essentially releasing the work under CC-BY-ND, meaning that neither condition is fulfilled. According to the Creative Commons license article, CC-BY-NC and CC-BY-ND "are not free content licenses, according to definitions such as DFSG or the Free Software Foundation's standards, and cannot be used in contexts that require these freedoms, such as Wikipedia".
If the copyright holders want it spread widely by means of Wikipedia, they should release it appropriately. --Boson (talk) 14:57, 29 July 2014 (UTC)

Question

Why is there no mention that this methodology gets most of its "new" ideas from the Free Software and/or Open Source development models used by those respective communities? —Preceding unsigned comment added by 205.193.94.40 (talk) 9 December 2010


Because it is the other way around, AGILE was here well before the free software movement. 169.253.194.1 (talk) 12:23, 30 July 2014 (UTC) George E. Haney III, PMP, MPM, MCTS

XP, Scrum, Crystal, etc. are Agile Methods

The History sections says: "Methodologies similar to Agile created prior to 2000—include Scrum (1986), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and DSDM (1995)." However, according to p. 396 of Sommerville's Software Engineering textbook (reference 7 in the article), these methodologies are different types of agile methods. Will someone confirm this and make the change? —Preceding unsigned comment added by 76.216.63.120 (talk) 19 November 2007

Good point. The history section has changed significantly since you posted this, and the current version seems to have fixed this. Spring (talk) 01:01, 1 September 2014 (UTC)

Song lyrics

I agree that the page needs to stay - however, what's with the parody song lyrics here? They shed no light on the subject and don't look very professional. (More "joke".)—Preceding unsigned comment added by 150.203.2.60 (talk) 19 April 2005

Parody song lyrics no longer included in the current version of the article. Spring (talk) 01:03, 1 September 2014 (UTC)

Obvious error

I am a technical writer learning about the Agile method from Wikipedia. I noticed what must be a typo. Change "Simplicity—the art of maximizing the amount of work not done—is essential" to Simplicity—the art of minimizing the amount of work not done—is essential" — Preceding unsigned comment added by 199.207.253.96 (talk) 19:58, 1 July 2014 (UTC)

I am new here too, not a technical writer, but a long-time computer man. There is no reason to think that was a typo.
Think about it. It is poorly stated, but perfectly valid. You might find it helpful to consider the statement in the context of the following remarks dating back to the 1960s at the very least:
  • Creative laziness is essential to a good computer man;
  • Creative pathological laziness is essential to a great computer man.
Pathological laziness := compulsion to avoid work so obsessively, that it would have been less work to work. JonRichfield (talk) 06:13, 24 July 2014 (UTC)
I can confirm that the "maximizing" phrasing is not a typo. This is a direct quote from the "Principles behind the Agile Manifesto", which is one of the seminal documents for Agile software development. Spring (talk) 01:16, 1 September 2014 (UTC)

Proposed merge of Agile management into this article

  • Oppose. Agile Management is more than just doing Agile Software Development. Agile Management as a whole encompasses Agile Software Development. An Agile ICP (ICAgile Certified Professional) can be certified in Agile Programming and Agile Software design, or be certified in Agile Project Management (which is not Software Development), or even Agile Testing, Agile Leadership, Business Value Analysis, etc etc. There is more to Agile than just Software Development. If anything, I believe the Agile Software Development page should be merged into the Agile Management page. Or it could stand in it's own right, as a subset of Agile Management. Timbob80 (talk) 22:42, 7 December 2014 (UTC)
  • I also oppose the merge. In practice these are two different topics. Agile software development is a generally recognised, established set of methods or methodologies used for the development of software. Agile management is not that. --Boson (talk) 23:14, 7 December 2014 (UTC)

Should Agile be capitalised?

This is not consistent in the article — Preceding unsigned comment added by 62.25.109.196 (talk) 10:16, 5 February 2015 (UTC)

The link in the quote number 62 does not exist anymore. — Preceding unsigned comment added by 79.197.194.35 (talk) 15:53, 29 March 2015 (UTC)

Agile is not a methodology

Agile is not a methdology. This article, at the top, says that it is a "group of methodologies". Even that is debatable. It is actually a set of guiding principles, against which methodologies can be assessed as either "being agile" or "not agile". The whole article could do with revision with this in mind.

However, this particular sentence is particularly flawed

"While not prohibited by the agile methodology, the scrum master needs to ensure they have the capacity to act in the role of scrum master first and not working on tasks for the project."

Agile is not a methodology.

Scrum is an agile methodology. That is to say, scrum is a methodology that meets the Agile principles.

It's not even clear what a whole section on "Scrum master" is doing in an article about Agile. It belongs in an article on scrum.

GreenAsJade (talk) 15:07, 17 April 2015 (UTC)

It has been suggested that this article (Agile Automation) be merged into Agile software development. (Discuss) Proposed since March 2014.

Hi, new to all this so may be missing something but cannot find any reference to the above suggested merge?

Any help appreciated as I'm reviewing the Agile Automation article now.

I think the naming of the article is part of the problem given that automation (of testing etc) is relevant to agile software development, but this article really is concerned with the opportunities and problems of applying aspects of agile software development to the specialised field of software development Automated Industrial Control Systems (i.e. control of mechanical systems in the manufacturing and distributions industries).

Thanks, Villagemunchkin (talk) 13:09, 1 June 2015 (UTC)

Buzzwords

This whole article is a mess of buzzwords that sounds like it was written by the company.

First sentence: "Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams."

Sentence from article: "Compared to traditional software engineering, agile software development mainly targets complex systems and projects with dynamic, undeterministic and non-linear characteristics, where accurate estimates, stable plans, and predictions are often hard to get in early stages—and big up-front designs and arrangements would probably cause a lot of waste, i.e., are not economically sound."

A large amount of the article is like this. I'm adding templates to the top of the page for buzzwords and tone. Alexofthewoods99 (talk) 20:22, 23 July 2015 (UTC)

While I agree that we can always be more clear, many of the words aren't so much buzzwords as technical words. For example the "sentence form article" is mostly correct and not buzzwords. Re "written by the company" that comment is off the mark, since it's about a methodology, not a company. AliveFreeHappy (talk) 21:50, 23 July 2015 (UTC)
Which company? Agree that this article has many buzzwords like a marketplace for business and research promotions. But not the two sentences you've picked up, they're objective descriptions of facts or rationales. AliveFreeHappy is right. -- Softzen (talk) 00:50, 24 July 2015 (UTC)

Experience and Adoption Section

First in response to the comments above: some people seem to think that this is about a particular company or product, e.g. Alexofthewoods99 said "This whole article is a mess of buzzwords that sounds like it was written by the company." Agile is not a company or a product its an approach that many of the most advanced groups doing software development have adopted. Also, just as a point of Wiki politeness IMO comments like that aren't very constructive. It's more or less like saying "this article is crap make it better!" That's not very helpful and it can be kind of discouraging to people who actually EDIT the articles to constantly read such comments by people who just tag the articles and complain. Rant over. I agree the Experience and Adoption section doesn't flow well and I'm going to take a shot at reworking it. If anyone has more specific suggestions, pointers to papers or other sources, please chime in. I've got plenty of Agile refs already but more refs are always better. Feel free to look at my Sandbox to see work in progress but keep in mind it is JUST work in progress. Also, if anyone does want to check my Sandbox I moved the whole article there because I like to do that to see how things will look in context but at this point I'm only focusing on that one section. --MadScientistX11 (talk) 14:48, 2 October 2015 (UTC)

Its far from perfect now but I think definitely better. I defined the jargon terms that weren't already defined, added references, re-arranged and added text to make it flow better.  Done --MadScientistX11 (talk) 20:05, 2 October 2015 (UTC)

Agile Manifesto copyright

There is a copyright notice on the Agile Manifesto reproduction included in this article which appears to not wholly compatible with the CC BY-SA 3.0 that WP uses. 194.75.171.106 (talk) 11:43, 30 October 2015 (UTC)

Agreed. I have tagged the section. Since the text appears to be released under something like CC-BY-ND, this should not, in my opinion be in breach of copyright law, but it is in breach of the stricter Wikipedia:copyright policy. --Boson (talk) 12:37, 30 October 2015 (UTC)
Since the footnote already links to the original text, we could simply remove it here. Alternatively, someone could summarize the contents in their own words.--Boson (talk) 12:41, 30 October 2015 (UTC)
summary, reformat, ref here: (diff) - Thanks; LeoRomero (talk) 21:43, 11 November 2015 (UTC)

Relevance of Wirth's Law?

The section comparing Agile to Formal Methods includes the text "Limited requirements, limited features see Wirth's law" in the table row discussing requirements. Wirth's law refers to the execution speed of software, and doesn't seem to me to have anything to do with project requirements. Is there some reason to keep this reference in there? Strobie (talk) 13:44, 23 December 2015 (UTC)

Lede:by the preeminent software engineers of the late 1980s and early 1990s

pre-eminent adjective adjective: preeminent surpassing all others; very distinguished in some way. "the world's pre-eminent expert on asbestos" synonyms: greatest, leading, foremost, best, finest, chief, outstanding, excellent, distinguished, prominent, eminent, important, major, star, top, top-tier, topmost, famous, renowned, celebrated, illustrious, towering, supreme, superior, exceptional, unrivalled, unsurpassed, unequalled, inimitable, incomparable, matchless, peerless, unmatched, arch-, transcendent; More


Wow, up themselves much? Greglocock (talk) 11:30, 12 January 2016 (UTC)

SAFe as a separate topic

Could an article be created for 'Scaled agile framework (SAFe)" and linked to from the SAFe reference under the "Large-scale, offshore and distributed"section?

SAFe now has 30,000 practitioners in the world, the number of which has doubled every year since 2011. The framework is currently on version 4.0 (http://www.scaledagileframework.com/about/)

Thanks, Melissa

63.225.16.218 (talk) 22:18, 18 February 2016 (UTC)Melissa Reeve

There was an article for scaled agile framework, but it was deleted as unambiguous advertising. That's a red flag that this should be treated with caution. The number of practitioners reported by the company itself isn't an ideal way to judge notability. In order for this to be notable enough for an article, it would need reliable sources which are independent of SAFe. Looking for sources, I'm seeing some, but very few are usable. Mostly it's press releases and interviews (which aren't independent), and borderline blog-posts like Huffpost, Forbes, and InfoQ (which aren't reliable). If good sources exist, maybe they could be used to expand coverage here before spinning it off into its own article. Again, with caution, per WP:NOTADVERTISING. Grayfell (talk) 22:52, 18 February 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 4 external links on Agile software development. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 14:44, 5 October 2016 (UTC)

Agile vs. agile

The opening paragraph of the article claims "although originally written as Agile (with a capital A) this is progressively becoming deprecated." And uses citation 5 to support this claim("Agile With a Capital "A" Vs. agile With a Lowercase "a"". Rally. 2010. Retrieved 9 September 2015.) This article does not support the claim that upper case 'A' is becoming deprecated. It is claiming there is an important distinction between the two. The text should be changed to match what the citation actually says, or a different citation used. 130.216.95.213 (talk) 02:23, 20 October 2016 (UTC)

Agile Automation merge proposal

A merge from Agile Automation aws proposed in March 2014. The material in the source article is not of high quality and merging it here would create an WP:UNDUE issue. We have separate articles on agile applied to other fields (Agile management, Agile construction, Agile manufacturing) so there is no strong reason Agile Automation cannot remain a separate article for now. I am removing the merge proposal. ~Kvng (talk) 16:32, 17 February 2017 (UTC)

The Agile Jester

It has been asserted that a new role of agile jester is emerging. While there have been sporadic mentions of this as a tongue-in-cheek term, the role as described is more that of a scrum master. Other than the assertion, this has not been supported with citations. I have reverted the edit so that this can be discussed here before determining if it is mainstream enough to warrant inclusion in the article. Davidjcmorris  Talk  02:39, 11 May 2017 (UTC)

  1. ^ "Guide to Agile Practices". Agile Alliance. Retrieved 25 July 2014.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Agile_software_development/Archive_2&oldid=1136501369"