Lean Principles Agile Techniques Joel Semeniuk Imaginet Microsoft

Lean Principles, Agile Techniques Joel Semeniuk Imaginet Microsoft MVP – Team System Microsoft Regional Director DPR 204

History Lesson 1927: Toyoda Automatic Loom Works revolutionized the Loom – key, high precision, interchangeable parts Taiichi Ohno 1945: Challenge Company to catch up to America Answered the Challenge – Developed a Method Evolved Into Toyota Production System Kiichiro Toyoda Son of Sakichi Toyoda

Two Pillars of TMS Just-in-Time Flow Completely against conventional wisdom Found it to be the only model to effectively manage complexity Autonomiation Jidoka Work is organized such that the slightest abnormality is immediately detected Once detected, work stops, cause of problem remedied before work resumes Organization has reflexes – respond instantly and correctly to events without having to go to the “brain” for instruction.

From Then to Now TPS was ignored until oil crisis of 1973 Slowdown filtered out average companies Soon, Japan was out producing America

Evolution Just In TPS Lean Time Prod Dev Lean Supply Chain Lean Software Development

Team System Review

Myth 1: Early Specs Reduce Waste Tell me everything you need up front because it will save us time reworking mistakes

Principle 1: Eliminate Waste Not Adding Value Waste Preventing Value

Principle 1: Eliminate Waste Recognize Value Changes Constantly Recognize Waste Eliminate Waste

Principle 1: Eliminate Waste Handoffs Relearning Extra Features Partially Done Work Task Switching Delays Waste Defects

P 1: Partially Done Work Also called “Inventory” Goal – develop, integrated, test, document, deploy in a single, rapid flow Examples : Uncoded documentation – stale requirements Unsynchronized code – unmerged branches in source control Untested code – writing code without a way to detect defects creates partially done work Undocumented code – done as code is written Undeployed code – deploying as soon as possible incrementally

• Use fixed short Practices P 1: DO Partial Work – Good duration iterations DO • Tight control over branching and merging DO • Always have a way of detecting defects DO • Document code as it is written Do • Deploy as soon as the code is written

P 1: Extra Features No Value? Don’t Develop It! What’s bad about extra features? Added Complexity Added Debug Added Work Added Maint.

P 1: Extra Features – Good Practices DO • Use common sense DO • Focus on customer’s job features DO • Be biased against adding features DO • Architect with good patterns

P 1: Relearning Forgetting People forget things Make the same mistake twice Rediscover things we have forgotten Ignoring Not involving the right people during the development process Problem Documenting all design decisions as they are made This documentation is never looked at again So, we just stop documenting all together

P 1: Relearning – Good Practices • Just in Time Learning DO • Do not have an inventory of things to forget DO • Continually involve the users DO • Capture learning

P 1: Handoffs How do you hand off? Documentation? Tactical knowledge is key Handoffs degrade tactical knowledge

P 1: Handoff • Reduce – Goodhandoffs Practices DO DO • Use design-build teams DO • High bandwidth communication DO • Early releases

P 1: Task Switching Distracting & detracts from the result of both tasks Wasting time “resetting” context; humans aren’t CPUs Humans are most efficient at 2 concurrent tasks Over 3 tasks and overall proficiency goes down Efficiency 20 15 10 5 0 1 2 3 4

P 1: Task Switching – Good Practices • Rotate in/out maintenance DO DO • Carve off time during a day where team handles defects vs. new features DO • Set aside time to triage work DO • Try to maintain a single code base

P 1: Delays Waiting for people who have information is wasteful Question Immediate Answer No Waste

P 1: DO Delays • –Complete, Good Practices collocated teams DO • Short iterations with regular feedback DO • Make sure knowledge source is available when and where needed DO • If information isn’t immediately available • Stop, Switch, Guess

P 1: Defects Code + set of tests that do not let defects back into code Proves that the code does what we think it should do and doesn’t fail the way we anticipate Sign of a healthy agile team – very low defects Mistake proof code Find defects early and ensuring they don’t come back Inspection to prevent defects is required Inspection to find defects is a waste Test harness allows safety net for further changes

Prevent or find defects DO P 1: Defects – • Good Practices • Unit testing DO DO • Test Driven Development DO • Check-in policies DO • Gated Check-ins DO • Continuous Integration DO • Continuous Deployment

Reduce Waste and VSTS Code Review Work Item Unit Testing and Code Coverage* Triage Alerts Unplanned Work Iteration Based Scheduling Prioritization Traceability Continuous Integration & Extensible Build

Myth 2: The Job of Testing Is to Find Defects

Principle 2: Build Quality In Build quality in from the start Avoid creating defects in the first place Inspection to prevent defects is required Inspection to find defects is a waste If you can’t prevent defects – inspect often When you find a defect Fix it immediately Put in a test so that it doesn’t come back

• Prevent or find. Practices defects DO Quality P 2: Build In – Good • Unit testing DO DO • Test Driven Development DO • Check-in policies DO • Gated Check-ins DO • Continuous Integration DO • Continuous Deployment

Built-In Quality and VSTS Unit Testing and Code Coverage Automated Web Testing Check-in Policies Extensible Build and Deploy

Myth 3: Predictions Create Predictability Plans MUST be an accurate prediction of the future – that is what planning is for – to accurately predict the future!

Principle 3: Create Knowledge Predictions about future will be wrong if: Complex Detailed About the Future About an Uncertain Environment You can still be reliable even with uncertainty Predictions are not facts

P 3: DO Knowledge – Good Practices • Reduce response time DO • Embrace software development as a knowledge-creating process DO • Detailed design during coding DO • Expect design will evolve DO NOT • Lock down design prematurely

P 3: Knowledge – More Good Practices • Early release of minimum features DO DO • Daily builds and integration tests DO • Choose a leader with experience and instincts DO • Modular architecture DO • Optimize the Software Development Process

Knowledge and VSTS Process Improvement WIKI Tracking Variance with Work Items Process Template Modifications Continuous Integration

Myth 4: Planning Is Commitment Planning is required, especially on large government projects – how else can we get what we want?

Principle 4: Defer Commitment “In preparing for battle I have always found that plans are useless, but planning is indispensable” Dwight Eisenhower

DO P 4: Defer Commitment – Good–Practices • Decisions wait until you have most info DO • Try to make all decisions reversible DO • System doesn’t need 100% flexibility DO • Experiment with options, be open DO • Ensure planning, not commitment DO • Plan thoughtfully, commit sparingly

Defer Commitment and VSTS “Spike” Branches Tracking Options

Myth 5: Haste Makes Waste You must take your time, plan, and ensure you do it right the first time…

Principle 5: Deliver Fast Companies that compete on time usually have significant cost advantage over competitors

P 5: Deliver Fast – Good Practices • Use tight feedback loops DO DO • Use repeatable and reliable speed = quality and low waste DO • Have engaged, thinking people who make good decisions and help each other out DO • Have standards! But constantly experiment to find better ways

Deliver Fast and VSTS Coding Conventions Code Analysis Process Guidance Code Build Deploy

Myth 6: There Is One Best Way For everything….

Principle 6: Respect People There is no “one best way” There is no process that can’t get better Never-ending continuous improvement should be found in every team/organization Cornerstone to continuous improvement = PEOPLE Software engineering is primarily a PEOPLE process – embrace it

P 6: 3 Cornerstones • Embrace Entrepreneurial Leader DO • Foster engaged, thinking people • Focuses efforts on creating a great product DO • Embrace Expert Technical Workforce • Continually develop and nurture technical experience as a culture DO • Responsibility-Based Planning and Control • Give team general plans, reasonable goals and trust to self-organize • Develop reflexive organization where people think for themselves around common set of principles

Respect People Review Assigning Work Items to a Team

Myth 7: Optimize by Decomposition

Principle 7: Optimize the Whole Optimizing parts <> optimize the whole Find a higher measure that will drive the right results for the lower level metrics

• Value based process improvement DO P 7: Optimize – Good Practices • Refocus entire value stream often DO DO • Don’t be afraid to re-prioritize – look at all of the requirements as a whole DO • Make time to triage DO • Sprint Planning is a good example DO • Continually evolve your processes DO • Gather and process metrics

Optimize the Whole and VSTS Continually evolve work items Continually Evolve Process Templates Reflect with Reports and Analytics

Recap: The 7 Principles Are Eliminate Waste Build Quality In Create Knowledge Defer Commitment Deliver Fast Respect People Optimize the Whole

Some Things I Didn’t Say Eliminate waste ≠ no documentation Amplify learning ≠ keep changing your mind Decide as late as possible ≠ procrastinate Deliver as fast as possible ≠ rush and produce sloppy results Empower the team ≠ abandon leadership Build in quality ≠ big, upfront design Optimize the whole ≠ ignore details

Other Related Practices Seeing Waste Value Stream Mapping Self-Based Development Pull Systems Queuing Theory Motivation Measurements

This All Fits Together Lean TDD FDD Prince 2 Scrum

References for You

Of Course… Book signing at 5: 30 pm on Thursday ME!

Thoughts? Questions?

Resources www. microsoft. com/teched www. microsoft. com/learning Sessions On-Demand & Community Microsoft Certification & Training Resources http: //microsoft. com/technet http: //microsoft. com/msdn Resources for IT Professionals Resources for Developers www. microsoft. com/learning Microsoft Certification and Training Resources

DTL Track Resources Visit the DPR TLC for a chance to win a copy of Visual Studio Team Suite. Daily drawing occurs every day in the TLC at 4: 15 pm. Stop by for a raffle ticket http: //www. microsoft. com/visualstudio/enus/products/teamsystem/default. mspx Please visit us in the TLC blue area

Complete an evaluation on Comm. Net and enter to win!

© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U. S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.