Lean Principles, Agile Techniques and Team SystemJoel SemeniukImaginetMicrosoft MVP – Team SystemMicrosoft Regional Director

History Lesson

Kiichiro ToyodaSon 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 InTime

Lean

LeanSuppl

y 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.

Not Adding

Value

Preventin

g Valu

e

Waste

Principle 1: Eliminate Waste

Recognize Value

Recognize Waste

Eliminate Waste

Principle 1: Eliminate Waste

Value Changes

Constantly

Principle 1: Eliminate Waste

Waste

Partially Done Work

Extra Features

RelearningHandoffs

Task Switching

Delays

Defects

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

•Use fixed short duration iterationsDO•Tight control over branching and mergingDO•Always have a way of detecting defectsDO•Document code as it is writtenDO•Deploy as soon as the code is writtenDo

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 •Use common senseDO

•Focus on customer’s job – !featuresDO•Be bias against adding featuresDO•Architect with good patternsDO

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

•Just in Time Learning•Do not have an inventory of things to forget

DO

•Continually involve the usersDO

•Capture learningDO

P1: Handoffs

• How do you hand off? Documentation?

• Tactical knowledge is key• Handoffs degrade tactical knowledge

P1: Handoff – Good Practices

•Reduce handoffsDO

•Use design-build teamsDO

•High bandwidth communicationDO

•Early releasesDO

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

1 2 3 40

5

10

15

20

Efficiency

P1: Task Switching – Good Practices

•Rotate in/out maintenanceDO

•Carve off time during a day where team handle defects vs new featuresDO

•Set aside time to triage workDO

•Try to maintain a single code baseDO

P1: Delays

• Waiting for people who have information is wasteful

Question

Immediate

Answer

No

Waste

P1: Delays – Good Practices

• Complete, collocated teams DO

• Short iterations with regular feedbackDO

• Make sure knowledge source is available when and where neededDO

• If information isn’t immediately available• Stop, Switch, GuessDO

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

•Prevent or find defectsDO•Unit testingDO•Test Driven DevelopmentDO•Check-in policiesDO•Gated CheckinsDO•Continuous IntegrationDO•Continuous DeploymentDO

Reduce Waste and VSTSUnit 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

•Prevent or find defectsDO•Unit testingDO•Test Driven DevelopmentDO•Check-in policiesDO•Gated CheckinsDO•Continuous IntegrationDO•Continuous DeploymentDO

P2: Build Quality In – Good Practices

Built In Quality and VSTSUnit 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

• Reduce response timeDO•Embrace software development as a knowledge creating processDO•Detailed design during codingDO•Expect design will evolveDO•Lock down design prematurelyDO NOT

P3: Knowledge – More Good Practices

•Early release of minimum featuresDO•Daily builds and integration testsDO•Choose a leader with experience and instinctsDO•Modular architectureDO•Optimize the Software Development ProcessDO

Knowledge and VSTSProcess

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

•Decisions – wait until you have most infoDO•Try to make all decisions reversibleDO•System doesn’t need 100% flexibilityDO•Experiment with options, be openDO•Ensure planning not commitmentDO•Plan thoughtfully, commit sparinglyDO

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

FACT

P5: Deliver Fast – Good Practices

•Use tight feedback loopsDO

•Use Repeatable and reliable speed = quality and low wasteDO

•Have engaged, thinking people who make good decisions and help each other outDO

•Have standards! But constantly experiment to find better waysDO

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• Embrace Entrepreneurial Leader• Foster engaged, thinking people• Focuses efforts on creating a

great productDO

• 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

DO

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

•Value based process improvementDO•Refocus entire value stream often DO•Don’t be afraid to re-prioritize – look at all of the requirements as a wholeDO•Make time to TriageDO•Sprint Planning is a good exampleDO•Continually evolve your processesDO•Gather and processes metricsDO

Optimize the Whole and VSTSContinually

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 TogetherLean

References For You

Of Course….

ME!

Book signing at 5:30

on Thursda

y

Thoughts? Questions?