Talk:Lean software development

	This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.
	This article is supported by WikiProject Computing.

Origin

The beginning of the page (origins) is clearly wrong, since the Poppendiecks published a paper in Dr. Dobb's with the "lean" title in 2001, two years before their book, but also because there is a 1995 article by Niklaus Wirth (IEEE Computer, February) entitled "Plea for Lean Software". Of course it is not a full-fledged development method but it has many elements in common with that method, and one cannot say that the term originated with the 2003 book. B-Meyer (talk) 14:13, 6 October 2013 (UTC)[reply]

I did a SQA course in 1993 which talked about applying lean principles to software development. 07:53, 31 March 2014 (UTC) — Preceding unsigned comment added by 203.41.222.1 (talk)

Untitled

Hi —Preceding unsigned comment added by 117.241.83.135 (talk) 12:00, 15 July 2010 (UTC)[reply]

Apart from the fact that it contains some great ideas i cannot really see any strong link between these ideas and Lean apart from its choice as part of a catchy title. Waste reduction relates to so many methodologies that this specific choice is perhaps arbitrary. Can the inclusion in the Lean concepts category be defended by anyone ? Facius 11:46, 10 October 2007 (UTC)[reply]

To reply to some of the comments above...Lean software development is a recognized, but very new area (<4 years). It is not at all obvious how to apply Lean principles to software development, or why we should. The Poppendiecks wrote the book(s) on the subject, so it is somewhat understandable that much of the content be biased towards them. DukeyToo (talk) 17:04, 31 December 2007 (UTC)[reply]

I agree that the article needs a lot of improvement. While it was helpful to me in getting up to speed on Lean principles, it does not read like an encyclopedia entry. As a first step, I've cleaned up the language in a few sections and added some internal links to other articles. Qwirty (talk) 18:54, 6 February 2008 (UTC)[reply]

I can see how this article needs improvement, but as to the "Lean Concepts" category, that's a discussion for a different page (the category page). If the category itself has merit, then this page should (in some modified form) be included. As the above suggests, Tom and Mary's book is probably going to take centre stage, since it's the (currently) definitive translation of the concepts from Toyota into software. However there are other sources which can be cited, and I'll try to work on it. --Christian Edward Gruber (talk) 17:22, 31 March 2008 (UTC)[reply]

Connection to Lean manufacturing.

Facius asked about the connection to lean, claiming that eliminating waste is the primary and only meaningful link. This is both true and not. It is true in the sense that eliminating waste is probably the most powerful technique/principle in any Toyota inspired method, but it is not the only connection. In fact the connections to Toyota Production System are much more substantial. Such things include "using pull systems to avoid unnecessary work" (Kanban), "stop the line culture", "level out the workload", "standardized tasks" (impossible in a creative effort, so more appropriate to Toyota Product Development System, for which there is currently no wikipedia article), "queueing theory", as well as "eliminate waste" (muda). It differs from Lean Manufacturing in two ways. First, because of the domain (software), but secondly because software development is a creative exercise, not a manufacturing process. So (and the point is made in the book and elsewhere) Lean Software Development is more the child of Lean Product Development, which is not a well used term, but it all derives from The Toyota Way, and their adaptation of such principles to new product development.

The connections to Agile are somewhat coincidental, but while some argue that they are quite different, Lean principles seem to provide a decent theoretical underpinning to agile methods, and many agile practices are (co-incidentally or not) decent implementation of Lean tools. --Christian Edward Gruber (talk) 18:46, 31 March 2008 (UTC)[reply]

An interesting viewpoint but I am still not clear on what the linkage is to Lean Concepts. I do accept that (despite having created it) the Lean Concepts category definition is fuzzy. It contains 'pure' concepts like Mura,Muri,Muda but also 'tools' found directly useful in implementations, mainly in manufacturing. This reflects the confusion of the 'principle' Vs. 'tools' approach out there in the real world. I do not see this article as a 'pure' concept but i also don't see well defined tools.

You seem to be saying that "Pull", "Kanban", etc are part of this technique but the article itself doesnt specify any new 'tools'. So even if you believe the linkage to Lean is strong, this does not make it a concept of Lean but an application of its concepts/tools to a specific area of work. Hence I had removed it from Lean concepts because it is someone's concept of how Lean tools/principles might be applied but not a concept of Lean itself. If you want to start a Lean implementations category please go ahead. This is why it is categorised in the Lean manufacturing page as an area of implementation. If it is a child of Lean Prouct Development then maybe someone could write a page on that. Facius (talk) 10:20, 7 April 2008 (UTC)[reply]

Lean is currently being evangelised in IT circles as a buzzword and euphemism for cost cutting. Peddlers of this snake-oil are hoping to cash in on the will to cut costs as a result of the downturn. The medicine they prescribe has no clear recipe, no empirical evidence of success, but is neatly packaged and easily swallowed in the current climate. In order to counter this kind of potentially destructive effect, this article should be taken with some seriousness and made extremely clear. I side with Facius - Lean has no place in a creative process. It is counterproductive to perceive the process of introducing change to business operations, automated or not, as something that is mechanised and optimisable. Some of the real problems with IT costs are down to the relationship between IT and business, where IT is incorrectly perceived as being a set of support processes, rather than the owners and executers of primary processes. It is the lack of creativity and the cultural divide, the lack of emphasis and investment in quality, that counterintuitively leads to bloated costs and suboptimal designs. Because Lean comes from manufacturing, it encourages a mechanised, support process view of IT. More useful would be to look at Deming's original thoughts and evolve a SW dev philosophy from scratch. — Preceding unsigned comment added by 193.245.34.59 (talk) 09:32, 1 September 2011 (UTC)[reply]

The article, and based on that, lean SD, contains basic and simple contradictions. For instance the Waste section talks about not throwing away code, the next section embraces it "...different ideas could be tried by writing code and building..." Perhaps a clearer indication that this is an emerging field rather than an established practice would improve the article. As it is today, it is far too low a quality to remain and should be removed. — Preceding unsigned comment added by 210.48.109.206 (talk) 04:02, 6 August 2012 (UTC)[reply]

Empower the team

This section needs some improvements in style as well as some citations.. I'll get to it in a few days if nobody gets to it sooner.. 2aprilboy (talk) 22:24, 17 January 2010 (UTC)[reply]

Other stuff

"Without speed, decisions cannot be delayed." That cannot be correct. It must be the opposite, right? /First time editor of Wikipedia. — Preceding unsigned comment added by 62.20.61.170 (talk) 14:10, 18 December 2012 (UTC)[reply]

Eliminate Waste - low quality must not always be waste

"Defects and lower quality are waste". I wouldn't accept this sentence. If a low quality product is sold it generates value and everything that is value cannot be waste at the same time. Though I agree that lower quality should be avoided, since it either increases costs of maintainance or leads to product failure. But I think Poppendieck also mentioned the pareto rule in some of her books. So it can be quite the opposite: "too high quality is waste"

I have touched this in m german blog: http://kleffels-software-blog.de/?p=1300 — Preceding unsigned comment added by 109.84.151.233 (talk) 17:05, 1 February 2014 (UTC)[reply]