Your SlideShare is downloading. ×
0
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Lean Software Development
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lean Software Development

563

Published on

Lean Software Development - Best Practices

Lean Software Development - Best Practices

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
563
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Lean Software Development From Concept to Cash Artemis Mendrinos Project Manager EWORX S.A.
  • 2. The Cost of Complexity 07/06/09 EWORX Profile
  • 3. Kano Model 07/06/09 EWORX Profile
  • 4. Minimum Useful Feature Sets <ul><li>Deploying small, useful feature sets in a custom development project allows customers to start using the software much faster. </li></ul><ul><li>When these feature sets start generating a return on investment earlier, the company can invest less money, payback the investmen sooner, and, usually, generate more profit over the life of the system. </li></ul><ul><li>From a customer’s viewpoint, receiving minimum useful feature sets means getting their job done sooner and finding out how they really would like the software to work. </li></ul>07/06/09 EWORX
  • 5. 07/06/09 EWORX Profile Release Profits Time Cost 0 Breakeven
  • 6. 07/06/09 EWORX Profile Release1 Profits Time Cost 0 Release2
  • 7. 07/06/09 EWORX Profile Release1 Profits Time Cost 0 Release2
  • 8. From Projects to Products 07/06/09 EWORX Profile
  • 9. From Projects to Products 07/06/09 EWORX Profile
  • 10. The Seven Wastes 07/06/09 EWORX Profile Manufacturing Software Development In-Process Inventory Partially Done Work Over-Production Extra Features Extra Processing Relearning Transportation Handoffs Motion Task Switching Waiting Delays Defects Defects
  • 11. What is waste? <ul><li>Waste is anything that </li></ul><ul><li>does not deliver customer value! </li></ul>07/06/09 EWORX Profile
  • 12. Partially Done Work <ul><li>Examples: </li></ul><ul><li>Uncoded Documentation </li></ul><ul><li>Unsynchronized Code </li></ul><ul><li>Untested Code </li></ul><ul><li>Undocumented Code </li></ul><ul><li>Undeployed Code </li></ul>07/06/09 EWORX Profile
  • 13. Extra Features <ul><li>Taichi Ohno emphasized that overproduction – making inventory that is not needed immediately- is the worst of seven wastes of manufacturing. </li></ul><ul><li>If there isn’t a clear and present economic need for the feature, it should not be developed . </li></ul>07/06/09 EWORX Profile
  • 14. Task Switching 07/06/09 EWORX Profile
  • 15. Handoffs <ul><li>When work is handed off to colleagues, a vast amount of tacit knowledge is left behind in the mind of the originator. </li></ul>07/06/09 EWORX Profile
  • 16. Delays <ul><li>Waiting for people to be available who are working in other areas is a large cause of the waste of delay. </li></ul><ul><li>Developers make critical decisions about every 15 minutes. It’s naive to think that all the information necessary to make these decisions is going to be found in a written document. </li></ul>07/06/09 EWORX Profile
  • 17. Delays <ul><li>A decision can be made quickly if the developer has a good understanding of what the code is supposed to accomplish, and if there is someone in the room who can answer any remaining questions. </li></ul>07/06/09 EWORX Profile
  • 18. Delays <ul><li>Complete, collocated teams and short iterations with regular feedback can dramatically decrease delays while increasing the quality of decisions. </li></ul><ul><li>It is important to make sure that knowledge is available exactly when and where it is needed – not too soon, or it will have to be changed, and not too late, or it will have to be ignored. </li></ul>07/06/09 EWORX Profile
  • 19. Defects <ul><li>A good agile team has an extremely low defect rate. </li></ul><ul><li>Finding defects as early as possible and looking ways to keep that kind of defect from reoccurring. </li></ul>07/06/09 EWORX Profile
  • 20. Mapping the Value Stream <ul><li>We have to look at the timeline from the moment a customer gives us an order to the point when we collect the cash. </li></ul><ul><li>We have to reduce that timeline by removing the nonvalue-added wastes. </li></ul>07/06/09 EWORX Profile
  • 21. Speed – Deliver Fast <ul><li>Speed is the absence of waste </li></ul><ul><li>Speed does not mean bad quality in code (see google – develops fast great software) </li></ul>07/06/09 EWORX Profile
  • 22. Minimize the size of Things in Process <ul><li>The amount of unfinished work in an organization is a function of either the length of its releases cycle or the size of its work packages. </li></ul><ul><li>The natural tendency is to stretch out product releases or project durations. </li></ul><ul><li>Stretching out the delivery times is moving in exactly the wrong direction from a lean perspective. </li></ul>07/06/09 EWORX Profile
  • 23. Limit Work to Capacity <ul><li>Far too often we hear that the marketing department or the business unit, “Has to have it all by such-and-such a date,” without regard for the development organization’s capacity to deliver. </li></ul><ul><li>We know what happens to computer systems when we exceed their capacity – it’s called thrashing. </li></ul>07/06/09 EWORX Profile
  • 24. Q &amp; A 07/06/09 EWORX Profile

×