Talk:Agile software development/Archive 1

Archive 1

Archive 2

Archive 3

Old posts

Any documentation to the success of the 2nd, 3rd, ... commercial release of agile software developed systems would greatly help as the current article touts agile software methodology as an effective way to deliver complete working software without any evidence to back up that claimed advantage. Furthermore, documentation to the cost of maintaining an agile methodology developed softare system would help since close to 3/4ths of the cost of a piece of softare is after it is released.

I read a book that showed charts of software development costs (Traditional vs XP; essentially Waterfall vs Agile); the charts indicate this pattern doesn't hold true for Agile methodology. I'd cite the book but I forgot the name. Slackmaster K 18:33, 18 July 2008 (UTC)

---

Link 10 doesnt work and archive.org doesnt have a copy of it and its not even listed at the references list at the bottom of the page. www.hacknot.com is apparently a mystery lost to the mists of ancient internet time.

---

This is an unnecessay page - Wikipedia is not an instruction manual. We don't have, say, When to use a riding mower rather than push mower or When to speak American English. The basic extreme programming page is more than sufficient, although it may need work or expansion. - DavidWBrooks 20:12, 6 May 2004 (UTC)

oh bollcks

Checkout "Waterfall model", "Moore's Law", etc. and get back to me when you get it. The page is far more than necessary. In fact Wikipedia is a primary source for me in keeping up with changes to technical terminology. In fact you could look up Riding Mower and Push Mower here and learn something. wjbean (UTC)

---

This page now includes the text formerly at Agile Methods. I believe the XP values and XP principles sections should be moved to the Extreme Programming page, but I'm to scared of trying to merge the related footnote references with the extensive list of references on the XP page. Niteowlneils 02:18, 21 Jul 2004 (UTC)

Check again. There was a mention in the Discussion page about there being 30-40 references, someone removed all but five; there are about a dozen now. Slackmaster K 18:33, 18 July 2008 (UTC)

---

This page is, as mentioned, unnecessary. In addition, it's not neutral. The author covered up his tracks pretty well, but it's still quite obvious he doesn't like XP. --jae 04:08, Dec 29, 2004 (UTC)

Why is it unnecessary? If you are going to knock the article at least give a substantive reason for knocking it. wjbean

Peer review requested for waterfall model.

Hi, I've just requested peer review for waterfall model. I'd really appreciate if some people could review the changes I've made. Thanks.  :) GeorgeBills 15:05, 17 November 2005 (UTC)

Agile vs Iterative-Incremental

Well, I think that all agile methodologies are just a subset of iterative-incremental models. In the section Ag. vs. I-I two differences are mentioned:

• time period of increments is measured in weeks -- but Iterative-Incremental model does not prescribe increments length,
• work is performed in a highly collaborative manner -- again, in the I-I model you are free to use any of the other methodologies when working on one increment, from the waterfall approach to a total chaos.

So, agile development is, let's call it, an "instance of I-I model" defined by its paramaters (increment length, increment development process, ...).

What is your opinion?

--Ondrejsv 10:29, 29 May 2006 (UTC)

I think that there are fundamental differences, and they are in the perspective of the values and principles. The iterative nature of delivery is merly an mechanism of providing it. It could be copied from iterative methodologies, but it isn't so important as is, for Agile. The agile is a framework for all lightweight methodologies, as they respect values and principles fom the manifesto. - Littlesal 20:47, 24 November 2006 (UTC)

Agile Software Development vs. Agile Unified process

What is the relation between Agile software development and Agile Unified Process ?!!!

"Both lightweight and heavy-weight methodologies may still lead to this breakdown as the user(s) attempts to facilitate within social/political environments within organizations. The probability of this breakdown can be directly correlated to the degree of processes inhibiting the risk of user(s) deviating from the organization standard, however at the cost of efficiency opportunities." This is quite possibly the most incomprehensible paragraph I've ever read. To whoever wrote it: kudos, you've achieved an unprecedented level of obfuscation. --IQpierce 19:25, 26 June 2006 (UTC)

some articles do need to be combined for these subjects

The current group of related articles to agile software development answered my questions, but they do need to be refactored. Mathiastck 17:31, 3 August 2006 (UTC)

Merge from Adaptation of Agile Methods

Merge from Adaptation of Agile Methods was suggested in April 2006. Since this has not been disputed, I intend to merge that article shortly. The result will still need cleaning up, but it will be in one place.
Boson 15:29, 27 August 2006 (UTC) Have now performed the merge. I hope that meets with approval. More refactoring probably needed as well as general cleanup and condensing.
Boson 16:50, 27 August 2006 (UTC)

Condense PRINCE2 discussion

The information on PRINCE2 appears to me to be much too detailled, going in the direction of a proof of concept or feasability study rather than an encyclopedia article. I would characterize it as an argument for using PRINCE2 for the management of agile software development and a lengthy demonstration by the author of one possible way of doing that. I don't, personally, disagree with the content, but I would delete the PRINCE2 sections and replace the section Agile methods and project management with something on the lines of the following:

Agile methods differ to a large degree in the way they cover project management. Some methods are supplemented with guidelines on project management, but there is generally not comprehensive support (footnote citing Abrahamsson et al., 2003). PRINCE2 has been suggested as a suitable, complementary project management system. -- adding a footnote citing Agile Alliance at http://agilealliancebeta.org/article/file/904/file.pdf

and quoting

PRINCE2 (Projects in Controlled Environments) . . . is a project management method that was specifically designed to be generic and independent of any particular project type or development method. As with DSDM,its use is dramatically on the increase in both the public and private sectors. As a development method and a project management method, the two should be complementary. Some have perceived the dynamic emphasis of DSDM and the control emphasis of PRINCE2 to be in conflict. However, this is not the case. When DSDM was being developed, those involved had PRINCE firmly in mind. This is reflected in a number of the DSDM principles and techniques – for example, product-based planning, the involved partnership of users and developers, and the strong emphasis on the underlying business case.

I thought I should propose it here before deleting a rather large chunk of text.
Boson 21:09, 30 August 2006 (UTC)

Have now done this and also tried to fix the citations. This still needs work, but I think the missing-citations problem is fixed; so I have removed the citations required template. Boson 23:06, 1 September 2006 (UTC)

I do disagree with the content here. I propose removing the citation of PRINCE2 altogether. The PRINCE2 methodology IS clearly in conflict with the philosophy of Agile - it is a documentation intensive, big phase methodology, and it is diametrically opposite to Agile. Although PRINCE2 is purportedly designed to be scaled according to the project's needs, the core philosophy is about "big-bang" delivery, and hence its application in an Agile project would result in what is known as PINO: PRINCE in Name Only. I would expect that both PRINCE2 and Agile practitioners would agree with this; on the whole, each probably believe that the strength of their approach is their rejection of each other. (This does not mean that they two practises exclude each other's techniques, just that their core philosophy is at odds.) —The preceding unsigned comment was added by 62.128.215.24 (talk • contribs) 2007-03-13.

I have now updated the link to agilealliance.org in the reference, which had become invalid owing to a reorganization of that Web site. The DSDM consortium seem to be pushing the ability to combine DSDM with PRINCE2, which is why I was loth to remove PRINCE2 completely. The reason may be "political" but it does seem to be a valid POV. I would not oppose its deletion but would welcome more input from the UK, where PRINCE2 may be a de facto standard(?). It would be nice to have more information on project management. The DSDM article could probably do with a rework as well. --Boson 22:36, 13 March 2007 (UTC)

(UK user, P2 practitioner) I can see how elements of P2 might work with Agile, but I can see a lot of other elements which seem to be at odds. I was suprised to see the comment in the text that Prince2 might be a suitable method for implementing Agile. I can actually see more similarities between the Programme methodology, Managing Successful Programmes (MSP) than with the P2 project methodology. For example, MSP focuses on Vision, Blueprint and the idea of Tranches, not an overall prescribed plan for the entire programme. —Preceding unsigned comment added by 84.12.40.226 (talk) 17:25, 12 May 2009 (UTC)

Merge from Manifesto for Agile Software Development

Supported. --Boson 23:03, 9 September 2006 (UTC)

Completed. Rich257 21:29, 19 September 2006 (UTC)

Industrial extreme programming

It really promises advance of XP. I added it in list as I saw it on cutter consortium site. Maybe it deserves an artical of its own. What do you think? Could you help me build it, if you want to help go to my user_talk page --Littlesal 21:53, 8 November 2006 (UTC)

Measuring Agility

This whole section appears to have been added by the author of the presentation that has been cited, and so by definition it presumably constitutes original research. Does the section really merit inclusion in this article?--Michig 14:45, 7 December 2006 (UTC)

Merge with Post-Agilism

Editors of this article- I've added the content from Post-Agilism into the eponymous section of this article. I'm not knowledgeable with this subject, so I prefer not to make any major edits here. For more context on the move, see Talk:Post-Agilism and Wikipedia:Articles for deletion/Post-Agilism. Thanks, A Train ^{take the} 17:47, 16 December 2006 (UTC)

thanks all

Notwithstanding the work you're obviously engaged in here, I found this article particularly helpful! Thanks to everyone for your efforts so far! HiTrish 19:04, 4 January 2007 (UTC)

I second that! Wjbean

Questionable pargraph removed

I removed the paragraph from the end of the "Principles behind agile methods ..." section. I think it is biased, not very encyclopedic in tone and makes unsupported assertions. Maybe the original author would like to try to fix it up. Here it is (Peashy 14:29, 15 February 2007 (UTC)):

One fundamental difference of an iterative/agile approach is the recognition that specs are typically built in a vacuum of theory prior to real-world experience. An iterative/agile development cycle forces the real world into the picture (thus "working code"), whereas the document driven process puts far too much pressure on the document author(s) to get it right the first time, which cannot be done. This is not an argument against documentation - just a recognition of documentation as a process tool and not the end goal. Further, the agile approach draws developers into the problem definition process, so that they are actively engaged in the solution. This active engagement also allows them to introduce new technology accelerators that the spec process would never have introduced.

Agile Developement

Thi site cane be more useful if practical examples are provided or case studies are provided.

C.A. Biplab Dutta Ray —The preceding unsigned comment was added by 59.95.173.212 (talk) 09:43, 14 April 2007 (UTC).

That sounds to me like a good idea for wikibooks:Computing department. (Wikipedia is not intended for textbooks or instruction manuals).--Boson 10:23, 14 April 2007 (UTC)

Ok. All fame and craze about Agile development provides far less thinking on the processes. I think the people who developed this methodology are averse to the idea of so-called processes coming under ISO9000, CMM etc. The argument about Agile is that it is fast. That is absolutely not true. Coz, except for 2x2 or 2+2, nothing is fast in this world. You have to do good planning, thinking and more planning before giving a solid output. Where is Agile supporting these characteristics. I am not sure. For sure it is more viable to implement to those products where user interface is important and requirements are not rigid.

I respectfully disagree. Agile Software development is about a mind-set of planning for and embracing change. Once the developers have a mindset that the requirements have flexibility, they change their approaches so that as many things on the project are as loosely coupled and configurable as possible. They use design patterns to ensure that, when the boss changes things at 11:59 in the project, it minimizes the impact of this change. That is the goal - to meet change with a smile instead of a sigh. That smile is possible by being smart and embracing the reality that things change because we cannot truly know everything up-front. Dprust 18:26, 14 May 2007 (UTC)

I have been reading about agile here and at other sites and with more than 200+ project management experience I have to say that agile could not deliver on major projects, as it is defined here. The discounting of initial planning is a major error, right at the beginning. Only with a review of the business requirements and the business vision & scope, can the direction of work be even contemplated. I do agree that you cannot plan all the work in detail at the beginning as well, this is unreasonable and all logic dictates that this effort is misguided effort, the farther you get from the starting point the more likely you will have departure. There are two scenarios to discuss here that highlight the breakdown of the agile approach. The first point is that no executive will provide an open ended cheque for work to be done. There needs to be some financial responsibility, which agile discounts completely. To secure funding the project leadership on both the IT and business side need to understand the costs involved, if for no other reason than to understand if the work is even worth doing. Without some basic planning, which in turn is based on understanding the clients basic goals from which the basic architecture and design are derived, you are working with a dart board on this point. Final example, how about building the next generation aircraft using agile? Without a plan ahead of time how will the various resources and vendors make the pieces come together in the end? Same for building a house. Should the drywall go in before the insulation? It could without a plan and understanding being developed from day one of what the goals are, how will the deliverable be used etc. On artifacts, if you discount these and do away with them, how will anyone on the team know what to do next?

Agile has a link to a burndown chart. When you read about this chart it cannot be built without a plan ahead of time of what needs to be done and the basic order of events. —Preceding unsigned comment added by Fl990 (talk • contribs) 15:04, 5 October 2009 (UTC)

Graphical Model

Could someone come up with a loose graphical model of Agile Software Development; similar to the Waterfall_model.png? If someone can give a verbal example I can come up with something. Thanks Wjbean

Unless somebody comes up with a graphic from a published source, the risk is that the answer to your question violates No Original Research. Iterator12n 20:24, 11 June 2007 (UTC)

Maps don't have to come from published sources to not be WP:OR; neither do photos or (obviously) text. Why do you think that this applies to maps? Merenta (talk) 22:22, 27 April 2008 (UTC)

Fl990 (talk) 15:00, 5 October 2009 (UTC)

Clarification

I clarified the first paragraph to include the goal of Agile Software engineering. It did not state the goal, so it was just a "framework", and learning that goal took a lot more reading later. Dprust 18:28, 14 May 2007 (UTC)

Additional content for Criticism section

I've read quite a few ACM and IEEE articles concerning the criticism of agile methods with respect to application security. For example, because there is no big up-front design, security is often addressed along the way rather than near the beginning. Would mentioning such issues (with references to the ACM/IEEE articles) be appropriate here? Gmazeroff 14:12, 11 June 2007 (UTC) GMazeroff

I think so - with the references, as you say. By the way, it is my experience that addressing security needs up front doesn't necessarily lead to better results than addressing them in the course of developing the successive iterations. It seems whatever you already know "for sure" should be addressed up-front, and whatever the customer and the developer learn in the course of developing and using the iterations can be addressed in the iterations still to come - including changes in the things they thought they knew "for sure." Iterator12n 19:39, 11 June 2007 (UTC)

203.57.241.67 03:27, 14 June 2007 (UTC) In reading this for the first time I can't help but view it as a sales pitch for using an Agile methodology rather than a balanced discussion of what it is and its pros and cons. While there is a "Criticisms" section, the criticisms mentioned are very quickly rebutted.

Like the above reader I am reading this for the first time and the article represents *far* from a NPOV. Another wikiarticle ruined by a lack of objectivity. —Preceding unsigned comment added by 212.69.54.14 (talk) 14:53, 16 October 2007 (UTC)

I agree with the two posters above. This article has a clear pro-Agile bias which should be addressed with a NPOV. —Preceding unsigned comment added by 216.87.87.19 (talk) 23:59, 12 March 2009 (UTC)

I've recently joined a group that uses the “Agile” development process (and SCRUM). After several weeks; I’m now convinced that Agile and SCRUM are a tool for bad management. They have a place (where, I would NEVER see being used in a real business) and when used in that place – all is fine. But businesses are using this as primary development. It removes all tracking, auditing, responsibility and documentation. It rewards bad behavior and waists time (daily stand up meeting). I’m not saying that “waterfall” is the best process, but any manager that is competent should seriously reconsider this process. As this is a discussion, I would like to know how for any form of long term software development project Agile could be considered “good”. (Long term here would be six ore more months). As noted above; it removes the documentation, and as such the audit ability. As nothing is documented, you can’t follow up and say what worked, and what did not work. For someone that is into Agile; please comment and follow up, how can this be considered good (Again for any form of long term project). Bomarc (talk) 17:53, 11 February 2009 (UTC)

Bomarc, totally agree. Fl990 (talk) 15:14, 5 October 2009 (UTC)

This article *really* needs work.

As a programmer with over 15 years of experience, I feel that this article fails to clearly describe a substantive "conceptual framework" mostly due to poor writing. The first sentence, as prominent as it could possibly be, is nearly useless. All software sporting a version stamp beyond 1.0 experiences development iterations. And, when it refers to 'the project' what project is it referring to? Shouldn't it say 'a software project' instead?

Some other things I'm wondering:

• What kind of risk is being minimized by developing software in short amounts of time? Seems to me that various risks are compounded when software is rushed out the door: bugs, security, etc.
• What is the scope of software project that gets delivered in "weeks, not months"?? Are we talking about a new OS for big iron? I doubt it. Are we talking about web wiki software written in PHP? perhaps. Or maybe a form to upload one picture on my niece's blog? I hope not. This repeated use of an arbitrary time frame in the discussion of such a general concept suggests the author completely lacks any understanding of the variability in scope exhibited by different software projects. It sounds like the author has been brainwashed by some motivational disciple of the 'agile programming' movement.
• the section titled "Contrasted with other iterative development methods" is especially poor for several reasons:

 - every software development method would like to build releasable software in a short time period.  also, aren't we *contrasting* things here?  this is listed as a similarity.
 - that stupid 'weeks not months' bit.
 - other forms of software aren't 'highly collaborative' ?

This article is lengthy and confused and sounds more like it was written by a poorly informed apologist for the movement rather than an objective author assessing a distinct development approach with its own unique earmarks. It should be completely rewritten.

---

Agile development will not necessarily get the entire project completed any sooner than the other processes. Instead delivery in weeks not months refers to each iteration or update of the software. Similar to the iteration approach this allows for early delivery dates for the most critical features. This allows the users of the software to test it out (similar to the prototype method) and be sure it is what they want and allow for changes in requirements.

---

—Preceding unsigned comment added by 65.46.168.254 (talk) 03:43, 10 September 2008 (UTC)

I agree with you (whoever you are). it's all over the place at the mo. It (the article) needs a cold-blooded and knowledgable editor. Matt Whyndham (talk) 17:25, 3 March 2008 (UTC)

If somebody had the time (a lot of time) he/she could analyze the article and make it into a case study: The Anatomy of a Real Bad Article, and the Many, Many Reasons it got that Way. If you had to make up a bad article, it wouldn’t be as bad as this one. A natural! For one thing, an article like this one exposes the subject as a fake. Happy for them, the promoters don't see it, they are blinded by vanity. Unbeatablevalue (talk) 22:28, 3 March 2008 (UTC)

Agile software development goes back to the time when English lit. majors took over software engineering. In the run up to Y2K, everybody with a half a brain was hired to swell the ranks. Once safely into the new millennium, after the consultancy firms had had their run, these people were looking for a new job. They could still write stories.... so here it came, garbage trucks of books about flavor-of-the-month agile development. Agile this or that is mostly a publishing event. The article provides an archeological record of that unfortunate course of history. Move on people, there’s nothing to see here. Unbeatablevalue (talk) 23:03, 3 March 2008 (UTC)

Whether or not it is real is irrelevant, as long as the article documenting its significance in the wider world is encyclopedic and well-referenced. Heck, we have an entire set of articles on creationism. ~ Jafet (spam) 19:51, 16 April 2008 (UTC)

Ha, significance in a wider world.... The agile software development movement is nothing more than a book publishing racket - books at $100 a pop. Written by people with a paper-thin engineering resume, they wouldn't recognize engineering if they fell smack into it. —Preceding unsigned comment added by 24.92.222.218 (talk) 02:14, 13 October 2008 (UTC)

Isn't agile about other processes besides software development?131.107.0.73 (talk) 23:58, 9 June 2008 (UTC)

One could argue that agile is about other processes as well as software development, however I believe this article makes a point to define what the software development model "Agile" is. This development model has its advantages and disadvantages just like all the others. It tends to work best with small teams on small projects better than large well defined mission critical ones. No process is a one size fits all. The article has a lot of information but it is poorly organized and needs extensive reworking. [burnit999] —Preceding unsigned comment added by 65.46.168.254 (talk) 03:34, 10 September 2008 (UTC)

The biggest problem is this entire thing is written in managementese; it looks like some PHB cranked it out with an obfuscation generator. I'd flag it as poorly written and confusing if I knew how to do that... JJ (talk) 16:10, 28 April 2009 (UTC)

Hehe! Enjoying the sharp comments very much, but for me the article is informative, however annoying the Managementese. The Agile software development seems to not be about software development, but rather about process management and administration in a tightbound relation to an end user that immediately can give criticism to software changes. It seems somewhat cultic (as usual in the S/W devl world), not properly defining preconditions for itself, such as intense contacts with end users, small or intermediate code bases, very stable development environment, high availability of target computers, not any advanced multitasking environment nor an embedded real time system for telecommunications, or such... ... said: Rursus (bork²) 14:39, 1 July 2009 (UTC)

External Links

Some of the links removed as spam weren't IMHO. For example the collection of book reviews here: http://www.techbookreport.com/SoftwareIndex.html seems to me a useful addition to this article. Books have played an important part in propagating Agile ideas, and there are more books published on the subject everyday. The link provided a set of reviews of many of these - making it a useful resource. Similarly the list of key Agile techniques from the same site was also useful - there are lots of readers who aren't interested in the philosphical underpinnings of Agile, what they want is a succinct list of practises (such as this: http://www.techbookreport.com/tutorials/agile-30-secs.html). Looking back through the history of this article the link to the book reviews seems to have been here for a long time - so why only the recent removal? —Preceding unsigned comment added by 217.205.90.120 (talk) 17:24, 3 December 2007 (UTC)

TechBookReport fails WP:EL and WP:PG on a number of points. For instance, as its About page explains, TBR accepts reviews from publishers, hardly a neutral party. Cheers. -- Iterator12n ^Talk 18:51, 3 December 2007 (UTC)

You're being very unfair - on the about page it's stated that publishers can suggest books for review. That's not the same as accepting reviews from publishers. The whole point of the site is that the book reviews are independent. —Preceding unsigned comment added by 86.30.116.196 (talk) 22:37, 3 December 2007 (UTC)

Here's a quote from that about page: If you would like to propose a book for review please send an email and, if the title is considered suitable, arrangements will be made to route the book to an appropriate reviewer. That's not the same as accepting reviews from publishers. —Preceding unsigned comment added by 217.205.90.120 (talk) 10:39, 4 December 2007 (UTC)

Why only recently? Uhhh, did I somewhere miss a Wikipedia statute of limitations? 70.126.40.85 19:42, 3 December 2007 (UTC)

---

I have pruned the section as it seemed to be getting out of hand. I skimmed through the links, and nearly all of them went to articles with anecdotes, or howtos and advice, so I decided to err on the side of removal. Some are not primarily about the Agile methodology at all.

Martin Fowler's article seems to be a comprehensive one focusing only on Agile development as a whole subject, so I left it in. Additionally he was an early member of the movement, having signed the Agile Manifesto ~ Jafet _{Speaker of many words} 11:27, 22 August 2008 (UTC)

---

By the way, the "Further reading" list is also getting quite out of hand. I don't have the motivation to check those, though. ~ Jafet _{Speaker of many words} 11:52, 14 September 2008 (UTC)

PPTS?

The article mentions, along with Gatherspace, Mingle, and other tools, a tool called PPTS. There is no link to the tool, nor is a WP article defined for the tool. Since PPTS is also the plural of PPT, the standard extension for Powerpoint, it is well-nigh impossible to search for this tool via the web. Whoever added this bit of text should provide some explanation, or a link, or a something besides an acronym. Chris van Hasselt (talk) 20:02, 2 September 2008 (UTC)

Bot report : Found duplicate references !

In the last revision I edited, I found duplicate named references, i.e. references sharing the same name, but not having the same content. Please check them, as I am not able to fix them automatically :)

• "Abrahamsson2003" :
  • Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. ''Proceedings of ICSE'03'', 244-254
  • Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. ''Proceedings of ICSE'03'', 244-254.

DumZiBoT (talk) 14:56, 9 August 2008 (UTC)

Harmonized. ~ Jafet • business • pleasure • voicemail 09:45, 15 September 2008 (UTC)

Perfect reflection of poor thinking

This article is a perfect reflection of the poor thinking that's going on about, and by, the agile movement. -- Iterator12n ^Talk 17:17, 14 September 2008 (UTC)

Yes, I can easily imagine that. But that is state of the art in software development "theory" if such a thing can be imagined... ... said: Rursus (bork²) 14:49, 1 July 2009 (UTC)

Expert attention?

Hi! I see that somebody has marked this article as requiring expert attention. Did somebody have something particular in mind? I probably qualify, and am glad to help. Thanks, William Pietri (talk) 08:58, 8 February 2009 (UTC)

Ok. A month later nobody has mentioned anything, so I'm removing the tag. -- William Pietri (talk) 05:48, 13 March 2009 (UTC)

Nobody criticised your removal, so it was correctly done, then. ... said: Rursus (bork²) 14:55, 1 July 2009 (UTC)

First line

"Agile software development is a group of software development methodologies that are based on similar principles." This statement does not convey any imformation. Can this be improved? --UB (talk) 09:32, 14 April 2009 (UTC)

Well, I think the information it conveys is that it is not a methodology on its own, but rather a family of them, and that the relationship between the family is not one of, say, linear descent, but rather one of similar principles. Could you say more about your concern, and what sort of change you'd propose? Thanks, William Pietri (talk) 16:19, 14 April 2009 (UTC)

How about "Agile software development refers a group of software development methodologies that are based on principles of iterative development where requirement evolves through collaboration between self-organizing cross-functional team." --UB (talk) 07:28, 15 April 2009 (UTC)

I have made the change. --UB (talk) 03:34, 16 April 2009 (UTC)

Just a little note: what is this "self-organizing" stuff? It certainly is not Self-organization which seems to be some kind of mass organization system exhibiting emergent properties, possibly related to chaos and nonlinearity ― but that cannot apply since the groups in the Agile self-organizing is about 10 members. Does it signify "autonomous non-formal collaboration" or some such? A typical case of Marketese where irrelevant associations are alleged but never delivered. ... said: Rursus (bork²) 15:02, 1 July 2009 (UTC)

Signed comment moved to Talk

≤

In fact, depending on what sort of work you are doing or you will do, there are different attitude. First of all, the product sponsor, product manager, and team leader must know about the type of problem they want to produce or solve, whether they are involving with a product based duty or a project based duty, and if there is a product attitude, whether they have to fight to capture some sections of market or they have their own businesses.

After it, the goal must be created and demonstrated to stakeholders, sponsor, managers, and specifically to developers. By doing this, the global design must be designed by architecture, although it must be altered in the future iterations, and in some brainstorming rooms should be explained for developers. Then, it is the time to produce some small iterations which they try to achieve the goals or sometimes repair their goals and designs. Making some small goals toward the main goals anf spending efforts to achieve them are the core of Agile. We can name the new approach of making and altering a big market vision or project quality in a one side and doing and solving the daily problems and requirements in the another side (for example by Agile stesp) as an Oval programming that will balance you in a better situation after a period of time not just for some small iterations periods. ≥ Aliaghatabar (talk) 00:30, 20 May 2009 (UTC)

I can believe that, but we need an external source to cite. On the other hand, if you feel like some parts of that information is missing in the article, you can add those parts to the article, preferrably but not immediately necessarily citing outside sources. In real Wikipedia life, only challenged statements require citations, so trivial and "obvious" statements don't need that scrutiny. ... said: Rursus (bork²) 15:23, 1 July 2009 (UTC)

Decoding the language

The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it and adding further functionality throughout the life of the project

"Business value" seems to be like "something that works, however buggily", while "smallest workable piece of functionality" have some compacter term in Compsciese, such as "base functionality", "continually improving it" seems to be "develop incrementally" in Compsciese. Might work nicely, if an end user is readily available, and if the system doesn't crash physically into the ground killing 50 persons, if there are serious bugs. ... said: Rursus (bork²) 15:43, 1 July 2009 (UTC)

Another

In section Agile practices:

Note: Although these are often considered methodologies in and of themselves, they are simply practices used in different methodologies.

Now, what language do we speak? Not Compsciese, since none of the "methodologies" mentioned in the previous section has anything to do with software development methods, they're simply project management models and mind-sets. So the language in question must be either Agilian or Managementese. It's likely those languages are pretty unrelated, since the topic of interest is the House of Babel of Programming.

However, according to Compsciese terminology, at the very least Test Driven Development (TDD), Behavior Driven Development (BDD) and Continuous Integration are real software development methods, since they deal with the programmers development of code, trying to ascertain a certain program quality. ... said: Rursus (bork²) 21:00, 1 July 2009 (UTC)

Deeming from reference.com that Agile talk of "methodology" vs. "best practice"/"practice" is a non-standard usage of English. According to that dict entry and the article on methodology, methods and methodology relate as I suspected: a method is a sequence of acts to achieve a certain goal, a methodology is either a coherent collection of methods, or more properly a comparative study of methods (of course disregarding the stupid habit of calling "access procedures" in C++ objects "methods"). Formerly, this kind of Marketese language obfuscation infuriated me no end, but mysteriously, I can now keep my temper. I think that we need to decode this kind Marketese in order to make viable encyclopedic articles. In principle articles written in Marketese should deserve mv Marketese /dev/null, but the content and topics are actually very important, so there's some need to deobfuscate and reinterpret the extraordinarily bad language that generally is provided by marketing sources. ... said: Rursus (bork²) 06:47, 2 July 2009 (UTC)

Top 5 Issues with Agile

This whole section seems to be original research with a specific point of view. Is there any way to salvage something from it?--Boson (talk) 15:34, 12 August 2009 (UTC)

Since no citations have been provided and the section presents a particular point of view as fact, I am moving the section here:

Agile makes some very fundamental assumptions, which has led some companies to go from one rigid process to another. Most success has been when Agile, Waterfall, Cowboy Coding, and many other methodologies are used in the appropriate areas. Some of the most common erroneous assumptions that Agile proponents makes are the following:

• 1. Agile assumes anything developing in a software company is software development; therefore the Agile process of software development should be used. This is a very risky assumption and should be properly investigated before concluding it to be true or false.
• 2. Agile proponents assume that Waterfall, Cowboy Coding, and other iterative methodologies don't learn from best practices, and only Agile has the ability to inspect and adapt.
• 3. Agile assumes any member of the scrum can take on any sticky. This is definitely not the case, especially if you don't have cross trained engineers, or you have engineers and artists in the same scrum.
• 4. Agile assumes no responsibility for load balancing. In some retorts, Agile proponents suggested that writing user stories and breaking up the tasks to be artist and engineer specific would help balance the workload. This is not the case, since the scrum fills up with user story points, not tasks. If the scrum filled up their iteration based on task estimates, then (according to Agile) it falls back into the Waterfall methodology.
• 5. Agile does not recognize the individual. Agile assumes the project is being worked on by below average workers. Agile builds in communication requirements, meetings to double check people's estimates, constant proof of product which is disruptive to fundamental non-user-facing epics, and many more protocols to double check workers. Most capable, above average, and skilled employees will end up having to report in as any problem employees. Agile does not recognize the individual.

--Boson (talk) 20:16, 17 August 2009 (UTC)

--- The above 5 items also directly contradict with the agile principles as stated in the manifesto. It seems more like a complaint about the authors personal experience than factual statements about the methodology. 216.99.202.233 (talk) 23:19, 28 August 2009 (UTC)

The points by Boson are totally valid as weaknesses in Agile. I am still trying to identify the difference between agile's user stories and iterative & waterfall user requirements. There should be a point #6 above. Agile makes no effort to support a project budget. How does the CFO approve a new ERP system if there is no plan from which a budget and time line are derived? Agile sounds like it may work well in very small work effort environments, work under 6 man-months of effort consisting of enhancements within a single tier. Beyond these limits planning and organization are keys to success. Fl990 (talk) 15:11, 5 October 2009 (UTC)

I see the same issue with the criticism section. It basically argues that a agile accepts a possibility of poor planning so just because it enables a bad development does not make it a issue with the model. The model is more of a direction of how to design your development model. Better criticism and less making an issue is needed. Tempust (talk) 22:49, 14 April 2010 (UTC)

Citation needed

This paragraph:

The criticisms regarding insufficient software design and lack of documentation are
addressed by the Agile Modeling method which can easily be tailored into agile processes
such as XP.

needs a citation. Needs to be written in a more encyclopedic way.

• Is it really easy to tailor into the agile process? says who?
• Where are the criticisms addressed? —Preceding unsigned comment added by 216.241.162.100 (talk) 19:17, 7 January 2008 (UTC)

Yes, certainly: citation needed. I added a {{fact}} for you, but feel free to do so yourself whenever you observe a seemingly illfounded statement that looks like too subjective and too poorly cited. ... said: Rursus (bork²) 14:46, 1 July 2009 (UTC)

Conceptual foundations of this framework are found in modern approaches to operations management and analysis,
such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.

Unless citation is provided, this statement should be removed from the open para. --UB (talk) 04:49, 11 May 2010 (UTC)

Separation from Agile Project Management

I was looking for information on agile project management, but noticed that Agile Project Management links to Agile Software Development. I see a couple of problems with this for project managers looking for information on agile/adaptive/iterative project management methods (as opposed to predictive/traditional methods):

1. As far as I can tell, this article is not so much about agile project management, as it is about particular computer programming techniques. The introductory sentence says it all: "Agile software development refers to a group of software development methodologies".

2. There's no reference to Agile under the Project Management category.

Agile project management dates back to at least 1986, and was conceived for iterative new product development, such as for cars and consumer electronics, and was expanded upon to form several general purpose project management techniques. In my mind, and I'm sure in the minds of project managers who use agile outside of software development, this redirection looks very strange. I wonder what people here think about putting in at least a separate stub article for Agile Project Management with a reference here, instead of redirecting? —Preceding unsigned comment added by Takayuki I (talk • contribs) 12:00, 22 May 2010 (UTC)

If what you mean is the agile management of (non-software-development) projects, it would need to be disambiguated from the management of agile software development projects, i.e. the term may refer to two very different topics. The two topics should not be confused. The problem with a stub is that it might be an invitation to spammers trying to promote their own tools or consultancy services. --Boson (talk) 11:12, 3 June 2010 (UTC)

Critical Points To Add

Agile methods promote systems having implemented and tested source code. Costs after delivery are ignored since Agile processes produce no real business process requirements, no technical documentation and no data models. Agile is well suited to short lifespan (<2 years) systems that are not updated or maintained. This is shown in Agile's difficulty in dealing with legacy data and legacy databases as Agile assumes the development team does not need to know and research (i.e., develop business rules, requirements or data models) legacy database systems. —Preceding unsigned comment added by 98.197.208.99 (talk) 21:33, 10 February 2008 (UTC)

--- +1 as a software developer currently tasked with modernizing on a 20 year old system and having agile forced on us this criticism is very true and should be added. —Preceding unsigned comment added by 216.87.87.19 (talk) 23:53, 12 March 2009 (UTC)

--- The above comments are not accurate. Agile suggests that a working system is more important than documentation. HOWEVER it does also say that documentation is still important! What the two authors above have run into is systems designed by bad programmers who used the word agile as an excuse not to do a proper job or write needed documentation.

I will point to the actual manifesto (notice the last sentence states that the items on the right DO have value.):

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Furthermore I will point to Alistair Cockburn's comments in the following article:

http://www.cio.com/article/464169/When_Agile_Projects_Go_Bad

216.99.202.233 (talk) 22:43, 28 August 2009 (UTC)

- The necessary documentations can be and should be provided at the end of each iteration, or at the end of the project. As stated at above, the Agile Methods emphasize that working software is more important than the documentation, but it doesn't mean the documentation is not needed at all. —Preceding unsigned comment added by 218.82.69.105 (talk) 04:58, 10 June 2010 (UTC)

Agile Development Poster

First of all, I am not an employee of the company (VersionOne) who created the poster in question. My company found and downloaded this poster about a year ago and we have several hanging on walls in common meeting areas. My company does not use any VersionOne software, nor do we have any family members who are employed by VersionOne. This discussion is for those "couple" of you who feel this resource does not belong in this topic. You asked me to defend my position of why it belongs here. Ok.

1. When you review the content of the Agile Development poster, you will find it is a creative, original, unique, unbiased and accurate, visual representation of the exact title of this article. 2. Quotes from developers who have downloaded this resource are extremely positive. 3. My team's personal opinions are all positive. 3. I contacted the marketing department of the company who created the poster and asked them how many teams have downloaded this poster. More than 13,000 Agile developers have downloaded this in the last 12 months. You "say" this resource doesn't belong in this article without doing any research of your own. The numbers simply do not support your position. If this many people think this information is valuable then this article is "EXACTLY" where a link to this type of resource belongs. (where people can find it)

You say it violates the external links guidelines. This is not true. In the "What to link" section there are three bullets. a. Is the content accessible to the reader - YES b. Is the content proper in the context of the article (useful, tasteful, informative, factual) - YES c. Is the link functional and likely to remain functional - YES - Each link should be considered on its merits.

In the What should be linked section, #3 states Sites that contain neutral and accurate material that is relevant to and encyclopedic understanding of the subject and cannot be integrated into the Wikipedia article due to copyright issues, amount of detail, or other reasons.

What should not be linked. None of these apply.

So, I have added the link back in. If you still feel that it does not belong, please provide your reasons in this discussion area. Dbenson 14:51, 28 June 2010 (UTC) —Preceding unsigned comment added by Dbenson (talk • contribs)

I feel it should not be linked due to WP:ELNO points 1,5, and 6. - MrOllie (talk) 15:47, 28 June 2010 (UTC)

No effort made to address legitimate criticisms

"Much criticism of Agile Methodology is attributable to misappropriation of the methodology itself." If you don't agree, you are automatically ignorant? What about the increase of management overhead? Teams being distracted by constant meetings? A focus on quick flashy results instead of scalable and flexible solutions? — Preceding unsigned comment added by 24.62.202.27 (talk) 2010-08-11

Since all the statements in the section have been flagged as unsourced for over a month, I have removed the entire section. Any criticisms should be based on reliable sources. It should also be stated who is making the statements. Many editors feel that criticisms should be dealt with in the sections relevant to the particular criticisms and should not be put in a separate section. --Boson (talk) 17:49, 11 August 2010 (UTC)

I agree with the anonymous user above. I used this article a bit more than a year ago as starting point for a presentation regarding Agile Methodologies. At that point in time, I found it to be fair representation of Agile's strength and weaknesses. Now it reads like a fan page along the lines "OK, there are some problems and it is great". Interestingly, I am actually working with the "Indian outsourcing company" that supports BT (mainly based in Chennai/India). Nobody has ever mentioned that "agile methodology" are being used in BT's outsourcing processes. In fact, the company in question is CMM Level 5 certified, operates its own SDLC methology and has a well-though out testing methodology based on ISEB/ISTQB teachings. So, at least the claim that "BT is doing successful agile outsourcing" sounds very much like an urban legend to me. HagenUK (talk) 14:17, 17 August 2010 (UTC)

Could you be a bit more specific about which sections you find problematic and provide sources for criticisms that you think should be added? Could you also say where the "Indian outsourcing company" is mentioned?--Boson (talk) 18:37, 17 August 2010 (UTC)

Quote from the Suitability section:
"Several successful large-scale agile projects have been documented.[where?] BT has had several hundred developers situated in the UK, Ireland and India working collaboratively on projects and using Agile methods.[citation needed]"

I emailed our account manager of the Indian outsourcing company. He confirmed that they are not doing anything agile, neither with BT nor anybody else. However, he forwarded the email to their methodology people in Chennai and they can have a look and update this article. The BT claim is factually wrong, but I leave it to the company involved to set the record straight. HagenUK (talk) 08:54, 18 August 2010 (UTC)

Since those two sentences have been flagged for some time, I think we can delete them. I have seen claims, apparently from BT, that they were doing agile projects, but not enough for me to replace those statements with ones that I think are are correct and adequately sourced. --Boson (talk) 22:26, 18 August 2010 (UTC)

Lead and Criticism

I am cleaning up the lead paragraph, seeing as the paragraphs on the proponents/detractors of the agile method significantly detract from actually informing the reader about agile software development and do not have citations. I would suggest that anyone who wishes to address the differing viewpoints regarding agile software development do so in a separate section as to avoid cluttering the lead.

Furthermore, please avoid using quotations around words that are not actually quotations. This is not, as far as I know, grammatically correct or proper for an encyclopedia quality resource. Robert Seaton (talk) 18:29, 9 September 2010 (UTC)

Release early, release often

Looks like there should be some links between both articles. Calimo (talk) 15:32, 18 September 2010 (UTC)

Agile home ground

Boehm and Turners's views on this were removed. I have reverted this removal. Such a major removal of sourced material (citing recognized authorities) should - at least - be discussed here first. Given the authors' standing, their characterization is noteworthy and it is described as an opinion. It is not given undue weight and balances the somewhat "evangelical" views that are common. There may be an argument for presenting it as normal prose rather than a bulleted list. --Boson (talk) 06:10, 21 September 2010 (UTC)

I wasn't the one who removed the section, but I would say that Boehm and Turner represent but one opinion on the suitability of agile methods. Devoting an entire section of the article to that opinion seems biased, especially when it's from authors who as far as I can tell have never actually participated on project using an agile method. While Mr. Boehm may have codified an early iterative approach with the Sprial Method, his work has not directly influenced approaches such as Scrum, XP and Kanban. If I wrote several books about Java, would that qualify me to opine on real-time C++ development? --daverooneyca (talk) —Preceding undated comment added 11:16, 21 September 2010 (UTC).

Spoken Wikipedia Audio Recording

I've uploaded an audio recording of the article for the Spoken Wikipedia project. Please let me know if I've made any mistakes. Thanks. --Mangst (talk) 22:22, 8 December 2010 (UTC)

New image

I have created a new version of the poster with File:Agile Software Development methodology.jpg. I think the original version with the advertisment for VersionOne is really unaccaptable. There is a clear policy not to accept these things on Wikipedia. -- Mdd (talk) 15:15, 27 January 2011 (UTC)

References

I think that references 27 and 31 (as of 29 Jan 2011), "Supersize Me" in Dr. Dobb's Journal refer to the same article in different media. Each is used in a different place in the text.

• Could/should these references be merged?
• Is it useful to be able to access the article in different formats. What is the Wikipedia policy/best practice on this?
  

(I don't have access to the print version of the journal.)
Peter Riches (talk) 03:00, 29 January 2011 (UTC)

Thanks for noticing. I merged both references. -- Mdd (talk) 13:36, 29 January 2011 (UTC)

Thanks for listening! Peter Riches (talk) 07:27, 30 January 2011 (UTC)

Diagram is confusing and fails to convey information

The diagram on this page is quite confusing and doesn't really convey information well. It seems like something from a corporate presentation intended for people who are already experienced in the subject. It provides no useful information to a newcomer. Skrelk (talk) 23:28, 9 May 2011 (UTC)

NPOV issue in Experience and reception section

The article states that 55% of a VersionOne survey said that Agile was successful in 90-100% of cases. However, VersionOne sells agile tools and so they have a financial stake in the survey results. What would be nice is if we could cite a independent, third-party source which doesn't have a conflict of interest in the survey results. A Quest For Knowledge (talk) 16:07, 5 August 2011 (UTC)

Agree. Do you have one? --Boson (talk) 21:12, 5 August 2011 (UTC)

To clarify: I agree that it would be better to include the findings of people without a conflict of interest. I do not agree that this is an NPOV issue (as implied by the current heading). That would apply if their findings were presented as fact. In sections such as 'reception' and 'criticism', we are supposed to report on attributable points of view; and noteworthy points of view are naturally held by people with an axe to grind. To avoid giving undue weight to views held by proponents of agile software development, we could, perhaps, do with some more opposing views.--Boson (talk) 21:43, 5 August 2011 (UTC)

I have attempted to make this section more NPOV.--Boson (talk) 18:06, 31 August 2011 (UTC)

Experience reports

I propose removing the entire section on experience reports. This is mainly a list of links, many of them dead, and the fact that there are experience reports etc. at annual conferences is not noteworthy and is not reported for other topics. In short, the section now adds nothing to the article. --Boson (talk) 23:18, 5 August 2011 (UTC)

 Done --Boson (talk) 14:48, 31 August 2011 (UTC)

When Agile Development is the wrong approach

This article seems more like a sales presentation. It should also discuss when Agile Development approaches are not appropriate.

It says, for example, that you should use small teams physically located in the same bull-pen. How does that work in organizations where developers are spread across a dozen time zones? Is Agile Development viable for products that require larger development teams or common architectural elements.

The politics of development is a huge hurdle to success. For example, how does Agile Development deal with the not-invented-here syndrome that limits re-use of components from other products / projects? Or centralized review boards that limit innovation in favor of their preferred products?

Agile Development, like almost all methodologies, attempts to deal with the lack of discipline inherent in developers. In essence, Agile Development attempts to deal with this by surfacing the "failures" as early as possible so that they can be remedied.

"Discipline is a harsh mistress."

137.254.4.4 (talk) 14:02, 19 September 2011 (UTC)Stardog

Needs balance, and classed with higher importance

I agree that this article reads like a sales pitch for agile. It treats the "waterfall method" as a straw man (as usual - some argue that the "waterfall" concept is nothing but a straw man.) It should contain a section detailing problems people have experienced with agile methods, and situations in which they are not appropriate. By contrast the Wikipedia article on Waterfall Method is mostly critique, and uses straw-man rhetoric even more blatantly.

There has been a lot of buzz about "Agile methodologies" for years, and the term is used to describe all sorts of development processes that often have little in common. I am surprised that the article, weak as it is and rated C, is not given a higher mark for "importance."

---

Jim — Preceding unsigned comment added by Cockeyed (talk • contribs) 01:29, 2 November 2011 (UTC)

Agile Manifesto copyright

In the current version of the article, the text of the Agile Manifesto is reproduced, allegedly in its entirety but in apparent contravention of the explicit copyright notice, which permits copying of the entire manifesto only if the copyright notice and the list of authors are included. Instead, the text should be broadly paraphrased and a link provided to the full text with the copyright notice. If the authors of the manifesto are happy to have the full text reproduced here under a Wikipedia-compatible licence, then they can change their copyright notice accordingly. --Boson (talk) 20:43, 18 November 2011 (UTC)

Quality of "Criticism" section

Disclaimer: I am a proponent of Agile software development.

I feel the "Criticism" section of this page lacks quality in its writing. It feels it was simply written by someone who is against Agile. The page needs a section criticising Agile, but written better than the one currently available. (I don't feel I'm knowledgeable enough to write the section myself.) Remi (talk) 07:34, 28 November 2011 (UTC)

Language, writing style

Language and writing style of the article is sloppy and somewhat jargony. I object to formulations such as

Agile is a group of agileologies based

This is in semantics probably a circular definition, because: how then are "agileologies" [jargon] defined? Probably as a set of methodologies within "agile", which teaches us nothing plus vacuum... I don't know now how to fix it, but Agile is a framework of development philosophies and methodologies based on some kind of "best practice" evolved from programmers' experience ("best" only in the sense that we know of no better, so far). Rursus dixit. (^mbork³!) 09:26, 1 February 2012 (UTC)

Also "best", presuming a certain problem solving context – this presumptuous boasting speaking style is typical for computer industry, which undermines the authority of the speakers. Rursus dixit. (^mbork³!) 09:29, 1 February 2012 (UTC)

These were certainly a vandalism. I'll revert that to a previous, clean version and then will try to readd your changes. Most of them are not needed, because, e.g. Agile was introduced by the vandal. 1exec1 (talk) 14:01, 1 February 2012 (UTC)

Agile vs. agile

The term agile, the methodology set, is small letter in the Agile Manifesto. It should obey the English casing rules, that dictate that the 'A' is uppercase when the term is the first word of a sentence. Starting a sentence with small letter is invalid, it is a typo. The Agile Manifesto on the other hand is always uppercase in the manifesto itself. Since that is allowed in English, we can adher to upper casing of Agile Manifesto. Rursus dixit. (^mbork³!) 13:25, 1 February 2012 (UTC)

Agile was introduced by a vandal. I've reverted his edits to a previous version, which does not capitalize Agile at all. 1exec1 (talk) 14:07, 1 February 2012 (UTC)

I didn't realize but now I see. Thank you! Rursus dixit. (^mbork³!) 14:34, 1 February 2012 (UTC)

XP != Agile

This page is a great description of Agile programming. XP and Agile are two similar, but distinct approaches to software development. They both exist in the real world and they both should be reflected in the Wikipedia.

Well I think that this is not whole truth. XP is just one of the agile methodologies. Agile software development can be an wikipedia category as well.

—Preceding unsigned comment added by 68.184.122.79 (talk) 20 March 2005

XP is not an agile method, XP is regognized as one method of development, SCRUM is not a development method, its a project method you can use on almost anything, it is true that its mostly used in software development (probably for constant changing enviroment more than other?) The above is very common misconcetition of agile process. — Preceding unsigned comment added by 83.250.45.133 (talk) 19:28, 14 February 2012 (UTC)