Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
Lean Concepts & Agile
Development
Lean Concept Recap
Lean Manufacturing Tenets
Specify Value
Map the Value Stream
Visualize Work
Create Flow – Eliminate Waste
Develop Customer Pull
Continuous Improvement
Toyota’s Taiichi Ohno
Why Implement Lean?
Manufacturing Example & Result in Our Market
Lean in Our Market
The Problem
 Sales at record levels
 Inventory too high
 Costs too high
 Unhappy Workers
 Long, costly change-
overs
The Lean Solution
 Shift to cellular manufacturing
 200+ Kaizen Events Yearly
 Employee Cross-Training
 Strategic Insourcing
 Executed at all levels
 Value Stream Managers
Lean in Our Market
The Results
 220% Productivity Increase
 400% Inventory Turns Increase
 200% Sales Increase
 10x Profit Improvement
Lean in Software
Development
Software Development Methodologies
Software Development Methodology
Framework used to structure, plan and control the process of
developing software and information systems.
Common Methodologies
 Waterfall - 1970’s to present, very old school
 Agile/Scrum - 2001 to present, modern & lean
 Kanban (“Scrumban”) - Now, continuous & lean
Lean Software Engineering
Waterfall: The Traditional Approach
Example Practitioners
Lean Software Engineering
Waterfall: What it Looks Like in Practice
Lots of artifacts and long development cycles
Lots of WIP, rework, “inventory”
Lean Software Engineering
Agile/Scrum: Software Engineering Gets Lean
Example Practitioners
Lean Software Engineering
Agile/Scrum: What it Looks Like in Practice
Lean Software Engineering
Kanban: Software Engineering Gets Lean(er)
Example Practitioners
Lean Software Engineering
Kanban: What it Looks Like in Practice
READY WIP READY TO SHIP
Lean Software Engineering
Dual Track Scrum: Emerging Concept
Discovery Track
Quickly generating validated product backlog items in collaborative
sessions with engineers & designers for Delivery Track.
Delivery Track
Engineering releasable software based on backlog items qualified and
defined in Discovery Track.
Lean Software Engineering
Additional Agile Reading & References
Introduction to User Stories:
http://www.agilemodeling.com/artifacts/userStory.htm#Introduction
Scrumban Overview:
http://leansoftwareengineering.com/ksse/scrum-ban/
Dual-Track Scrum:
http://www.svpg.com/dual-track-scrum/
Ryhme and Reason
 Why Responsive Development Is Important

More Related Content

Lean Concepts & Agile Software Methodologies

  • 1. Lean Concepts & Agile Development
  • 2. Lean Concept Recap Lean Manufacturing Tenets Specify Value Map the Value Stream Visualize Work Create Flow – Eliminate Waste Develop Customer Pull Continuous Improvement Toyota’s Taiichi Ohno
  • 3. Why Implement Lean? Manufacturing Example & Result in Our Market
  • 4. Lean in Our Market The Problem  Sales at record levels  Inventory too high  Costs too high  Unhappy Workers  Long, costly change- overs The Lean Solution  Shift to cellular manufacturing  200+ Kaizen Events Yearly  Employee Cross-Training  Strategic Insourcing  Executed at all levels  Value Stream Managers
  • 5. Lean in Our Market The Results  220% Productivity Increase  400% Inventory Turns Increase  200% Sales Increase  10x Profit Improvement
  • 7. Software Development Methodologies Software Development Methodology Framework used to structure, plan and control the process of developing software and information systems. Common Methodologies  Waterfall - 1970’s to present, very old school  Agile/Scrum - 2001 to present, modern & lean  Kanban (“Scrumban”) - Now, continuous & lean
  • 8. Lean Software Engineering Waterfall: The Traditional Approach Example Practitioners
  • 9. Lean Software Engineering Waterfall: What it Looks Like in Practice Lots of artifacts and long development cycles Lots of WIP, rework, “inventory”
  • 10. Lean Software Engineering Agile/Scrum: Software Engineering Gets Lean Example Practitioners
  • 11. Lean Software Engineering Agile/Scrum: What it Looks Like in Practice
  • 12. Lean Software Engineering Kanban: Software Engineering Gets Lean(er) Example Practitioners
  • 13. Lean Software Engineering Kanban: What it Looks Like in Practice READY WIP READY TO SHIP
  • 14. Lean Software Engineering Dual Track Scrum: Emerging Concept Discovery Track Quickly generating validated product backlog items in collaborative sessions with engineers & designers for Delivery Track. Delivery Track Engineering releasable software based on backlog items qualified and defined in Discovery Track.
  • 15. Lean Software Engineering Additional Agile Reading & References Introduction to User Stories: http://www.agilemodeling.com/artifacts/userStory.htm#Introduction Scrumban Overview: http://leansoftwareengineering.com/ksse/scrum-ban/ Dual-Track Scrum: http://www.svpg.com/dual-track-scrum/
  • 16. Ryhme and Reason  Why Responsive Development Is Important

Editor's Notes

  1. The term Kanban originated with physical cards that were placed in inventory bins that aided employees to visually identify when inventory was running low and it was time to “pull” more inventory.
  2. Billion,Wisconsin manufacturer of snowblowers and lawnmowers800+ employeesInventory was frequently returned from distributors and stacking upChangeover from lawn to snow took 2 weeks and $1 Million+ YearlyHOWNew leadership that distinguished itself, listened and communicated franklyExecutive commitment – spent days collaborating in lean eventsIssues made visible to allEmployee cross-training eliminated layoffsCellular manufacturing eliminated change-over costs and enabled additional units to be made on demandExtra capacity created allowed insourcing – smoother supply, higher quality
  3. Methodologies represent natural progression as tools and technology have improved – an demand more rapid changes.Kanban is used by many startups and is recommended by startup guru Eric Ries
  4. Been around since 1970Sequential phases from requirements (PRD) to dev to release.  Very rigid and formally documentedFeedback loops exist between phases to support modifying plans based on observed infoPlanning & requirements do not include feedback from developers - assumes feasibilityLittle crossover and collaboration - siloed groups (Research, planning, dev, testing)Attempts to plan milestones and costs of entire project up-front.  Very likely to be wrong.Attempts to develop whole, entire projects at once...no breaking up so feedback loops are too little too late.  Massive WIP – very little “shippable” at one time.Underlying Assumptions:There exists a reasonably well-defined set of requirements if we only take the time to understand them.During the development process, changes to requirements will be small enough that we can manage them without substantially rethinking or revising our plans.Software innovation and the research and development that is required to create a significant new software application can be done on a predictable schedule.
  5. Tons of documentationRigidReally formalSlow to change
  6. More responsive - 2 weeks sprints & iterationsMore flexible backlog and planning - anything outside of sprint is open for modificationFrequent shipping of functional elements (roughly every 2 weeks)Decreased focus on documentation and increased focus on interactionFocused on collaborative planning and requirements definition - reduces amount of rework and unfeasible requirementsSupport iterative and continuous improvement, assumes things will continue to be refinedRecognizes and addresses long timeframes and large projects will inevitably be derailed by unforseenchallenges
  7. Basic visualizationStill a little hard to grasp at a glanceCompartmentalized into sprintsScope, effort, and capacity measured by story points via “planning poker” during Sprint planningSprints formally scheduled with associated work scheduled for completion and release at a specific date.
  8. Visualization of statuses and progressIncreased responsivenessStandardized, flexible backlogTrue Pull systemConstant smooth process, elimination of rigid plan/release cyclesFocus on cycle time and throughput in place of burndown
  9. Visualize status at a glanceHard limit on WIPStrengthen “Pull” ProcessBetter OrganizationMore IntelligibleCapacity and performance gauged by story throughputIn order to properly project performance and throughput, all stories must be broken down into approximately identical and consistent sizes.Very little/loose calendar association (no defined beginning and end of periods and bodies of work)
  10. Helps reduce drawn out Sprint planning sessions with undefined user storiesIncreases collaboration with Engineers and Designers when defining stories, easing transition to production and deliveryFurther eliminates mini-waterfall effect of each specialized group creating artifacts and passing onto the next group for execution without collaborative definition sessionHeavy focus on Lean UX and prototyping in place of artifacts