Scaling Agile Up to the Enterprise and Staying Lean

TK
Half‐day Tutorial
6/4/2013 1:00 PM

"Scaling Agile Up to the Enterprise
and Staying Lean"

Presented by:
Dean Leffingwell
Leffingwell, LLC

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073
888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

Dean Leffingwell
Leffingwell, LLC

A renowned methodologist, author, coach, entrepreneur, and executive, Dean
Leffingwell founded Requisite, Inc., which was acquired by Rational Software. As a vice
president at Rational (now part of IBM), Dean’s responsibilities included the Rational Unified
Process. As chief methodologist at Rally Software, he worked with large enterprises to achieve
the business benefits of agility by helping to define and implement the tooling and practices
needed to support large-scale agile development. Dean is the author of Agile Software
Requirements, Scaling Software Agility, and Managing Software Requirements. His most recent
project is the Scaled Agile Framework (scaledagileframework.com) which describes a
comprehensive system for scaling lean and agile practices to the largest software enterprises.

Scaling Agile Up to the
Enterprise and Staying Lean:
A Workshop
By Dean Leffingwell

Agile Development
Conference West
Las Vegas, Nevada
June 2013
© 2008 - 2013 Leffingwell, LLC. All rights reserved.

© 2008 - 2013 Leffingwell, LLC.

1

Agenda

Scaled Agile Framework Overview
Be Lean
Be Agile
Scale to the Program: The Agile Release Train
Scale to the Portfolio: Agile Portfolio Management
Scale Leadership
S


2

1

About Dean Leffingwell

Founder and CEO

Creator: Scaled
Agile Framework
Fellow: Lean
Systems Society
Agile Enterprise Coach:

ProQuo Inc., Internet
ProQuo, Inc
identity

Senior VP

To some of the world’s largest
enterprises

Rational Software
Responsible for Rational
Unified Process (RUP) &
Promulgation of UML

Chief Methodologist

Founder/CEO
Requisite, Inc.
Makers of RequisitePro

Rally Software

Cofounder/Advisor

Founder/CEO

Ping Identity, Roving Planet,
Silver Creek Systems Rally
Systems,
Software

RELA, Inc.
Colorado MEDtech

3


The Scaled Agile Framework® (SAFe)
The Scaled Agile Framework is a proven, publicly-facing framework
for applying Lean and Agile practices at enterprise scale

Synchronizes alignment,
collaboration and delivery
Well defined in books
and now on the web
Scales successfully to large
numbers of practitioners and
teams
Core values:
Alignment
Code Quality
Program Execution
Transparency


4

2

Contributors
Associate
Methodologist

Principal
Contributors

Drew Jemilo

Colin O’Neill

Alex Yakyma

Alan Shalloway

Acknowledgements

Enterprise
Adopters

Community


5


6

3

Agenda

Be Lean
Be Agile
Scale Leadership
S

7


Lean Thinking Provides the Tools We Need

Respect for
People

Product
Development
Flow


Kaizen

8

4

Goal: Speed, Value, Quality

Respect for
People

Product
Development
Flow

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.

Kaizen

̶ Taiichi Ohno

THE GOAL
Sustainably shortest lead time
Best quality and value to people
and society
Most customer delight, lowest
cost, high morale, safety

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

Most software problems will exhibit
themselves as a delay.
̶ Alan Shalloway

9


Respect for People

Your customer is whoever
consumes your work
y
Respect for
People

Product
Development
Flow

Don’t trouble your customers

Kaizen

Don't force people to do
wasteful work
Don't overload them
Don't make them wait

PEOPLE
Develop individuals and teams;
they build products
Empower teams to continuously
improve
Build partnerships based on
trust and mutual respect

p
g
Don't impose wishful thinking
Equip them with problem-solving
tools
Form long-term relationships based
on trust


10

5

Kaizen

Steady, small improvements
Respect for
People

Product
Development
Flow

C
id
ll data, then implement
t
Consider all d t th i l
change rapidly

Kaizen

Reflect at key milestones to identify
and improve shortcomings

BECOME RELENTLESS IN:
Reflection
Continuous improvement as an
entreprise value

Use tools like retrospectives, root
cause analysis, and value stream
mapping
Protect the knowledge b
by
P t t th k
l d base b
developing stable personnel and
careful succession systems


11

Foundation: Leadership

Respect for
People

Product
Development
Flow

Develop people. They will develop
solutions
solutions.
Management understands and
teaches lean and agile behaviors

Kaizen

Management is trained in the
practices and tools of continuous
improvement

Lean-Thinking ManagerTeachers
Management is trained in
M
ti t i di
lean thinking
Bases decisions on this
long term philosophy

Management takes responsibility for
Lean success
Teaches employees problem solving
and corrective action
Managers are expected to see with
their own eyes


12

6

Principles of Product Development Flow

1. Take an economic view
Respect for
People

Product
Development
Flow

2.
2. Actively manage queues

Kaizen

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

Reinertsen, Don. Principles of Product Development Flow

8. Decentralize control
13


PPDF #1 – Take an Economic View
Base your decisions on economics
Develop an economic
framework for
decision making

Understand the full
value chain
Sequence jobs for
maximum benefit

Empower local
decision making

If you only quantify one
thing, quantify the cost
of delay

Do not consider money
already spent

Cost f
C t of
Delay
A

High Weight First

B
C



14

7

PPDF #2 – Actively Manage Queues
Email from a client service organization: “Thank you for contacting us. We are experiencing
increased volumes and apologize in advance for the delay. Our goal is to contact you within…..

Understand Little’s Law

Wait time = queue
length/processing rate
Control queue sizes to control
wait times
Operating at high levels of
utilization increases variability
Measure cycle time and queue
length with cumulative
flow diagrams

15


PPDF #3 – Understand and Exploit Variability
Risk-taking is central to value creation in product development
We cannot add value without
adding variability
ddi
i bilit

VALUE

Development variability can
increase economic value
Buffers trade money and time for
variability reduction

EPIC

Schedule buffers convert uncertain
earliness to certain lateness

EPIC

Managing variability
By investing relatively more in beneficial areas
and abandoning wasteful ones, the enterprise
maximizes economic benefit

– Planning and requirements

forecasting are exponentially easier
in short-term horizons

– Research spikes, incremental value
delivery and fast feedback are
critical



16

8

PPDF #4 – Reduce Batch Size
Small batches go through the system faster, with lower variability

Large b t h sizes i
L
batch i
increase variability
i bilit
High utilization increases variability
Severe project slippage is the most
likely result

Reducing batch i
R d i b t h size
– Reduces cycle time; faster feedback
– Decreases variability and risk
Most important batch is the transport
(handoff) batch
Proximity (co-location) enables small
batch sizes
Good infrastructure enables small
batches (build and test automation,
(
,
continuous integration, etc)
Loose architectural coupling enables
small batches

Slippage in projects rises exponentially with duration
Fig. Source: Poppendieck. Implementing Lean Software Development


17


Exercise – Large Batch Push

Batch Push
1. Create groups of five with ten
pennies per group. One person is
the time keeper. The remaining four
people process the pennies.
2. Person by person, flip all pennies
one at a time, recording your own
results (heads or tails)
3. Pass all pennies at th same ti
3 P
ll
i
t the
time
to the next person
4. The time keeper records the time
from the start of the first flip to the
completion of the last flip

Timebox:
5 minutes
18

9

Exercise – Small Batch Pull

Small Batch Pull
1.
1 Same four person process
2. Flip each penny one at a time and
record your own results
3. Pass each penny as flipped
4. The time keeper records the time
from the start of the first flip to the
completion of the last flip

Timebox:
5 minutes
19


Discussion – Rework
A defect is discovered on the third penny at
station four. All pennies have the defect.

Timebox:
5 minutes

The defect was induced at station three, and
requires 10 sec. of rework at station three
How much rework i required i push vs. pull?
H
h
k is
i d in
h
ll?

Push

Pull

1

2

3

4
20

10

Finding Economic Batch Size
Optimum batch size is an example of a “U-Curve optimization”

Cost

Optimum
Batch Size

Total Cost

Higher transaction
costs shift
optimum batch
size higher
Higher holding
costs shift it lower

Holding
Cost

Transaction
T
ti
Cost

Batch size
reduction probably
saves 2X what
you think!

Items per Batch


21

Agenda

Be Lean
Be Agile
Scale Leadership
S


22

11

Agile Accelerates Value Delivery

Documents

Documents

Unverified Code

Software


23

Accelerating Value Delivery

V
Value Delivery

Early value delivery drives first to market, fast feedback, and
profitability

Time

24

12

Exercise – Accelerating Value Delivery
Scenario 1 – Serial Delivery
Project A

Project B

Scenario 2 –
Parallel Delivery

Project C

Time

Project A
j
Project B

Your team has three projects. Each will take the
entire team one month and delivers one unit of
value.
Plot value delivery curves by doing the projects
serially and in p
y
parallel (
(simultaneously)
y)

Project C
Time

– Assume 20% task switching overhead for
Value

each team member in Scenario 2

Hint: Plot the serial case first

Time


Timebox:
10 minutes
25

VALUE DELIVERY

Makes Money Faster

TIME

26

13

Reduces Risk
Deadline
Waterfall

Risk

?
Agile
A il

Time
27


Avoids the Death March and Burnout

Pressure

Deadline

Peak performance
achieved and
maintained indefinitely
at a sustainable pace

Time

28

14

Delivers Better Fit for Purpose

Measure of
waterfall customer
dissatisfaction

agile
(adaptive) plan, result

waterfall plan, result

Time

29

Agile Teams
Empowered, self-organizing, self-managing teams with
developers, testers, content authority
Teams deliver valuable, fully tested software increments every
two weeks
Teams apply Scrum (and Kanban) project management practices
and XP technical practices
Teams operate under program vision, system, architecture and
UX guidance


30

15

Agile Teams are Lean
Scrum is Founded on Lean

SAFe Scrum

Cross functional teams
Time boxes to limit WIP
Sprints provide fast feedback
Empowered,
Empowered local decision
making
Colocation reduces batch
size and communication
overhead

XP. Quintessentially Lean?

XP Inspired Technical Practices
Continuous
g
Integration

TDD and ATDD limit waste
and scrap

User Stories

Small batch sizes
Test‐First:
TDD
ATDD

Scalability
Required

XP Inspired

Collective
Ownership

Agile
Analysis

Emergent
Design

Fast feedback:
Test first
Continuous integration
Test automation

Collective ownership

31

PPDF #5 – Apply WIP Constraints
WIP Constraints force capacity matching and increase flow

Apply WIP constraints

Force capacity matching
Accelerate delivery

Timebox

Prevent uncontrolled expansion of work
Make waiting times predictable

Purge lower value projects
when WIP is too high

Increase efficiency and throughput of
remaining work

Constrain local WIP pools

Constrains global WIP pools

Make WIP continuously
visible

1) Understand 2) take action

It is far easier to start a project than it is to finish one.


32

16

Exercise – WIP Constraints

1. Above is a software teams visible information radiator
2. How are they doing? How do you know that?
3. What would be the effect of three story WIP constraint on
development and test?

Today

Timebox:
5 minutes


33

Agenda

Be Lean
Be Agile
Scale Leadership
S


34

17

Scale to the Program Level
An empowered, self-organizing, self-managing team-of-agile
teams committed for continuous value delivery
Cadence based, synchronized
Aligned to a common mission
g

Fast feedback: fully tested, system-level solutions every 8-12
weeks
Common sprint lengths and normalized velocity
Face-to-face planning cadence provides development
collaboration, alignment, synchronization, evaluation

35

PPDF #6 – Control Flow Under Uncertainty

Transforms unpredictable events into
p
predictable events

Synchronization causes multiple
events to happen at the same time
pp

Requires scope or capacity margin

Scheduled, periodic
resynchronization limits variance to a
single time interval

Makes waiting times predictable
– If you can’t predict delivery, existing

programs become “feature magnets”

Manages load: When load and
utilization become too high, you will
p
see a sudden and catastrophic
reduction in throughput!

Regular, system wide integration
provides higher fidelity tests and
objective assessment
Synch events facilitate cross
functional tradeoffs of resources,
scope



36

18

Control Variability with Planning Cadence
Cadence-based planning timeboxes limit variability to a single interval

Max
Deviation
(3X)

Asynchronous
planning

Max
Deviation

Cadencebased
planning

Time

37

The Agile Release Train
The ART is the primary mechanism for accelerated value delivery
at scale

Align teams to a common vision
Manage interdependencies amongst teams
Provide continuous flow
Common training, common language, common schedule
Self-organizing, self-managing

Repeat until further notice. Project chartering not required.

38

19

The Agile Release Train
Organized around enterprise value streams
Delivers Potentially Shippable Increments (PSI) every eight to
twelve weeks


39

Rules of the Release Train
PSI dates for the solution are fixed
Estimating, planning and asset integration coordinated with
two-week sprint length, aligned cadence and normalized
velocity
Fortnightly (every two weeks) system integration and system
demo milestones are enforced
All “cargo” (code, docs, supplemental) goes on the train
The system always runs


40

20

Every Team Must Be on the Train
What do we
integrate here?

Planned release

Waterfall Doesn’t Iterate
Doesn t
Release docs
MRD

PRD

SRS

delay

Drop 1 Drop 2
to QA to QA

Dev

Test
drop 1

Test
drop 2
Ports, certs

Integration can’t work
here
PSI

Actual release

Agile Iterates
Iterate

Iterate

Release docs

Iterate

Iterate

Iterate

Iterate
Ports, certs

41


Cadence Alone is Not Enough

Planned system
release date

…the system is not sprinting ....time spent thinking you are
on track…….
track
System
External Release

PSI

Integrate
I t
t
and slip!

Release docs
Iterate

Iterate

Iterate

Iterate

Iterate

Iterate
Port and certs

PSI

External Release
Release docs

Iterate

Iterate

Iterate

Iterate

Iterate

Iterate
Port and certs
External Release

PSI

Release docs
Iterate

Iterate

Iterate


Iterate

42

21

Synchronize to Assure Delivery

Second System
PSI or Release

PSI

System
y
Iterations

Sys 1

Sys 2

Sys 3

Sys 5

Sys 6

Sys 7

Sys 8
External Release

PSI

Continuous
Integration

System
Team

Sys 4

Release docs
Iterate

Iterate

Iterate

Iterate

Iterate

Iterate

PSI

Ports certs
External Release

Continuous
Integration

Dev
Teams

Release Docs
Iterate

Iterate

Iterate

Iterate

Iterate

Iterate
Ports certs

PSI

Continuous
Integration

External Release
Release Docs

Iterate

Iterate

Iterate

Iterate

Iterate

Iterate
Ports certs

43


Develop on Cadence. Deliver on Demand.
Scenario A: Release less frequently than cadence
Deliver on Demand

Major
Release

Customer preview
PSI

Customer
Upgrade

QA-Release to MarketGovernance Firewall

Docs and
certs

Docs and
certs
PSI

Major
Release

Feature
Release

PSI

PSI

PSI

PSI

Develop on Cadence

44

22

Release Whenever You Like
Scenario B: Release on cadence

Scenario C: Release more frequently than cadence

45


PPDF #1 – Take an Economic View
Base your decisions on economics
Develop an economic
framework for
decision making

Understand the full
value chain
Sequence jobs for
maximum benefit

Empower local
decision making

If you only quantify one
thing, quantify the cost
of delay

Do not consider money
already spent

Cost f
C t of
Delay
A

High Weight First

B
C



46

23

Features and the Program Backlog
Features are services that fulfill
user needs
Features are identified, prioritized, estimated, and
maintained in the Program Backlog
The program backlog is the authority for what
gets built by each train


47

PPDF #1 – Take an Economic View: Prioritizing
Backlog for Optimal ROI
In a flow system, job sequencing is the key to economic outcomes

To prioritize based on lean
economics, we need to know two
things:

1. What is the Cost of Delay
(CoD) in delivering value

2. What is the cost to implement
the value thing
Principle of Product Development Flow E3: If you only quantify one thing, quantify the Cost
of Delay. ̶ Reinertsen 2009


48

24

CoD Economics: Shortest Job First
Cost of
Delay

When the cost of delay is equal,
do the Shortest Job First

Shortest Job First

A
1x3=

B

(1 + 3) x 3 =

C
Time

Cost of
Delay

Longest Job First
A

30

10 x 3 =

3
3

10

3

B
39

(10 + 3) x 3 =

3

C

C

1

B

A

Delay Cost

Time

From “The Principles of Product Development Flow,” by Donald G. Reinertsen. Celeritas Publishing: 2009. Copyright 2009, Donald G. Reinertsen

49


CoD Economics: High Delay Cost First
Cost of
Delay

High Delay Cost First

When the effort is equal, do the
high CoD job first

A
B
C

3x3=
(3 + 3) x 1 =

Cost of
Delay

6

Time
Low Delay Cost First

C

B

A

60

3

3

C

(3 + 3) x 10 =

3

B

3x3=

10

3

1

A
Delay Cost

Time



50

25

CoD Economics: Weighted Shortest Job First
Cost of
Delay

WSJF = Cost of Delay / Effort
y

A

B
C

1x3= 3
(1 + 3) x 1 =

When nothing is equal, do the
Weighted Shortest Job First!

High Delay Cost First

4

Cost of
Delay

Time

Low Delay Cost First
C

A

10 x 3 =
(10 + 3) x 10 =

130

10

3

3

1

C

B

1

B

10

10

1

0.1

A
Delay Cost

Time



51

Cost of Delay Components
Relative value in the eyes of the customer
User/
Business
Value

“They prefer this over that”.
Revenue impact on the business?
Penalty potential on the business?
How User Value Decays Over Time
Is there a fixed deadline?

Time Value

Will they wait for us or move to another solution?
What is the effect on customer satisfaction now?

Risk
Reduction/
Opportunity
Enablement
(RR|OE)

What else does this do for our business?
Reduce the risk of this or future delivery?
Is there value in the information we will receive?
Enable new business opportunities?

52

26

WSJF Prioritization Matrix
Weighted Shortest Job First (WSJF) provides
the greatest economic benefit

WSJF =

User Value + Time Value + RR|OE Value
Job Size

Scale for each parameter: 1, 2, 3, 5, 8,13, 21
Do one column at a time, start by picking the smallest item and giving it a “1”.
(There must be at least one “1” in each column!)
Highest WSJF is highest priority
53


Exercise: Prioritizing Program Backlog
Take 5 minutes and
identify your top 10
personal backlog items

As Lean Thinkers
we can prioritize our work
so that we can achieve the
best economic outcomes
for our stakeholders

Then,
Then using the prior
page, prioritize three of
your personal backlog
items using WSJF
Notes:
1. Estimate each backlog
item one column at
a time
2. There must be a “1” in
each column:
Timebox:
15 minutes


54

27

PPDF #2 Control Queues for Fast Response
Long queues, plus high utilization = unpredictability!

Little’s Law: the average wait time
equals th average queue l
l the
length
th
divided by the average processing time
Long queues. Long waits. Slow
delivery
Backlogs are a form of queue
(If items are committed, then it is a
queue)
Plus: Operating at high levels of
utilization increases unpredictability
For fast, reliable service:
Keep the program backlogs short and
uncommitted
Limit WIP to keep planned utilizations at
80% or below
Reinertsen, Principles of Product Development Flow, 2009.


55

Agenda

Be Lean
Be Agile
Scale Leadership
S


56

28

Scale to the Portfolio

Lean principles emphasize sustainably fastest value delivery
Centralize strategy. Decentralize execution.
Local decision making
Portfolio vision guides investments in solutions and the enterprise
architecture needed to support customer and business needs
Business epic kanban system provides visibility and work-inprocess limits to support continuous product development flow
Objective metrics support governance and kaizen
57


Lean-Agile Program Portfolio Management
SAFe patterns provide a transformation roadmap

#1 Centralized control

Decentralized decision-making

#2 Project overload

Continuous value flow

#3 Detailed project plans

Lightweight business cases

#4 Centralized annual planning

Decentralized, rolling-wave planning

#5 Work Breakdown Structure

Agile estimating and planning

#6 Project-based funding

Agile Release Trains

#7 Projects and PMBOK

Self-managing teams and programs

#8 Waterfall milestones

Objective, fact-based measures and
milestones

Legacy PPM

Agile PPM

58

29

#8 – Decentralize Control
Centralize control for decisions that

– Are infrequent
– Can be applied globally; have significant economies of
scale

– Age well
Decentralize control for all others

– Inefficiency of decentralization costs less than the value
of faster response time

– Local decisions have better local information
Control the economic logic behind a decision, not the entire
decision

– Set the framework, empower others to make the
decisions


59


Decentralize Control

Investment
Themes

Kanban

Market Feedback

Port
tfolio Backlog

Central Decision Making

Strategy

Program Backlog

Themes Drive
Release Train
Operating Budgets

Program Backlog
B

Program Backlog

Local Decision Making


One theme
drives cross
cutting Epics

Value Stream feedback



60

30

Agile Program Portfolio Management
Agile Program Portfolio Management fulfills key responsibilities
Decentralized decisionmaking
Continuous value flow
Lightweight business
cases
Decentralized, rollingwave planning

Agile estimating and
planning
Agile Release Trains
Agile Program
Management
Objective, factbased measures
and milestones

61

Agenda

Be Lean
Be Agile
Scale Leadership
S


62

31

Foundation: Leadership

Respect for
People

Product
Development
Flow

Develop people. They will develop
solutions
solutions.
Management understands and
teaches lean and agile behaviors

Kaizen

Management is trained in the
practices and tools of continuous
improvement

Lean-Thinking ManagerTeachers
Management is trained in
M
ti t i di
lean thinking
Bases decisions on this
long term philosophy

Management takes responsibility for
Lean success
Teaches employees problem solving
and corrective action
Managers are expected to see with
their own eyes


63

On “Managing” Knowledge Workers
“Workers are knowledge workers if they are more knowledgeable
about the work they perform than their bosses.”
Workers themselves are best placed
p
to make decisions about how to
perform their work and how to
modify processes to improve how
their work is performed.
To effectively lead knowledge
workers, the workers must be heard
and respected

Peter Drucker

Knowledge workers have to manage
themselves. They have to have
autonomy.
Continuing innovation has to be part
of the work, the task and the
responsibility of knowledge workers.

64

32

Leadership Styles
The effectiveness of your workers is determined in large part by your
personal leadership style

Leader as Expert
Leader as Conductor
Leader as Developer


65

Leader as Developer of People
A post-heroic, lean leadership style

Change in orientation

– Direct report-centric, rather
than manager-centric

Behaviors

– Creates a team jointly responsible for
success

– Asks “How can each problem be solved in a
way that further develops my direct reports’
commitment and capabilities?”

– Allows leader to spend more time managing
laterally and upward


66

33

Drive: Surprising Truth About What
Motivates Us

M
P
Video Source:
http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=youtu.be
Book: Drive: The Surprising Truth About What Motivates Us by
Daniel H. Pink. 2011

Timebox:
15 minutes
67


Another Perspective on Leadership

Quietly read the article “Leadership as a
Task, Rather than an Identity
Underline any sentences that you find
interesting or thought provoking
Be ready to share your thoughts

Source: Harvard Business Review article "Leadership in Online Labs”
Byron Reeves, Thomas W. Malone, and Tony O’Driscoll. 2008.


Timebox:
10 minutes
68

34

Excerpts from a Harvard Business Review article Leaderships Online Labs
- May 2008 by Byron Reeves, Thomas W. Malone, and Tony O’Driscoll

"The organizational and strategic challenges facing players who serve as [online] game leaders are
familiar ones: recruiting, assessing, motivating, rewarding, and retaining talented and culturally diverse
team members; identifying and capitalizing on the organization’s competitive advantage; analyzing
multiple streams of constantly changing and often incomplete data in order to make quick decisions
that have wide-ranging and sometimes long-lasting effects. But these management challenges are
heightened in online games because an organization must be built and sustained with a volunteer
workforce in a fluid and digitally mediated environment.”
g
y
"Put simply, online games can be informal but realistic simulators for contemporary leadership
training… Perhaps the most striking aspect of leadership in online games is the way in which leaders
naturally switch roles, directing others one minute and taking orders the next. Put another way,
leadership in games is a task, not an identity—a state that a player enters and exits rather than a
personal trait that emerges and thereafter defines the individual.”
"Don’t get us wrong: Leadership stars do exist in games. Some guild leaders have successfully led
100-strong teams for a year or more—an eternity in this new medium. As in business, players with
exceptional relationship skills are p
p
p
particularly g
y good at forming effective teams, delegating responsibility,
g
,
g
g
p
y,
and keeping groups motivated and moving forward. However, games do not foster the expectation that
leadership roles last forever. Someone leading a guild today may grow weary of the stress and hand
over the reins after a month or two. The leader of a raid knows that someone else’s skills and
experience may be better suited to commanding the next effort. Even during the frenzied activity of a
raid, the leadership role can be transferred as conditions change or because the person in charge
doesn’t happen to be around when the need for a decision arises. Notably, choices about who will lead
and who will follow are often made organically by the group—frequently because someone volunteers
to take over—not by some higher authority.”

69

Excerpts from Leaderships Online Labs (cont)
"Nevertheless, our findings reinforced our basic premise that leadership in online games offers a sneak
preview of tomorrow’s business world. In broad terms, that environment can be expected to feature the
fluid workforces, the self-organized and collaborative work activities, and the decentralized,
nonhierarchical leadership that typify games. In more specific terms, we found several distinctive
characteristics of leadership in online games that suggest some of the qualities tomorrow’s business
leaders will need in order to achieve success.”
g
p
people’s backgrounds and natural
g
"Most writing about leader selection and development focuses on p p
talents. Whether leadership ability is inborn or acquired through training, the assumption is that expertise
resides within the individual. Our study provided us with an arrestingly different view: Perhaps the right
environment is what really matters, whoever the leader happens to be. This concept, which as far as we
know is absent from the academic and professional literature about leadership, wasn’t something that we
set out to prove. The notion arose from the experienced gamers on our research team, who were puzzled
by our initial preoccupation with the individual qualities of game leaders. “If you want better leadership,”
they asked, “why not change the game instead of trying to change the leaders?”
So we began to focus on identifying distinctive aspects of online game environments that could improve
p
g
pinpointed at least two p p
properties of g
games that
leadership in business and other real-world settings. We p p
we believe facilitate and enhance leadership: nonmonetary incentives rooted in a virtual game economy;
and hyper-transparency of a wide range of information, including data about individual players’ capabilities
and performance. These two elements—along with the rich mix of text, audio, and visual communication
in games—make it easier for leaders to be effective. Players know exactly what they should be doing and,
to a large degree, have the tools they need to manage themselves. This suggests that organizations can
benefit by selectively “gamifying” their work environments in order to improve the quality of leadership—
not in the future but right away."

70

35

Inspire, Inform, Educate
Inspire: Expect and challenge management to lead, not follow the
Lean|Agile Transformation

Form and support a
Lean|Agile working group

Lean|Agile leadership
trainings and workshops

Include management

Scaled Agile Framework
Training and Certification

Create and work the
transformation backlog

Lunch and learns:
Principles of Product
Development Flow, Reinertsen

•

Agile Software Requirements,
Leffingwell

•

Implement effective
effective,
continuous communication
plan

•

Lean Software Development,
Poppendieck


71

Conclusion

The foundation of Lean

is leadership

The foundation of SAFe

is you


72

36

Next Steps
Browse the framework at
scaledagileframework.com
Read Agile Software
g
Requirements
Get training, certification,
courseware and
implementation tools through
Scaled Agile Academy
Start/accelerate your
Lean|Agile transformation
now
Implement your first Agile
Release Train

73

37

Scaling Agile Up to the Enterprise and Staying Lean

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a Scaling Agile Up to the Enterprise and Staying Lean

Semelhante a Scaling Agile Up to the Enterprise and Staying Lean (20)

Mais de TechWell

Mais de TechWell (20)

Último

Último (20)

Scaling Agile Up to the Enterprise and Staying Lean