Lean Concepts & Agile Software Methodologies

Editor's Notes

• #3: 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.
• #5: 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
• #8: 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
• #9: 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.
• #10: Tons of documentationRigidReally formalSlow to change
• #11: 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
• #12: 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.
• #13: 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
• #14: 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)
• #15: 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