(advanced practices_five keys).pptx - scaling software agility

© 2011, Leffingwell, LLC.

Agile Software Development Series

Alistair Cockburn and Jim Highsmith, Series Editors

Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise

Dean LeffingwellForeword by Don Reinertsen

Scaling Software Agility: Advanced Practices for Large

Enterprises

Five Keys to Building the Lean|Agile Enterprise

By Dean Leffingwell

Agile 2011 Salt Lake City, Utah

August, 2011





© 2011 Leffingwell, LLC.

About Dean Leffingwell

2










Five Keys to Building the Lean|Agile Enterprise ➵  Not Everything is a User Story:

Scalable Agile Requirements ➵  Think Agile Programs, Not Just Agile Teams:

The Agile Release Train and Program Kickstart ➵  Enterprise Systems Require Intentional

Architecture: Rearchitecting with Flow ➵  Portfolio Management Must be Agile Too:

Addressing Legacy Mindsets and the Agile PMO ➵  Your Enterprise Can Be No Leaner Than the

Executives Thinking: Lean Education and The Big Picture

3






#1 – NOT EVERYTHING IS A USER STORY

SCALABLE AGILE REQUIREMENTS

The Agile Team in The Enterprise

H

H H

H

There can be a large number of teams in the enterprise

“pods” of 5-10 teams building a feature, component, or subsystem is not unusual

Some product lines require 30-40-50 teams to build

However, the structure of each team is largely the same






Their work is based on the user story

User Story

As a <role> I can <activity>

So that <business value>

“As a Gmail user, I can select and highlight a conversation for further action”






Stories drive iterations

Story A Story B Story C Story D Story E Story F

Story …

Plan

Fixe

d R

esou

rces

Fixed Time (Iteration)

7






Implemented by Story

Is one of

Backlog Item

Task 1 1..*

Stories are maintained in the teams backlog

There is only one backlog for the team

All work comes from the backlog

If isn't a user story (defect, etc) it still goes in the backlog

“If there isn’t a story in the backlog, it ain’t gonna happen”






Implemented by Story

Is one of

Backlog Item

Task 1 1..*

Acceptance Test

Done when passes

1..*

1

A test and quality-centric approach

Teams perform unit testing and functional testing for every story

The details of the story go into the functional test, where they are the persistent representation of system behavior

Stories are temporal (not maintained after implementation)

Unit Test Functional Test

Consists of 1

1..* 1..*






Scaling Challenges

  Assume a program requires –  200 practitioners, (25 agile teams) to deliver a product –  The enterprise delivers software every 90 days in five, two

week iterations. –  Each team averages 15 stories per iteration. –  Number of stories that must be elaborated and delivered to

achieve the release objective = 25*5*15= 1,875!

  How is an enterprise supposed to reason about things? –  What is this new product going to actually do for our users? –  If we have 900 stories complete, 50% done, what do we

actually have working? How would we describe 900 things? –  How will we plan a release than contains 1,875 things?

  And, what if it took 500 people? 10






And further

  And, even if I know 100 things that “as a <role> I can <activity> so that <business value>”, can do

what Features does the system offer to its user and what Benefits do they provide?

11

Feature Benefit Stars for conversations Highlight conversations of

special interests Colored label categorization Easy eye discrimination of

different types of stories (folder like metaphor)

Smart phone client application

Faster and more facile use for phone users – ease adoption






So we need an additional level of planning

Iteration Cycle

Drives

Feedback - Adjust

Product & Release Cycle

Release Vision

Release Planning Release Scope and Boundaries

12

Iteration Planning

Develop & Test Review &

Adapt

Features

Stories






Which creates an iteration and release pattern

Stories

Release timebox

13






Implemented by Story Feature Realized by 0,1 1..*

Is one of

Backlog Item

Task 1 1..*

So we need to extend the information model

Features are another kind of Backlog Item

Introduce Gmail “Labels” as a “folder-like” conversation-organizing metaphor.

Or:

As a modestly skilled user, I can assign more than one colored label to a conversation so that I can see a conversation from multiple perspectives






Implemented by Story Feature Realized by

Is one of

Backlog Item

Task 1 1..*

Features also require testing

0,1 1..*

Acceptance Test

Done when passes

1..*

1 1

And maybe a new team …..

Features typically span many teams

Sometimes, a special team is dedicated for the purpose of testing system level features






Implemented by Story Feature

Realized by

0,1 1..*

Is one of

Backlog Item Non-functional Requirement

Constrained by

Task 1 1..*

Acceptance Test

Done when passes

1..*

1 1

1..*

0..*

System Qualities Test

Compliant when passes

0..* 0..*

Nonfunctional requirements (system qualities) also require testing

Often requires specialty skills and tools

May also be province of system team

1






At the enterprise portfolio level, even system features are too fine grained   There may be dozens of concurrent programs   Each delivering dozens of features to market   How do portfolio managers and system

architects communicate the sweeping, larger scale initiatives that drive those programs?

  We use the word “Epic” to describe this content type

17






Implemented by Story Epic Feature Realized by Realized by 0,1 1..* 0,1 1..*

Is one of

Backlog Item Non-functional Requirement

Constrained by

Task 1 1..*

Acceptance Test

Done when passes

1..*

1 1

1..*

0..*

System Qualities Test

Compliant when passes

0.. 0..*

Epics drive programs Epics are key value propositions that create competitive advantage

Epic may be implemented over long periods, even years

Epics may be user, or technology based

Big, abstract, high level, visionary

Arch User






One last question: Where do epics come from?   Investment themes represent the budget

allocations that drive the portfolio –  Agreed to investments in product lines or business units –  Typically updated annually or twice annually

16% 18%

7%

22%

17%

13% 7%

Cloud Computing Business Unit Strategic Investment Themes

2HF11

Customer Relationship Management

Employee data backup

Social Intranet

E-Commerce

Back office storage

User authentication

Computing Resources

E Commerce Epics






#2 – THINK AGILE PROGRAMS: NOT JUST AGILE TEAMS

AGILE RELEASE TRAIN & AGILE PROGRAM KICKSTART






The challenge: lots and lots of teams

  There are a lot of potentially agile teams (20-50-100-more) in the larger enterprise

  They all require training but team by team by team training is sloooowwww and expen$$ive

  Plus: –  Teams must be aligned to a common mission –  Scaling requires constant dependency management

amongst non-collocated teams –  Scaling delivery requires coordinated planning and

synchronized development

  Solution: launch Agile Release Trains Train, Plan and Execute.

21






The Agile Release Train

  Organize teams along value delivery lines   These teams train, plan and execute together   Development cadence (common schedule) is

fixed across all teams   Intermediate, integration milestones are

established   Common release governance

–  Release management team –  Scrum of Scrums –  Release Train Engineer

and Conductor

  Common architectural governance 22






Regular cadence of smaller, more frequent releases

 Faster value delivery and faster feedback –  60-120 days

 Less Work In Process

 Predictable delivery –  Date, theme, planned

feature set, quality

 Scope is the variable –  Release date and

quality are fixed

23

We have to figure out a way to deliver software so fast that our customers won’t have time to change their minds. ─Poppendiecks - Implementing Lean

Software Development






Fix: Cost, quality, schedule

24

Variable: Scope






Achieving cadence: Fix dates & quality, float features

  Teams learn that dates MATTER   Product owners learn that priorities MATTER   Agile teams MEET their commitments   Floating features provides the capacity reserve to meet deadlines

10/1/2010 11/1/2010 12/1/2010 1/1/2011 2/1/2011 3/1/2011

3/25/2011 9/24/2010

25






Everybody must be on the train

26

What do we integrate here??






Cadence alone is not enough

27

Time when you discover you are not

…....time spent thinking you are on track…….

The slowest component drags the train






Synchronize to assure delivery

28

S H I P !

Regular, system wide integration provides higher fidelity tests and objective assessment

Synch events facilitate cross functional tradeoffs

Assured Potentially Shippable Increment






Separate Development Concerns from Release Concerns

Release Release






Cadence pacemaker: Release Planning

  A full day or two for every release   Collocation: most everyone attends in person   Decentralized planning: the plan is owned by the teams   Product/Solution Managers own feature priorities   The team builds the plan from the vision   Development team owns

planning and high-level estimates   Architects work as intermediaries for

technical governance, interfaces, etc.

30

Global alignment. Local prioritization.

Lean Principle D7: There is more value created with overall alignment than local optimization. The Principles of Product Development Flow, Reinertsen 2009.






What is an agile program, really?

31

Plan

Commit

Execute Demo

Retro

Day 1 Day 10 Day 2-9

Team

One sprint (2 weeks)

Program: 5-10 teams

Plan

Commit

Demo

Retro

One PSI (10 weeks)

Execute






One week “All In” Agile program kickstart

When you’ve selected a domain for the train, go “All In” and “All at Once”

32

Training: Scrum for Teams

Release Planning

Scrum Master

Orientation

Product Owner

Orientation

Mon Tue Wed Thu Fri

 Train everyone at the same time  Same instructor, same method, same terminology  Most cost effective

 Align all teams to common release (PSI) objectives  Continue training during planning

 Orientation for specialty roles  (defer formal role training for now)  Tool training for teams

Tool training

GO. AGILE. NOW.






#3 – ENTERPRISE SYSTEMS REQUIRE INTENTIONAL ARCHITECTURE

REARCHITECTING WITH FLOW






The Challenge of Refactoring at Scale

 Excessive refactoring of large-scale systems can drive crappy economics and slow time to market –  Creates rework for large numbers of teams, most of whom would

otherwise NOT have to refactor

–  Potential impact on deployed systems/users

  Many drivers for system architecture arise from outside the domain, purview and visibility of the agile programs –  Business drivers: M&A, etc.

–  Common architectural constructs ease usability, extensibility, performance and maintenance

For systems of scale, some intentional architecture is necessary

34






Principles of Agile system architecture

  Principle # 1 ─ The teams that code the system design the system.

  Principle # 2 ─ Build the simplest architecture that can possibly work.

  Principle # 3 ─ When in doubt, code it (or model it) out.   Principle # 4 ─ They build it, they test it.   Principle # 5 ─ The bigger the system, the longer the

runway.   Principle # 6 ─ System architecture is a role

collaboration.   Principle # 7 ─ There is no monopoly on innovation.   Principle # 8 ─ Implement architectural flow

35


System architecture is a role collaboration

Architectural - Inputs - Ideas

- Constraints

36

Architectural Evolution






Architectural epics

Large, technology development initiatives, cutting across dimensions:

Time – affecting multiple releases of products, systems, services or solutions Scope – affecting multiple products, systems, services, or solutions Organization – affecting multiple teams, programs, business units

Examples –  UI framework for porting existing apps to mobile devices –  Common installer and licensing mechanism –  Industry security standard to lower data purchasing costs –  Support 64 bit back office servers

37






Where do these monsters come from?

  New product or service opportunities. Mergers/acquisitions.

  Changes in technologies that affect multiple products and services

  Problems within the existing solution set   Architectural governance

–  usability, extensibility, performance, and maintenance

  Common infrastructure and avoidance of duplication of effort

  Cost

38






Motivation for an architectural epic kanban system   Provide an agile framework for system

architects. They must be agile, too.   Drive incrementalism in architectural refactoring   Make architectural work in process (AWIP)

visible   Establish AWIP limits to control queue sizes, limit

global WIP and help assure product development flow

  Drive an effective collaboration with the development teams

39





Dean LeffingwellForeword by Don Reinertsen4. Implementa5on

  Ownership transi-ons   Teams begin implemen-ng at

release planning boundaries   Teams break epics into

features   Architect support on “pull”

basis

Problem/Solu-on Needs Iden-fica-on

Evalua-on Architecture Team Ownership

Implementa-on Development Team Ownership

Agile Release Trains

WIP Limit

Release planning boundary

Innova5on feedback

Ac-vi-es:   Effort size es-mate   Value size es-mate   Investment theme

alignment

Authority approves epic   Meets

threshold criteria

Architect Team Pulls Epic   Lead architect

assigned

Product/ Technology Council Approval

1. Funnel   Technology roadmap   Disrup-ve technology   Solu-on problem: compa-bility

speed, size, security, usability,   Common infrastructure/duplicate

investment

2. Backlog   Refine

understanding   Est. cost of delay   Refine effort est.   Rela-ve ranking

3.Analysis   Design alterna-ves  Modeling   Development

collabora-on   Solu-on/product management

collabora-on   Business case

WIP Limit

PSI 1 PSI 2 PSI 3 PSI 4

WIP Limit

PSI 1 PSI 2 PSI 3 PSI 4

WIP Limit

System Architect Design

Spike

Tech lead/

architect

Architectural Epic Kanban System






Splitting epics for implementation in the release train

41

Partition by subsystem, product or service

Major/Minor effort

System qualities Simple/Complex

Incremental functionality Variations in data

Build scaffolding first Break out a spike






# 4 PORTFOLIO MANAGEMENT MUST BE AGILE TOO

ADDRESSING LEGACY MINDSETS & THE AGILE PMO


Changing legacy mindsets

43

Investment Funding

“widget engineering” “order taker mentality”

Epic based portfolio planning

Intense development collaboration

Change Management

“Maximize utilization”

“Get it done”

Fixed resources short term only

Team commitments Adjust priorities

quarterly

Governance and Oversight

“Control through milestones/data”

“plan out a full year of projects”

Control through empirical release

increments Rolling wave

release planning

From:

To:

DTE Energy Case Study, Agile 2009






From “too many projects” to continuous content delivery

 Getting anything done (new feature or epic) requires creation of a new project

 Projects have significant overhead, planning, resourcing, execution, closure

 Once started, projects take on a life of their own. They develop antibodies to change and closure.

 Many small projects cause people to multiplex between projects –  Each project switch takes 20% overhead –  Working on three projects means people only deliver

value 40% of the time –  While switching to agile, one company diagnosed the

failures of the first 5 teams first few iterations. Conclusion: No one worked on the project long enough to accomplish anything!

Project, portfolio mix: Size, risk, reward

 Dedicated teams stop multiplexing – no one works on more than one team

 Project overhead is replaced by standard iteration and release cadence

 New initiatives appear as new content and are prioritized at each iteration/release boundary

 Work in an iteration/release is fixed  Team resources are adjusted only at

periodic release boundaries

Agile Release Train with content management






From waterfall/WBS/PERT to Agile velocity estimating and planning

 Traditional project estimates tasks at the lowest leaf

 Requiring all leafs be identified before estimate is given

 Forces Big Up Front Analysis and estimates based on false precision

 Force fits later activities into a flawed WBS

 Agile teams develop and monitor “velocity” (capacity) based on story points at iteration level

 Story points can be normalized across teams  Standardized estimating by analogous model can also

be applied at the level of Epics and Features  Epic estimating can be used for gross, portfolio-level

planning  Feature estimates can be used for release (product)

level planning  Story points used for iteration planning






From PMBOK to Agile project management

Work Breakdown Structure estimating

Gantt Charts scheduling

Critical Path analysis

Iteration planning

Actual velocity based estimating

Release planning and roadmap

Release/iteration review/ retrospective

2 pts

4 pts

2 pts

Reporting






From Gantt to asynchronous Sprints to Agile Release Train

Issues:  Irrelevant to agile teams  Hard to maintain  Always obsolete  If a team isn’t on the plan, is it

a “bad” team or “bad” plan?  Measure paper, not software

Issues:  Most agile companies start here  Little coordination amongst teams  Non-harmonized schedules  No visibility beyond the next

sprint  Little or no system level visibility

 Coordinates sprints  Multi- sprint visibility and

commitment  Teams work out

interdependencies on the fly  Full system visibility  Requires set-based development






From milestone-based to fact-based governance

 Teams report milestones with document -based reviews

 Subjective, milestone reports do not correlate to actual project status

 Teams “report to” project office (leader as conductor/boss)

 Teams cannot proceed until and unless they pass milestones (start-wait-start-wait waste cycle)

 Scheduling delays and overhead  Process changes dictated by “those who know

best”

 Milestones are iterations and incremental releases of working code

 Status and quality are quantitative, not subjective

 Project office “comes to teams” (enabling leadership model)

 Teams default model is to proceed unless stopped by business case (no process driven delays/waste)

 No scheduling delays and overhead  Process changes applied and harvested from

team’s retrospectives






From waterfall milestones to driving incremental delivery

  If (you must have them)   Then (they must drive incremental delivery)   Else (you don’t need them)

Commit to Maintenance

Program Approved

1.1 - 1.n Potentially shippable Increments

2.1 - 2.n Incremental releases






From legacy mindsets to Agile PMO drives release planning, reviews, retrospectives   Release planning is a routine, major enterprise “event”   Requires: coordination, cooperation, logistics, facilitation,

planning, discipline, metrics   Difficult for teams themselves to coordinate this across teams-of-

teams function.   Resource adjustment (change management) happens at these

boundaries! –  May be inappropriate for them to change their own resources

  Question: who has the skills and discipline necessary to institutionalize this critical agile best practice?

  Answer: PMO?






Summary - The Agile PMO New Mission: Enable, Empower, Ensure

1.  Leads value chain analysis 2.  Educate project managers in lean and agile 3.  Adopt agile estimating and portfolio planning 4.  Implement Agile Release Train best practices 5.  Implement common agile metrics: iteration, release &

process sets 6.  Join Agile Project Management Leadership Network

PMO enables, fosters, and promotes agile practices






#5 – YOUR ENTERPRISE CAN BE NO LEANER THAN THE EXECUTIVES THINKING

LEAN EDUCATION & GIVE THEM THE BIG PICTURE






The Challenge: let’s get real

  Managers, directors, and executives are not “chickens” in the enterprise. They are “pigs”. (And really big ones at that.)

  To be successful, our expectation must be not that they –  a) simply don’t interfere, or –  B) simply understand, or –  C) are even simply supportive

  Instead, they must LEAD. After all, that’s what leaders do

  Our job Inform, Educate, and Inspire them to their new lean/agile leadership mission

53






Lean Thinking House

54

Product Development Flow

1.  Take an economic view

2.  Actively manage queues

3.  Understand/exploit variability

4.  Reduce batch size 5.  Apply WIP Constraints 6.  Flow with uncertainty

Cadence and Synchronization

7.  Apply fast feedback 8.  Decentralize control

Derived from: Toyota Production System (2004) Larman and Vodde (2009)

Reinertsen (2009)






The Goal: Sustainably deliver value fast

  All we are doing is looking at the timeline, from the moment the customer gives us an order to the point where we collect the cash. And we are reducing the time line by reducing the non-value added wastes. -- Taiichi Ohno

  We need to figure out a way to deliver software so fast that our customers don’t have time to change their minds. --Poppendieck

  Focus on the baton, not the runners. -- Larman and Vodde

55

1)  Focus on customer requirements as they move through the system, not the people and organizations who manage them

2)  Minimize delays, handoffs and non-value added activities






  Managers are teachers, not directors

  Mentor people closely for years, in engineering and problem solving

  Teach people to analyze root causes and make problems visible; they discover how to improve

  Employees see managers understand and act on the goal of eliminating waste and delays

Lean Pillar 1: Respect for people

56

  Your customer is anyone who consumes your work or decisions

  Relentlessly analyze and change to stop troubling them

  Don't force people to do wasteful work   Don't give them defects   Don't make them wait   Don't impose wishful thinking on them   Don't overload them

  Management challenges people to change and may ask what to improve, but ...

  Workers learn problem solving skills and then decide how to improve

  Form long-term relationships based on trust

  Help partners improve and stay profitable

Source: Larman and Vodde, 2009






Lean Pillar 2: Continuous improvement   Respect your network of partners.

–  Treat your partners as extensions of your business.

–  Set challenging targets and assist your partners in achieving them.

–  Challenge them to grow and develop.

  Make decisions slowly by considering all data; implement decisions rapidly

  Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen). –  Once you have established a process, use continuous improvement

tools to determine the root cause of inefficiencies and apply effective countermeasures.

–  Protect the organizational knowledge base by developing stable personnel, slow promotion, and careful succession systems.

–  REFLECT (hansei) at key milestones and after you finish a project to identify shortcomings

57 Source: The Toyota Way, 2004






Lean foundation: Lean-thinking manager-teachers   Management is trained in lean thinking - bases decisions on

this long term philosophy   Management is trained in the practices and tools of continuous

improvement   Management leads, coaches and drive teams to continuously

improve

58

Kaizen Mind – your job, and the job of your employees, is to do the job AND improve your job. Endlessly.

Source: Larman and Vodde, 2009






IN THE HOUSE OF LEAN – PRINCIPLES OF PRODUCT DEVELOPMENT FLOW






Principles of Product Development Flow

1.  Take an economic view 2.  Actively manage queues 3.  Understand and exploit variability 4.  Reduce batch sizes 5.  Apply WIP constraints 6.  Control flow under uncertainty - cadence and

synchronization 7.  Get feedback as fast as possible 8.  Decentralize control

60

Reinertsen, Principles of Product Development Flow, 2009.

Give them the Big Picture: Scaled Agile Delivery Model

H

H H

H

©2011 Leffingwell, LLC.

See Agile So8ware Requirements: Lean Requirements Prac>ces for Teams, Programs, and the Enterprise and www.scalingsoRwareagility.wordpress.com






Inform, educate, inspire

  Inform –  Make sure the agile working group executes an

effective communication plan

  Educate –  Suggested Readings

– The Principles of Product Development Flow. Reinertsen – Scaling Software Agility, Best Practices for Large

Enterprises. Leffingwell. – Lean Software Development: An Agile Toolkit.

Poppendieck.

–  Have them attend a leadership workshop that you hold

  Inspire –  Expect and challenge them to lead, not follow






More from Dean Leffingwell

http://www.informit.com/store/product.aspx?isbn=0321635841)

63

(advanced practices_five keys).pptx - scaling software agility

Documents