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

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

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 TPS Just In Time Lean Supply Chain Prod Dev 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

Value Changes Constantly Value Changes Constantly

Principle 1: Eliminate Waste

P1: 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

P1: Partial Work – Good Practices

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

P1: Extra Features – Good Practices

P1: 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

P1: Relearning – Good Practices

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

P1: Handoff – Good Practices

P1: Task Switching Distracting & detracts from the result of both tasks Wasting time “resetting” context - Human’s aren’t CPU’s Humans are most efficient at 2 concurrent tasks Over 3 tasks and overall proficiency goes down

P1: Task Switching – Good Practices

P1: Delays Waiting for people who have information is wasteful

P1: Delays – Good Practices

P1: 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

P1: Defects – Good Practices

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

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

P2: Build Quality In – Good Practices

Built In Quality and VSTS Unit Testing and Code Coverage Check-in Policies Automated Web Testing 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

P3: Knowledge – Good Practices

P3: Knowledge – More Good Practices

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

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

P4: Defer Commitment – Good Practices

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

P5: Deliver Fast – Good Practices

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

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

P6: 3 Cornerstones

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

P7: Optimize – Good Practices

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 Prince2 Scrum FDD TDD

References For You

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

Thoughts? Questions?