Talk:Lean software development/Archives/2012

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)

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)

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)

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)

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)

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)