Lean Software Delivery
Upcoming SlideShare
Loading in...5
×
 

Lean Software Delivery

on

  • 3,170 views

 

Statistics

Views

Total Views
3,170
Views on SlideShare
2,193
Embed Views
977

Actions

Likes
3
Downloads
112
Comments
0

7 Embeds 977

http://blogs.urbancode.com 775
http://architects.dzone.com 176
http://www.scoop.it 11
https://twitter.com 10
http://blog.urbancode.com 3
http://www.linkedin.com 1
http://cvs2.urbancode.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Lean Software Delivery Lean Software Delivery Presentation Transcript

  • Lean Software Delivery Get lean and mean without being stretched too thing
  • UrbanCode Inc. ©2013 Lead Consultant & Tech Evangelist Eric is Lead Consultant at Urbancode where I help customers get the most out of their build, deploy and release processes. Today he works with customers and industry leaders to figure out this DevOps thing. Eric Minick eminick@us.ibm.com @EricMinick
  • UrbanCode Inc. ©2013 Why Lean?  Need to do more - Agile: Faster pace of builds & releases - More complex architectures - Distributed, even global teams  Adding more people unlikely  Only solution is to increase efficiency
  • UrbanCode Inc. ©2013 Lean Software  By analogy, inspiration and even direct mapping from Lean Manufacturing  More focused on principles than practices - 7 Lean Principles - Complements and underpins Agile and DevOps  Provides a low-risk approach to increasing efficiency
  • UrbanCode Inc. ©2013 Lean increases efficiency by removing waste 7 Wastes: of Manufacturing Inventory Extra Processing Overproduction Transportation Waiting Motion Defects 7 Wastes: of Software Partially Done Work Extra Processes Extra Features Task Switching Waiting Motion Defects
  • UrbanCode Inc. ©2013 Wastes: 1 Partially Done Work  Waste: Work you get no value from  Risk: Untestable. - Can’t verify you’re on the right track Commons.wikimedia.org
  • UrbanCode Inc. ©2013 Wastes: 2 Extra Process  Wastes: Paperwork that nobody really reads is “theater” at best, a complete waste at worst.  What happens if we skip or delay this process? Is any value to the customer lost? Image: http://upload.wikimedia.org/wikipedia/commons/d/d9/Paperwork_- _by_Tom_Ventura.jpg
  • UrbanCode Inc. ©2013 Wastes: 3 Extra Features  Waste: All planning, development and testing time was useless. No value was delivered.  Worse: Extra complexity was introduced Image: http://commons.wikimedia.org/wiki/File:IPhone_3G.png
  • UrbanCode Inc. ©2013 Wastes: 4 Task Switching  Waste: “Reloading” the information for various concurrent process is expensive when switching between them. ? Another useless meeting… now where was I on this?
  • UrbanCode Inc. ©2013 Wastes: 5 Waiting  Waste: When the project is not moving forward, value is not being delivered. Waiting tends to generate more task switching as well. ♫
  • UrbanCode Inc. ©2013 Wastes: 6 Motion  Each hand-off represents a risk due to incomplete knowledge.  Can my developer quickly understand a feature, or does she need to ask someone; who asks someone; who asks someone?
  • UrbanCode Inc. ©2013 Wastes: 7 Defects  Severity of Defect * Time undetected
  • UrbanCode Inc. ©2013 In Short Build the right thing Deliver it promptly
  • UrbanCode Inc. ©2013 In Short Build the right thing Deliver it promptly Execute Efficiently
  • UrbanCode Inc. ©2013 In Short Build the right thing Deliver it promptly Execute Efficiently Agile focuses here DevOps focuses here
  • UrbanCode Inc. ©2013 In Short Build the right thing Deliver it promptly Execute Efficiently Agile focuses here DevOps focuses here DevOps also helps with feedback
  • UrbanCode Inc. ©2013 Build the right thing: Strategy by situation  When requirements are well understood - Document them well  When big picture is understood but details are shaky - Tight customer collaboration - Rapidly deliver to QA and user acceptance for validation  When big picture of the app is shaky - Use ‘Lean Startup’ approach of Minimum Viable Product • Get something in front of customers quickly and measure
  • UrbanCode Inc. ©2013 Should I support „Log-in with Facebook‟?
  • UrbanCode Inc. ©2013 Should I support „Log-in with Facebook‟?
  • UrbanCode Inc. ©2013 Should I support „Log-in with Facebook‟? Pro: Lower sign-up barrier to entry. More customers! Con: My company is B2B. Maybe Facebook is too personal 1) Acknowledge uncertainty
  • UrbanCode Inc. ©2013 Should I support „Log-in with Facebook‟? Pro: Lower sign-up barrier to entry. More customers! Con: My company is B2B. Maybe Facebook is too personal 2) Establish a Thesis 10% of People who would otherwise ‘bounce’ will attempt to sign up w/ Facebook
  • UrbanCode Inc. ©2013 Pro: Lower sign-up barrier to entry. More customers! Con: My company is B2B. Maybe Facebook is too personal 3) Test it cheaply. Then decide 10% of People who would otherwise ‘bounce’ will attempt to sign up w/ Facebook Add button that doesn’t work for X% of visitors. Measure attempted use. Something went wrong. Try again. Should I support „Log-in with Facebook‟?
  • UrbanCode Inc. ©2013 Experimentation may depend on delivery Build the right thing Deliver it promptly Execute Efficiently Agile focuses here DevOps focuses here DevOps also helps with feedback
  • UrbanCode Inc. ©2013 Visualize waste with lean techniques Spaghetti Diagramming - shows motion, such as handoffs and the flow of artifacts between people Value Stream Mapping - shows the temporal division between work being done (value being added) and waiting (waste) image credits: http://commons.wikimedia.org/wiki/File:Diagram_spaghetti_kilka_produktow.PNG http://www.michaelnygard.com/blog/2008/02/outrunning_your_headlights.html
  • UrbanCode Inc. ©2013 Example: Sign-off Process 1. PM emails Dev Manager 2. Dev Manager emails PM 3. PM emails QA Manager 4. QA Manager emails PM 5. PM emails Operations 6. Operations emails PM
  • UrbanCode Inc. ©2013 Spaghetti diagrams show flow of work
  • UrbanCode Inc. ©2013 Value stream map shows delays --- 30 30 30 30 30 1 1 1 1 1 1 Waiting Working 150 6 1. PM  Dev 2. PM  Dev 3. PM  QA 4. PM  QA 5. PM  Ops 6. PM  Ops
  • UrbanCode Inc. ©2013 Value stream map after process change --- --- 30 --- 30 30 1 --- 1 --- 1 1 Waiting Working 90 4 1. PM  Dev 2. ---------- 3. Dev  QA 4. ---------- 5. QA  Ops 6. Ops  PM
  • UrbanCode Inc. ©2013 Lean Software Takeaways  Inspired by Lean Manufacturing  Strong emphasis on removing “waste”  The 7 Wastes of Lean Software Development  Tools for Visualizing Waste
  • UrbanCode Inc. ©2013 A Lean view of build & deployment
  • UrbanCode Inc. ©2013 Common Practice: “Dan the Deployer” 1. Pam emails Dan to deploy to the Development environment 2. Dan the Deployer reads the email 3. Dan moves the build artifacts to the Development environment 4. Dan runs the deployment scripts 5. Deployment script runs while Dan monitors progress via the console 6. Dan emails Pam to let her know the deployment is complete 7. Pam reads the email
  • UrbanCode Inc. ©2013 Dan‟s Diagram
  • UrbanCode Inc. ©2013 1. Pam emails 2. Dan reads 3. Moves artifacts 4. Launches script 5. Deploy runs 6. Dan emails 7. Pam reads --- ? ? ? 0 ? 1 1 1 1 1 10 1 1 Waiting Working ? 16 Delays from Dan
  • UrbanCode Inc. ©2013 What if Pam could click a button? http://commons.wikimedia.org/wiki/File:Big_Green_Button.png
  • UrbanCode Inc. ©2013 1. Pam triggers 2. ---------- 3. Move artifacts 4. ---------- 5. Deploy runs 6. System emails 7. Pam reads --- --- 0 --- 0 0 1 1 --- 1 --- 10 0 1 Waiting Working 1 13 Self-service deployment removes delays
  • UrbanCode Inc. ©2013 Deployment automation story  Offshore testing team needed to request deploys to test environments - Due to timezones, average turn-around was 20 hours - Giving the offshore team direct access to servers was not an option  Secure, automated deployments allow self-service - Turn around drops to under one hour  Win: 15% more testing gets done. Defects found faster, cheaper to fix, and product ships quicker.
  • UrbanCode Inc. ©2013 Bug fix & verify cycle 1. Pam commits a feature 2. Feature is built by Bob 3. Build with new feature is deployed by Dan 4. Tom the Tester tests new feature and reports a bug 5. Pam fixes the bug 6. Bug fix is built 7. Build with fix is deployed 8. Tom verifies the bug fix
  • UrbanCode Inc. ©2013 Manual fix & verify spaghetti
  • UrbanCode Inc. ©2013 Bug fix & verify value stream 720 3600 240 2880 720 3600 240 15 15 120 60 15 15 60 Waiting Working 12000 300 1. Feature build 2. Build deployed 3. Bug reported 4. Pam fixes 5. Fix built 6. Fix deployed 7. Tom verifies
  • UrbanCode Inc. ©2013 Adding automation 1. Automated builds (CI); that invokes: 2. Automated deployments; that invokes: 3. Automated regression tests
  • UrbanCode Inc. ©2013 15 15 120 60 15 15 60 1. Feature build 2. Build deployed 3. Bug reported 4. Pam fixes 5. Fix built 6. Fix deployed 7. Tom verifies 720 3600 240 2880 720 3600 240 Waiting Working 12000 300 Impact of continuous delivery
  • UrbanCode Inc. ©2013 720 3600 240 2880 720 3600 240 15 15 120 60 15 15 60 1. Feature build 2. Build deployed 3. Bug reported 4. Pam fixes 5. Fix built 6. Fix deployed 7. Tom verifies Waiting Working 12000 300 Impact of automated testing
  • UrbanCode Inc. ©2013 1. Feature build 2. Build deployed 3. Bug reported 4. Pam fixes 5. Fix built 6. Fix deployed 7. Tom verifies Waiting Working 12000 300 720 3600 240 2880 720 3600 240 15 15 120 60 15 15 60 Impact of automated reporting
  • UrbanCode Inc. ©2013 Bug fix & verify with Enterprise CD
  • UrbanCode Inc. ©2013 Bug fix & verify value stream with ECD 0 0 0 60 0 0 1440 15 15 30 15 15 15 120 Waiting Working 1500 225 1. Feature build 2. Build deployed 3. Bug reported 4. Pam fixes 5. Fix built 6. Fix deployed 7. Tom verifies
  • UrbanCode Inc. ©2013 CD impact on bug fix & verify cycle Partially Done Work Extra Processes: no bug “hot potato”; Tom tests once Extra Features Task Switching: Pam quickly notified of defect Waiting: no waiting for builds or deployments Motion: fewer handoffs; no bug report adminstrivia Defects: more time testing, can find additional defects
  • UrbanCode Inc. ©2013 The impact of automated building & testing  90% rise in LOC output/programmer when performing builds at least daily  36% reduction in defect rate when integration/regression testing at each code check-in “Trade-offs between Productivity and Quality in Selecting Software Development Practices”, IEEE Software, Sept-Oct 2003
  • UrbanCode Inc. ©2013 Think at the system level Image credit: http://52weeksofux.com/post/694598769/the-local-maximum
  • UrbanCode Inc. ©2013 Urbancode.com/resources Continuous Delivery Maturity Model Deployment Automation Basics Value of Deployment Automation Blogs.urbancode.com Twitter.com/UrbanCode Facebook.com/IBMUrbanCodeProducts SlideShare.net/Urbancode Further Resources
  • UrbanCode Inc. ©2013 Yes, UrbanCode has tools that help  IBM UrbanCode Deploy - Application Release Automation  IBM UrbanCode Release - Release management and release weekend v execution  IBM UrbanCode Build - Build automation on an enterprise scale
  • Q&A eminick@us.ibm.com Slideshare.net/Urbancode @EricMinick Linked-in group: “Automating Deployment and Release”