• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

concept of "Lean Software Development"?

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wnat to know about the concept of Implementing Lean Software Developmen.

[Edit to provide meaningful subject]
[ November 07, 2006: Message edited by: David O'Meara ]
 
Ranch Hand
Posts: 904
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Naresh,

welcome to the Ranch.

Lead Software Development borrows it's ideas from lean manufactoring, e.g.
you try to eliminate "wast" and thereby improving the quality and reducing
the costs and production time.

I've (shamefully) copied these 10 rules of lean programming from
www.Poppendieck.com, which is the authors of "Impl. Lean Software Development"'s
website.

http://www.poppendieck.com/publications.htm

The Ten Simple Rules of Lean Programming
1. Eliminate Waste
2. Minimize Paperwork
3. Implement in Small Increments
4. Decide as Late as Possible
5. Decide as Low as Possible
6. Satisfy All Stakeholders
7. Focus on Testing
8. Measure Business Results
9. Optimize Across Organizations
10. Never Stop Improving



/Svend Rost
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lean and Theory of Constraints discussions both came from manufacturing, right? I think they're compatible if not overlapping. I read The Goal and listened to Beyond the Goal (audio). I'd like to dig into Tom & Mary's work next. How much will I find in common there?
 
author
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Naresh,

The first chapter of our book does a good job of answering your question, and it is available on-line at:

Sample Chapter: Implementing Lean Software Development: From Concept to Cash: http://www.awprofessional.com/articles/article.asp?p=664147&rl=1

Mary Poppendieck
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Svend!
Can you please elaborate more on the following two points mentioned by you:

4. Decide as Late as Possible
5. Decide as Low as Possible

Thanks :-)
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


4. Decide as Late as Possible



I remember the phrase to decide "at the last responsible moment". The reasoning is that the later you make a decision, the more information you have to come to the right decision.

But there is actually more behind this than just waiting until later to make a decision - there are some things you can actively do to allow you to defer decisions. Basically, everytime you need to make a decision, you try to think of ways to keep your options as open as possible (for example by applying "set based decision making").

This is actually not only coming from manufacturing, it is also an important principle of decision making in the military, for example.


5. Decide as Low as Possible



I'd guess that means not making decisions for the people below you in the hierarchy, but communicating goals and enabling the people who will have to live the decisions to also make them.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
I'd guess that means not making decisions for the people below you in the hierarchy, but communicating goals and enabling the people who will have to live the decisions to also make them.



Exactly. All too often there are processes in place that require higher-level approvals before work can proceed, even though the expertise for making these decisions resides at a lower level. So the aim is to remove delays which leads to "waiting" waste. If you implicitly trust the people with the expertise there is no need for higher level approval - if you don't trust the people with the expertise then you have much bigger problems.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I like the influence of "decide as late as possible" on design. For instance, if you start a new system with the knowledge that it will use an Oracle database you might wind up handling result sets, interpreting vendor specific exceptions or writing sepcific SQL in inappropriate places. If you defer the decision whether to use a database or JMS or a web service to external persistance you pretty well have to write generic get & put interfaces.

You can read "decide as low ..." as closely related. Commit to the decision far down in the architecture, close to the implementation. Keep higher layers out of the decision. I really like reading it as low in the organization, too. In my culture that is kind of subversive. Heh heh.
 
Mary Poppendieck
author
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

All too often there are processes in place that require higher-level approvals before work can proceed, even though the expertise for making these decisions resides at a lower level. So the aim is to remove delays which leads to "waiting" waste. If you implicitly trust the people with the expertise there is no need for higher level approval - if you don't trust the people with the expertise then you have much bigger problems.



This is exactly what we mean by "Decide as Low as Possible". It is the people doing the job that know it best. There are no better people to make decisions about how that work should be done. Attempts by management or 'process police' to decide for front line workers how they should do their job will invariably give mediocre results, while robbing the people who do the work of their right to be fully engaged in doing a superb job.

Mary Poppendieck
 
Ranch Hand
Posts: 128
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree, but it is not always easy. We give software to the troops (engineers) and they tend to modify it for the specific needs. Now when a system change comes along, there is a problem. Instead of fixing one code, we have many versions to change. Some more difficult that others.

I'm suggesting that CVS be used to fix this problem. However, the troops don't currently use CVs , so there is a learning curve to climb.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sonny Pondrom:
I agree, but it is not always easy. We give software to the troops (engineers) and they tend to modify it for the specific needs. Now when a system change comes along, there is a problem. Instead of fixing one code, we have many versions to change. Some more difficult that others.

I'm suggesting that CVS be used to fix this problem. However, the troops don't currently use CVs , so there is a learning curve to climb.



With all due respect, to "decide as low as possible", I'd think "suggesting that CVS be used" is exactly *not* the thing to do.

Instead, you should gather with those engineers, explain the *problem* (propagating code changes to be too expensive, if I understand correctly) and ask *them* to come up with a solution.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic