leanban: the next step in the evolution of agile

Leanban: The Next Step in the Evolutionof AgileLean-Agile Transformation from the C-suite to Dev Ops

© Copyright Net Objectives, Inc. All Rights Reserved

Al [email protected]

@AlShalloway

CEO, Founder

Co-founder of Lean-Systems SocietyCo-founder Lean-Kanban University (no longer affiliated)Contributor to SAFe


Lean ManagementProject

Management

technical

Lean for ExecutivesProduct Portfolio ManagementBusiness Product OwnerProduct Owner

Onsite SPC Leading SAFe®Agile ArchitectureProduct Manager/PO

Leanban / Kanban / Scrum ATDD / TDD / Design Patterns

ASSESSMENTS

CONSULTING

TRAININGCOACHING


Absorb what is useful, reject what is useless, add what is specifically your own.

Bruce Lee

All models are wrong, some are useful.

George Box


A brief history of Agile1995 – Scrum1999 – XP2001 – Agile Manifesto2004 – Lean Software2007 – Kanban2007 – Scrumban2009 – Kanban Method


Lean-Kanban

Lean-Scrum

Webinar In a NutshellFocus on flow

Focus on Eco-System

Kanban

ScrumDisc

iplin

e Re

quire

d

Lean-Thinking

Leanban


1. The Beginnings – Iterative Development2.The Rise & Challenge of Flow-Only Based

Agile3.Contrasting Iterative and Flow-Only Based

Agile4.The Case for the Next Evolutionary Step for

Agile5.The Requirements for the Next Phase of

Agile6.Leanban – Continuing the Evolution of Agile

Agile Evolution’s Next Step: Introducing Leanban


Lessons from ScrumCross-functional teams are goodImprove collaborationEliminate wasteCadence coordinates different rolesIterations Create DisciplineShort term planning can be accurate

Principles are needed to learn

Theory without experience is useless. Experience without theory is expensive. - Paraphrase of Deming


Lessons from XPTest-first and automated testing results in long-term high quality, maintainable codeContinuous integration is importantSmall stories are importantCollaboration is criticalShared understanding of Agility is critical

If we have too high a bar for adoption – even when the practices are good – few teams will move forward.


1.The Beginnings – Iterative Development2. The Rise & Challenge of Flow-Only Based Agile3.Contrasting Iterative and Flow-Only Based






Challenges Implementing Agile• Can’t always form cross-functional teams• Unfamiliar roles are sometimes resisted• Too much change is bad• Lack of management inclusion• Lack of flexibility required in IT

& product environments with heavy maintenance costs


Lessons from KanbanUse kanban to manage flow with or without cross-functional teamsVisibility and explicit workflow greatly enhances learningIt is important to include managementHow to affect change when one can’t do any change at start

If we focus only on work flow, we will miss other opportunities for improvement.

Flow when you can, pull when you must. – many Lean senseis


1.The Beginnings – Iterative Development2.The Rise & Challenge of Flow-Only Based

Agile3. Contrasting Iterative and Flow-Only Based Agile4.The Case for the Next Evolutionary Step for





Scrum Kanban

Organize in cross-functional teams Use your current team organization. Team structure is orthogonal to some Kanban practitioners

Create new roles: PO, SM, Team Use existing roles

Just jump to Scrum and consider any impediments you face as issues to remove

Start where you are. Avoid making eco-system changes until after a kanban system has been put into place

Use time-boxed sprints for planning and guidance to finish things quickly

Do not have sprints nor plan work ahead besides creating a product backlog

Estimate work and use velocity based on estimates and work done to assist planning Do not estimate – considered wasteful activity

Create visibility of work going into and out of sprint as well as status of work being done. But don’t explain workflow rules.

Make all work visible to management including work status and workflow agreements.

Have learning retrospections at the end of every sprint Have explicit workflow policies that enable the use of kaizen to improve flow on a daily basis

Teams coached by a Scrum Master with no authority over them

Teams use existing team-leadership approaches in place prior to Kanban Method


Framework/Method Tunnel Vision

Frameworks and methods do not preclude others de jureBut focusing on one thing precludes others de factoScrum tends to preclude flow, explicit policies, management (doesn’t have to, but often does)Some Kanban methods tends to preclude teams (doesn’t have to, but often does)

In theory, theory and practice are the same. But in practice they are different. Albert Einstein

Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened. Winston Churchill


Scrum KanbanOrganize in cross-functional teams Use your current team organization. Team structure is

orthogonal to some Kanban practitionersCreate new roles: PO, SM, Team Use existing roles

Just jump to Scrum and consider any impediments you face as issues to remove

Start where you are. Avoid making eco-system changes until after a kanban system has been put into place

Use time-boxed sprints for planning and guidance to finish things quickly

Do not have sprints nor plan work ahead besides creating a product backlog

Estimate work and use velocity based on estimates and work done to assist planning Do not estimate – considered wasteful activity

Create visibility of work going into and out of sprint as well as status of work being done. But don’t explain workflow rules.

Make all work visible to management including work status and workflow agreements.

Have learning retrospections at the end of every sprint Have explicit workflow policies that enable the use of kaizen to improve flow on a daily basis

Teams coached by a Scrum Master with no authority over them

Teams use existing team-leadership approaches in place prior to Kanban Method

Why would we think we

have only two choices?

How can we pick the

appropriate practices?




Agile4. The Case for the Next Evolutionary Step for Agile5.The Requirements for the Next Phase of




What’s Missing?• Transition Management• Learning theory• Double loop learning


transition is a process


Transition happens at all levelsOrganizationManagement: Business & TechnologyTeamIndividual


The ideal rate of change depends on the ability of the organization to change

Ability to change

Amou

nt o

f cha

nge

attem

pted

Risk of resisti

ng change

Risk of insufficient change

Ideal Rate of Change


Novice – tell them what to do with a little whyAdvanced Beginner - tell them more whyCompetent – provide optionsProficient – have them chose on their ownExpert – have them make up new choices

Phases of Learning

It’s not about ‘being’ or ‘doing’

it’s about learning

We need a way to start for novices that navigates people into competent and proficient.


Double-Loop Learning – Chris Argyris

Assumptions(underlying beliefs form basis of

actions)

ActionsStrategies & Techniques

Results

Single-Loop LearningAdjust actions based on results keeping

approach you started with

Double-Loop LearningConsider new actions by challenging assumptions you made

based on results achieved





Agile5. The Requirements for the Next Phase of Agile6.Leanban – Continuing the Evolution of Agile



It’s not enough to combine Scrum & Kanban. They must be put in the context of business value delivery.


thinkingpoints

Requirements for Team-Level Agile (at Scale)

1. Work in context of enterprise • Helps ensure teams do the

core practices• Enables individuals to move

around more easily• Facilitates cross-team learning• Facilitates management

understanding


thinkingpoints


1. Work in context of enterprise

2. Business driven

• All teams must focus on getting MBIs done in concert and not locally optimizing

• Provides the mindset for coordination across teams


thinkingpoints



2. Business driven3. Adopt core practices

• Helps teams be effective without having to relearn the wheel

• Increases quality, predictability and velocity

• Take learnings from Scrum, XP, Kanban


thinkingpoints



2. Business driven3. Adopt core practices4. Practices tailored to the

team

• Variations must be accounted for

• Whether have cross-functional teams

• Whether need iterations• Level of team’s discipline• Discipline of team’s

interacting with


thinkingpoints

Requirements for Team-Level Agile (at Scale)1.Work in context of

enterprise 2.Business driven3.Adopt core

practices4.Practices tailored to

the team5. Attend to culture

• Culture is unique to a company.

• Requiring change may be a mistake but avoiding it usually is

• Must attend to culture and what degree of change is appropriate


1.The Beginnings – iterative development2.The Rise & Challenge of Flow-Only Based

Agile3.Contrasting iterative and Flow-Only Based



Agile6. Leanban – Continuing the Evolution of Agile



thinkingpoints



2. Business driven3. Adopt core practices

• Based on Lean principles• Helps teams be effective

without having to relearn the wheel

• Increases quality, predictability and velocity

• Take learnings from Scrum, XP, Kanban


What Methods Profess Vs What Everyone Should Do

KANBANImproves flow within existing structure

Focus on FinishingEverything VisibleExplicit Workflow

Manage WIP

eXtreme ProgrammingTest-First Unit TDD

Paired ProgrammingContinuous Integration

Automated testing

Small batchesSelf-organizationDaily standups

Focus on finishing

SCRUMCross functional team

Sprints provide discipline

Use estimation & velocity



Focus on finishingEverything visible



Automated testing

KANBANImproves flow within existing structureEverything VisibleExplicit Workflow

Manage WIP







Focus on finishingEverything visibleExplicit workflow



Automated testing

KANBANImproves flow within existing structureExplicit WorkflowManage WIP








Manage WIP



Automated testing

KANBANImproves flow within existing structureManage WIP








Manage WIPUse estimation & velocity



Automated testing

KANBANImproves flow within

existing structure






Adopt Test-First at Acceptance Level




ATDD

XPTest-First Unit TDD


Automated testing

KANBANCreate teams to extent possible

Adopt common cadence




Adopt Other Practices When Able




ATDD

LEAN-XPTest-First Unit TDD


Automated testing

LEAN-KANBAN

Create teams to extent possible

Adopt common cadence

LEAN-SCRUM

Cross functional team


Virtually everyone should be trying to do these

Virtually everyone should be doing these.


thinkingpoints



2. Business driven3. Adopt core practices4. Practices tailored to the

team

• Variations must be accounted for

• Whether have cross-functional teams

• Whether need iterations• Level of team’s discipline• Discipline of team’s

interacting with


call for Different Methods Different Situations

Do we need iterations for planning?Do we need iterations for discipline?Can we adopt test-driven development?Are our developers willing to pair?


Determining Where to StartCan cross-functional teams be created?

No

Yes

Are iterations needed

for planning

or discipline

?Yes

No

Use Leanban with cross-functional

teams and iterations

Use Leanban with a pure flow model

without cross-functional teams

Use Leanban with a pure flow model

with cross-functional teams


Plan decide on a practice (e.g., iterations)Do that practice

Study the result (is it working out?)

Act on the results. Keep doing it? Improve it? Do something new?

How To: Plan-Do-Study-Act

Plan

Do

Study

Act

Repeat


Practice Value Provided Challenge Presented Alternative Method of Getting Value

Time Boxing

Cadence for:• Input• Output• Demo• RetrospectionDisciplineSmall batchesVisibility In & OutVelocityPlanning MethodFocus

Difficult to close out at end of time-boxNo real backlog, but rather small items come in on a regular basis making planning difficultCost of time-box management high

Can have independent cadencesMust bring discipline to each story since they make take longer than should without itUse small batches / storiesUse visual controls throughout workflowMeasure velocity via cadencePlan ahead if valuableTake a value centric approach

Cross-Functional Team

Limits WIPReduces HandoffsImproves FeedbackShort term delays in workflowImproves Collaboration Improves learning

Certain key people must be spread across several teams

Attending to flow while using as close to a true team structure can achieve these valuesKanban for key folksDynamic Feature Teams

Product owner

Reduces unneeded features Team understands what needs to be done

An equivalent “one-voice” is needed regardless of method

How to Adopt a Better Practice


Focus on outcomes, not practicesOutcome to Achieve

Scrum Kanban What to Do

Coordination with other teams

Time-boxes all in synch Use cadence all in synch Use time-boxes or cadence

Intra-Team Collaboration

Cross-functional teams Insufficient, requires attempting to create teams

Create teams to the extent possible

Team in synch Daily standup Visual Control, daily standup Visual control, daily standup

Reality check Things not done at end of sprint are clear

Cycle time. Insufficient, requires tracking size of stories

Manage

Developer / tester relationship

Skills, but not roles.End of sprint checkpoint

Insufficient, ignores issue Time-boxing OR discipline with small storiesATDD highly recommended

Predictability of work done

Estimation and velocityInsufficient if don’t manage WIP

Insufficient, requires estimation

Estimation and velocity, Manage interruptions, Reduce technical debt

Smooth transition Often insufficient if teams don’t exist prior to transition

Can control rate of transition Use MBIs, create teams to the extent possible, sequence work, use ATDD

Reduce Technical Debt

Use XP style technical practices

Ignores Use test-first methods (ATDD/TDD), Continuous integration, Emergent Design


Focus on outcomes, not practicesOutcome to Achieve

Scrum Kanban What to Do

Finish stories quickly

Time boxes, small stories Managing WIP helps. Still insufficient as may not break stories down small enough

Time boxes OR discipline to complete stories quickly. Decompose to small stories using <given> <when> <then> story format.

Minimal delays in workflow

Cross-functional TeamsUse small stories

Manage WIP Cross-functional teams, Manage WIPUse small stories

Short feedback cycles

Use small storiesProduct owner and cross-functional teams

Manage WIPInsufficient – requires discipline

Use small stories, Manage WIPProduct owner and cross-functional teams

Balanced workload

Pull work based on velocity Manage WIP Pull work based on velocityManage WIP


Create ChecklistsPractice What It Achieves Doing?Explicit workflow Enables everyone to know what’s happening. Facilitates learning

Daily standups Keeps people informed (often not needed if co-located)

Make everything visible Facilitates learning and management. Detect challenges.

Common cadence/sprints Enables early synchronization of different teams

Build incrementally and iterate on the increments

Short feedback cycles and learning

Focus on finishing Avoid too much WIP, look for opportunities to collaborate

Do continuous integration Detect out of synchronization errors

Estimate work items and compute velocity (unless a maintenance group)

Validates understanding of items being worked on by the teams. Facilitates planning.

Work in small batches Faster feedback. Easier to avoid workflow delays. Enables people moving around as needed.

Use small stories Faster feedback. Easier to avoid workflow delays. Enables people moving around as needed.

Manage work in process (WIP) Eliminate delay, speed up feedback

Create cross-functional teams to the extent possible

Eliminate delay, speed up feedback, learn faster

Use test-first methods Better understand what is needed, convey this better, improve collaboration between dev and test, facilitate automation of test

Paired Programming Collaboration, shared knowledge of code base, increased discipline


thinkingpoints


enterprise 2.Business driven3.Adopt core

practices4.Practices tailored to

the team5. Attend to culture

• Culture is unique to a company.

• Requiring change may be a mistake but avoiding it usually is

• Must attend to culture and what degree of change is appropriate


Telling people “Just do it”

just doesn’t do it


When an organization starts at the team level, the teams learn local optimizations which they later have to give up when they consider the entire value stream.When an organization starts with the whole in mind, the teams improve as much as they can within this larger context.

Bottom up? Holistic? Consider …


thinkingpoints


enterprise 2.Business driven3.Adopt core practices4.Practices tailored to

the team5.Attend to culture6. How teams work

together

• Teams coordinate using Lean principles

• Many approaches• Core teams• Dynamic Feature Teams• Shared backlogs


Challenge: Can only create a few cross-functional teams


Solution:

use Kanban for othersCreate those you can,

review

© Copyright Net Objectives, Inc. All Rights Reserved 60

Summary Scrum, XP and Kanban are all partial

implementations of Lean that we can learn from If we drop the labels and certifications and come

from Lean we can see what works best Leanban is based on Lean-Thinking It includes what everyone should be doing It provides a way to see how to tailor it It provides a way to see how to adopt new

practices as needed


Lean ManagementProject

Management

technical

Lean for ExecutivesProduct Portfolio ManagementBusiness Product OwnerProduct Owner

Onsite SPC Leading SAFe®Agile ArchitectureProduct Manager/PO

Leanban / Kanban / Scrum ATDD / TDD / Design Patterns

ASSESSMENTS

CONSULTING

TRAININGCOACHING

Questions?

www.netobjectives.com/leanban