Download - An Agile Practice Framework for Scaling Agile Adoption in an Enterprise

An Agile Practice Framework for Scaling

Agile Adoption in an Enterprise

by Brad Appleton

April 23, 2013

April 23, 2013

An Agile Practice Framework forScaling Agile Adoption in an Enterprise

Brad Appletonblog.bradapp.net

APLN Chicago

2

• Background• A Framework• Mindset & Values• Principles• Practices & Practice-Areas• Adoption• Scaling

Agenda

BackgroundA quick overview

April 23, 2013



APLN Chicago

4

OverviewHave an existing community-of-practice of

agile coaches, developers A few have have been part of agile efforts that

started between 1999-2003 More have been part of efforts since >=2007 The “third wave” started around 2008-2010 Had strong sr. mgmt sponsorship in late 2000’s Still have sr. mgmt support for Agile & Lean (but visibility & momentum has waned)

April 23, 2013



APLN Chicago

5

Waves of Adoption & Support

First wave of agile adoption efforts (1999-2003) were grass-roots practitioner-driven efforts that started bottom-up at the individual & team-level.

As the number of teams and interest grew, this gave rise to a second-wave (2003-2007) at the organization-level with top-down sponsorship/acceptance.

April 23, 2013



APLN Chicago

6

Waves of Adoption & Support [cont.]

The Third-wave (2008-2012) took an outside-in approach, using a “middle-management sandwich” to help grow more agile coaches and teams,

but experienced some new challenges … – Many teams & practitioners were new to agile

Less pre-existing expertise in agile principles & practices– Tailoring communication messages & meanings for

multiple audiences New practitioners, middle-management, and senior

management Each needs different emphasis on different sets of things at

different levels of detail

http://jaaksi.blogspot.com/2007/06/middle-management-sandwich.html

April 23, 2013



APLN Chicago

7

How are adoption efforts going?

Some teams are further along in their progress than others Some are “doing agile” or even “being agile” Many others are still struggling to get more than

just minor improvement Still more have stalled due to loss of momentum or

critical-mass (some have even regressed backward)

What can be done to get back on track?!

April 23, 2013



APLN Chicago

8

What is the barrier/plateau?

Progress (and motivation) has been slowing1. To make important cultural and mind-set changes2. To fully realize the significance of key principles, technical

practices and technical debt3. To escalate & overcome external impediments4. To adequately grow automation capability + test-coverage.

No clear milestones other than “initial state” and “desired state” – the gap is too intimidating!

An Agile Framework?

Challenges, Goals & Objectives

April 23, 2013



APLN Chicago

10

Evolution -vs- RevolutionAgile Transformation: Revolutionary

Getting an entire organization to change it’s culture and practices, together. (Very often top-down!)

Learn “The whole enchilada” and begin training and adoption of (most) all the practices at once.

Incremental Transition: Evolutionary Getting a few key people & teams at a time to learn and

adopt a practice or two at a time. (Very often bottom-up!) Gradually building competence with a handful of practices

and teams before trying a new one.

Existing organizational-culture and business-context determines which approach is acceptable!

April 23, 2013



APLN Chicago

11

Being Agile: Internalizing the mindset, values, and principles then applying the right practices and tailoring them to different situations as they arise.

Doing Agile: Executing the practices as closely as possible to “as prescribed” description, and trying to “inspect and adapt” to remove impediments to achieving the “as prescribed” execution.

• Don’t “Do” Agile. Be Agile! –Alan Kelly

• Stop ‘Doing Agile’ Start ‘Being Agile’! –Jim Highsmith

Doing Agile versus Being Agile

April 23, 2013



APLN Chicago

12

http://www.halfarsedagilemanifesto.org/

http://www.halfarsedagilemanifesto.org/

April 23, 2013



APLN Chicago

13

WANTED: more adoption guidance and progress milestones (and

scaling)

http://leadinganswers.typepad.com/leading_answers/2011/04/periodic-table-of-agile-adoption-.html

http://leadinganswers.typepad.com/leading_answers/2011/04/periodic-table-of-agile-adoption-.html

http://leadinganswers.typepad.com/.a/6a00d834527c1469e2014e605c3e90970c-popup

April 23, 2013



APLN Chicago

14

Looking for a Framework …

That synthesizes existing/proven frameworks• Practices from the full range of methods:

XP, Scrum, Lean, FDD, AUP• Team-Level Agility:

Disciplined Agile Delivery (DAD) – Ambler & Lines Distributed Scrum

• Scaling: Scaled Agile Framework (SAFe) – Leffingwell, et.al. Enterprise Agile Delivery – Alan Brown, et.al.

• Learning and Mastery: Dreyfus model, other models,

http://www.disciplinedagiledelivery.com/

http://www.distributedscrum.com/

http://www.scaledagileframework.com/

http://www.amazon.com/dp/0321803019

April 23, 2013



APLN Chicago

15

April 23, 2013



APLN Chicago

16

Other important requirements

• Not looking to do top-down “transformation” of a whole program or organization

• Start small (individual teams) and help them incrementally grow their agility “up” and “out”

• Striving for high-cohesion within teams and loose-coupling between teams

• Existing frameworks (e.g., DAD, SAFe) are good as long as proceed in an evolutionary fashion

Agile

Sca

ling

Agile Adoption

Agile Results

Agile Practices

Agile Principles

Agile Values

An Agile Practice

Framework

April 23, 2013



APLN Chicago

18

6 Faces of the “Cube”

Mindset

Principles

Values

Adoption

Practic

es

Scal

ing

April 23, 2013



APLN Chicago

19

• The Agile Mindset• 4 Agile Values• 6x2 Agile Principles• 6 Agile Practice Areas• 6 Stages of Agile Adoption/Evolution• 6 Levels of Agile Scaling

The Agile Practice Framework

April 23, 2013



APLN Chicago

20

Agile is a mindset• Defined by values• Guided by principles• Manifested through many different practices

―Ahmed Sidky

The “Agile” mindset

April 23, 2013



APLN Chicago

21

Values, Principles & Practices

Values

Practices

Principles

Values bring purpose to practices.Practices bring accountability to values.Principles bridge values and practices by guiding behavior.

―Kent Beck, Extreme Programming Explained (2nd edition)

http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658

April 23, 2013



APLN Chicago

22

“Practices by themselves are barren. Unless given purpose by values, they become rote.” —Kent Beck, Extreme Programming Explained (2nd edition)

“Is it better to spend your time understanding principles or studying practices? We observe that the best results come from combining the two approaches.

Copying practices without understanding the underlying principles has a long history of mediocre results.” —Mary & Tom Poppendieck, Implementing Lean Software Development,

Chapter 2 – Principles

Which comes first?

http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658

http://www.poppendieck.com/ilsd.htm

http://www.infoq.com/resource/articles/poppendieck-implementing-lean/en/resources/poppendieck_ch02.pdf

April 23, 2013



APLN Chicago

23

The Agile Manifesto establishes a set of four values that are people-centric and results-driven:

while there is value in the items on the right, we value the items on the left more.

— The Manifesto for Agile Software Development,The Agile Alliance, February 2001, www.agilemanifesto.org

Agile Values (from the Agile Manifesto)

Individuals &

InteractionsProcesses

& Tools

Working Software

Comprehensive

Documentation

Responding to change

Following a plan

Customer Collaboratio

nContract

Negotiation

over

over

over

over

http://www.agilemanifesto.org/

April 23, 2013



APLN Chicago

24

Agile Principles are Guiding Themes

Continuous Technical Excellenceand Simplicity is Essential

Align, Support & Trust …Self-Organizing Teams

Collaborate Daily Across Functions and

Convey Information via Conversation

Deliver Working Software Frequently

at a Sustainable Pace

Welcome Change – Reflect and Adapt

Continuous Delivery of Customer-Value

and Working Software Defines Progress

April 23, 2013



APLN Chicago

25

Values and Principles

Align, Support &

Trust Self-

Organizing

Teams

Continuous Value thru Working Software

Welcome Change -- Reflect and

Adapt

Deliv

er

Freq

uent

ly a

t

a S

usta

inab

le

Pace

Cont

inuo

us

Sim

plic

ity

& T

echn

ical

Exce

llenc

e

Collaborate Daily

via

Conversation

Responding

to change

Individuals &

Interactions Working

Software

Customer

Collaboration

April 23, 2013



APLN Chicago

26

Grouping Practices into Practice-Areas

• Each of the 10-12 initial agile practices are really several smaller practices put together

• Each one of the smaller (“canonical”) practices is often easier to learn and assimilate

• But the full-list of all the “canonical” practices can be very intimidating!

• Grouping them into practice-areas makes them easier to present, explain, learn and digest

• Use the values and principles as a guide for how to divide into practice-areas

April 23, 2013



APLN Chicago

27

Grouping Values & Principles into …

Individuals &

Interactions

Working Software

Responding to change

Customer Collaborati

on

Continuous Customer-

ValueAlign, Support

& TrustSelf-

Organizing Teams

Continuous Technical

Excellence

Welcome Change

Working Software Defines Progress

Simplicity is Essential

Deliver Frequently

Reflect and Adapt

Collaborate Daily Across

Functions

Convey Information

via Conversation

Sustainable Pace

April 23, 2013



APLN Chicago

28

Project & Program Management

Programming, Design &

Architecture

Testing & Specification

Integration, Build & Release

Collaboration & Leadership

Agile Practice-Areas

Business Analysis & Value Management

April 23, 2013



APLN Chicago

29

Viewing Practices by Practice-Area

• Even for a given practice-area, the full list of practices can still be very daunting.

• Plus some “stepping stone” practices are often necessary to transition to a specific practice.

�̶E.g., being able to build daily (or even weekly) prior to integrating continuously

April 23, 2013



APLN Chicago

30

Practice Area PracticesProject & Program Management

Release Plan, Iteration Plan, Velocity Tracking, Buffer Management, Sprint Goals & PSIs, Iteration Review, Task/Kanban Board, Release Train (ART), etc.

Programming, Design & Architecture

Clean Coding, TDD/BDD, Refactoring, Incremental Design, DDD, Technical Debt Mgmt, Evolutionary Architecture, Architectural Runway, etc.


Team Coaching/Facilitation, Pairing, Standups, Retrospectives, Collective Ownership, Customer Proxy, Definition of DONE, Cross-Functional Teams, etc.


Continuous Integration, Daily (Staged CI) Build, Continuous Inspection, Deployment Pipeline, Continuous Delivery, etc.


Automated Testing, Concurrent Testing, Acceptance Criteria, ATDD, Specification by Example, Test-Driven Requirements, etc.

Business Analysis & Value Mgmt

Agile Product Mgmt, Backlog Mgmt, MVP/MMF, Stories & Spikes, Epics & Themes, Value Streams, WSJF Prioritization, Impact Mapping, Agile UX Design, etc.

Viewing Practices by Practice-Area

April 23, 2013



APLN Chicago

31

Adoption Stages/Milestones

• Still need to breakdown adoption efforts into many smaller milestones

• This breaks-up the long journey of agile adoption and continuous improvement into “baby steps”

• Needed for overall adoption and by practice-area!• Each step/stage represents an important transition

to a higher-level of skill mastery, and understanding• Identifies the important stages where teams often

get stuck and don’t progress further (or regress)• Teams can strive for the next attainable near-term

milestone without losing sight of desired destination

April 23, 2013



APLN Chicago

32

# Stage Name Skill Level Expected Results / Improvement

0. Regressive Legacy <= 0

1. Exploring Agility Beginner .10X–.25X

2. Emerging Agility Advanced Beginner .25X–1X

3. Principled Agility Intermediate 1X–2X

4. Disciplined Agility Proficiency 2X–4X

5. Transforming Agility

Mastery 4X–10X

6. Transcending Agility Supremacy ???

Stages of Agile Adoption/Evolution

April 23, 2013



APLN Chicago

33

Stages of (Team) Learning & Mastery

for Skill Acquisition/ExecutionStage 1 2 3 4 5

My Proposal Exploring Emerging Principled Disciplined Transformed

Dreyfus Model Novice Advanced Beginner Competent Proficient Expert

Agile Skills Project

Questioning Learning Practicing Journeying Mastering / Contributing

ThoughtWorks* Neutral / Chaotic Collaborative Operating Adapting Innovating

AgileFluency One Star (Focus on Value) Two Star (Deliver Value)

Three Star (Optimize Value)

Four Star (Optimize for

Systems)

Sidky/SAMI* Collaborative Evolutionary Integrated Adapting Encompassing

ICAgile Model Associate/Apprentice Professional Expert Master

Shu-Ha-Ri Shu Ha Ri

http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

http://www.agileskillsproject.org/skill-levels


http://martinfowler.com/articles/agileFluency.html

http://icagile.com/ExploretheRoadmap.html


April 23, 2013



APLN Chicago

34


• 0: Big-Bang Integration• 1: Incremental Integration• 2: Daily Build• 3: Continuous Integration• 4: Continuous (Quality) Inspection• 5: Continuous Delivery• 6: Continuous Feedback

Incremental Integration

Big Bang Integration

Daily (CM) Build

Continuous Integration

Continuous Inspection

Continuous Delivery

Regressive Exploring Emerging Principled Disciplined Transformed

April 23, 2013



APLN Chicago

35

Stages of Mastery by Skill-set


Baseline for Improvement

.1X –.25X Improvement

.25X–1X Improvement

1X-2X Improvement

2X-4X Improvement

4X-10X Improvement

Project Mgmt Predictive Control

Scrummerfall

Incremental

Water-Scrum-Fall

Iterative & Increment

alAdaptive &

Evolutionary

Design & Architecture BDUF Clean

Coding

“Just Enough, Just-in-Time”

Validated Learning

Test-First &

Refactoring

Supple & Sustainable


Self-Serving

Self -Motivating

Self-Awareness

Self-Reliant

Self-Disciplined

Self- Organizing

Integration, Build, Release

“Big Bang” Integration

Incremental

IntegrationDaily Build



Continuous Delivery


End-of-phase

Manual Testing

Incremental Test-

Automation

Automated Integration

-Testing

Automated Regression

- Testing

Concurrent Acceptance-Testing

Continuous ATDD

BA & Value Mgmt

April 23, 2013



APLN Chicago

36

April 23, 2013



APLN Chicago

37

# Name of Level Scope of Level

0. Individual personal

1. Team interpersonal – across people2. Project/

Featureacross places/sites and phases/functions

3. Product-Line across product-lines and their projects/features

4. Program across products & projects for a system/solution

5. Portfolio across systems/solutions and their programs

6. Enterprise across businesses, markets, and their portfolios

Levels of Agile Scaling

April 23, 2013



APLN Chicago

38

Exploring Emerging Principled Disciplined Transformed

Team

Project /

Feature

Product-Line

Program

Portfolio

Agile Practice Scaling

April 23, 2013



APLN Chicago

39

An Agile Framewor

kAg

ile S

calin

g

Agile Adoption

Agile Results

Agile Practices

Agile Principles

Agile Values

April 23, 2013



APLN Chicago

40

Proj

ect &

Pr

ogra

m

Mgm

t

Collaboration &

Leadership

Programm

in

g, Design &

Architecture

Testing &

Specificatio

n

Inte

grat

ion,

Build

/Rel

eas

e

Business Analysis &

Value MgmtAlign, Support &

Trust Self-

Organizing Teams

Continuous Value

thru Working Software

Welcome Change -- Reflect and

Adapt

Deliv

er

Freq

uent

ly a

t

a Su

stai

nabl

e Pa

ce

Cont

inuo

us

Sim

plic

ity

& Te

chni

cal

Exce

llenc

e

Collaborate Daily

via Conversation

Responding

to change

Individuals &

Interactions Working

Software

Customer

Collaborati

on

Exploring Emerging Principled Disciplined Transformed

An Agile Framewor

kPr

oduc

t-Lin

ePr

ogra

mPo

rtfol

ioTe

amPr

ojec

t/Fe

atur

e

April 23, 2013



APLN Chicago

41

Thank You!

Mahalo

Xie xieYum boticSalamatKhawn khun

Spacibo

Arigato

Juspajaraña

Danke

April 23, 2013



APLN Chicago

42

References• A Middle-management Sandwich,

http://jaaksi.blogspot.com/2007/06/middle-management-sandwich.html • Doing Agile versus Being Agile

Doing agile isn’t the same as being agile, Bob Hartman, http://www.slideshare.net/lazygolfer/doing-agile-isnt-the-same-as-being-agile

Don’t just do agile! Be agile. by Adrian Cho, https://www.ibm.com/developerworks/community/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/dont-just-do-agile-be-agile

Be Agile! Don’t just do agile. http://blogs.captechconsulting.com/blog/carl-alvano/be-agile-dont-just-do-agile Stop doing Agile! Start being Agile!, Jim Highsmith, http://www.youtube.com/watch?v=cZsB8-7KI3o

• Disciplined Agile Delivery, www.disciplinedagiledelivery.com • Scaled Agile Framework, scaledagileframework.com • Distributed Scrum, www.distributedscrum.com • Enterprise Agile Software Delivery, http://www.amazon.com/dp/0321803019 • Practical Approach to Large-Scale Agile Development

http://www.amazon.com/dp/0321821726 http://www.infoq.com/articles/practical-large-scale-agile http://www.agileleadershipnetwork.org/wp-content/uploads/2012/12/Young-LargeScaleAgielDevelop

ment-2012-01-20.pdf

• James Shore on Large-Scale Agile, http://www.jamesshore.com/Blog/Large-Scale-Agile.html

http://jaaksi.blogspot.com/2007/06/middle-management-sandwich.html

http://www.slideshare.net/lazygolfer/doing-agile-isnt-the-same-as-being-agile

https://www.ibm.com/developerworks/community/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/dont-just-do-agile-be-agile

https://www.ibm.com/developerworks/community/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/dont-just-do-agile-be-agile

http://blogs.captechconsulting.com/blog/carl-alvano/be-agile-dont-just-do-agile

http://www.youtube.com/watch?v=cZsB8-7KI3o

http://www.disciplinedagiledelivery.com/

http://scaledagileframework.com/

http://www.distributedscrum.com/



http://www.infoq.com/articles/practical-large-scale-agile

http://www.agileleadershipnetwork.org/wp-content/uploads/2012/12/Young-LargeScaleAgielDevelopment-2012-01-20.pdf

http://www.agileleadershipnetwork.org/wp-content/uploads/2012/12/Young-LargeScaleAgielDevelopment-2012-01-20.pdf

http://www.jamesshore.com/Blog/Large-Scale-Agile.html

April 23, 2013



APLN Chicago

43

References [continued]

• Agile is a mindset, http://www.santeon.com/images/pdf/Intro2Agile.pdf • Models of Learning and Mastery:

http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition http://www.agileskillsproject.org/skill-levels http://www.thoughtworks.com/sites/www.thoughtworks.com/files/files/AgileMadeUsBetter.pdf http://martinfowler.com/articles/agileFluency.html http://agile2007.agilealliance.org/downloads/presentations/AgileAdoption_489.pdf http://scholar.lib.vt.edu/theses/available/etd-05252007-110748/unrestricted/asidky_Dissertation.pdf http://icagile.com/ExploretheRoadmap.html http://martinfowler.com/bliki/ShuHaRi.html http://alistair.cockburn.us/Shu+Ha+Ri

• Continuous Inspection: http://www.ibm.com/developerworks/library/j-ap08016/ http://www.sonarqube.org/continuous-inspection-practice-emerges-with-sonar/

• Continuous Delivery, http://www.continuousdelivery.com/ • Continuous Feedback, http://www.infoq.com/news/2013/07/reimagining-alm [updated 12-July-2013]

http://www.santeon.com/images/pdf/Intro2Agile.pdf

http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition


http://www.thoughtworks.com/sites/www.thoughtworks.com/files/files/AgileMadeUsBetter.pdf

http://martinfowler.com/articles/agileFluency.html

http://agile2007.agilealliance.org/downloads/presentations/AgileAdoption_489.pdf

http://scholar.lib.vt.edu/theses/available/etd-05252007-110748/unrestricted/asidky_Dissertation.pdf


http://martinfowler.com/bliki/ShuHaRi.html

http://alistair.cockburn.us/Shu+Ha+Ri

http://www.ibm.com/developerworks/library/j-ap08016/

http://www.sonarqube.org/continuous-inspection-practice-emerges-with-sonar/

http://www.continuousdelivery.com/

http://www.infoq.com/news/2013/07/reimagining-alm

BACKUP Slides

Supplementary material and work-in-progress

April 23, 2013



APLN Chicago What is Agile Software Development?

“An iterative and incremental (evolutionary) approach to software development- performed in a highly collaborative manner- by self-organizing teams with "just enough"

ceremony- producing high quality software in a cost effective

and timely manner- to meet the changing needs of its stakeholders.”

— Scott Ambler, IBM Practice Leader, Agile Development

“Ultimately, Agility is about:- Embracing change rather than attempting to resist

it- Focus on talent and skills of individuals and

teams.”— James Highsmith, Cutter Consortium

April 23, 2013



APLN Chicago

46

Importance of Technical Practices

The defining characteristic of software is that it is soft. • The easier software is to change, the easier it is to achieve

any of its other required characteristics. • Both architectural integrity and process effectiveness will

drive the cost of change. Therefore, agility is not solely an attribute of a process.

It is equally, if not more, an attribute of good design. • When architectures are resilient and platforms support

change automation and measurement, • then projects can optimize their resource investments …

and steer toward better outcomes for all stakeholders.— Walker Royce, Measuring Progress and Quality Honestly

http://walkerroyce.com/blog/coaching/measuring-progress-and-quality-honestly/

April 23, 2013



APLN Chicago

47

Programming, Design & Architecture

• 0: BDUF• 1: Clean Coding• 2: Incremental Design (“Just Enough, Just-In-Time”)• 3: Validated Learning (Automated Unit-Testing)• 4: Emergent Design (Test-First & Refactoring)• 5: Supple Design• 6: Sustainable, Evolutionary Architecture

Clean CodingBDUF “Just

Enough”Validated Learning

Test-First & Refactoring

Supple & Sustainable


April 23, 2013



APLN Chicago

48

Project & Program Management

• 0: Conformance to Plan (Predict & Control)• 1: Scrummerfall (Timeboxed with velocity & burn-up/down)• 2: Incremental (Including Two-Level Planning)• 3: Water-Scrum-Fall (Up-front reqts/arch with test-phases)• 4: Iterative & Incremental ()• 5: Adaptive & Evolutionary (Scrum & Kanban)• 6: Scrumban/Kanban & Lean (?)

ScrummerfallPredictive Control Incremental Water-

Scrum-FallIterative &

IncrementalAdaptive &

Evolutionary


April 23, 2013



APLN Chicago

49

• Cadence• Flow• Pull• Visibility & Transparency• Seeing WIP & Waste• Measuring Feedback & Cycle-time

April 23, 2013



APLN Chicago

50

Team Leadership & Collaboration

• 0: Self-Serving (Command & Control)• 1: Self-Motivating (Accepting Responsibility)• 2: Self-Awareness (Empathy & Openness)• 3: Self-Reliant (Trusting, Attentive & Conflict Resolution)• 4: Self-Discipline (Committed & Accountable)• 5: Self-Organizing (Reflective & Responsive)• 6: Self-Renewing (Reinvention of self)

Self Motivated

Self Serving

Self Aware

Self Reliant

Self Discipline

Self Organizing


April 23, 2013



APLN Chicago

51


"Big Bang“ Integration

Incremental Integration

Daily Build



Continuous Delivery

Regressive Exploring (.1X –.25X)

Emerging (.25X–1X)

Principled (1X-2X)

Disciplined (2X-4X)

Transformed(4X-10X)

Building

Integrating

Environment/ Staging

Testing

Reporting

Collaborating

April 23, 2013



APLN Chicago

52

Disciplined Agile Delivery

Scott Ambler & Mark Lines, Disciplined Agile Delivery

http://disciplinedagiledelivery.com/


April 23, 2013



APLN Chicago

53

Disciplined Agile Delivery




April 23, 2013



APLN Chicago

54

1. Focus (on Value)2. Fast (at creating and responding to change)3. Flexible (in adopting and adapting to changes)4. Frequent5. Flow6. Feedback

• Value == Focus on value• Value-Stream == Fast … Across the Value-Stream• Flow• Pull == Feedback?

6 F’s

April 23, 2013



APLN Chicago

55

Self OrganizationSelf

DisciplineSelf Awareness

Foundations of Agile Teaming




April 23, 2013



APLN Chicago

56

1. Absence of Trust2. Fear of Conflict3. Lack of Commitment4. Avoidance of Responsibility5. Inattention to Results

Patrick Lencioni, The Five Dysfunctions of a Team, http://www.tablegroup.com/dysfunctions/

5 dysfunctions of a Team

http://www.tablegroup.com/dysfunctions/

April 23, 2013



APLN Chicago

57

A group possesses a self-organizing capability when it exhibits three conditions

1. Autonomy2. Self-transcendence3. Cross-fertilization

http://hbr.org/1986/01/the-new-new-product-development-game/

Elements of Self-Organization from Nonaka and Takeuchi

http://hbr.org/1986/01/the-new-new-product-development-game/%E2%80%8E

April 23, 2013



APLN Chicago Levels of Learning & Feedback Loops

Results

Actions

Assumptions

Context

Single-Loop Learning(Information: Following the Process)

Double-Loop Learning (Reframing: Changing the Process)

Triple-Loop Learning(Transformational: Changing the Culture)

Are we doing things right?

Are we doing the right things?

How do we decide what is right?

April 23, 2013



APLN Chicago

Types of ComplexityComplexity Low HighDynamicFocus is on various parts or the whole system?

Cause and effect are close together in space and time.Solutions can be found by testing and fixing one part at a time.

Cause and effect are far apart in space and time.Solution can be found only when situation is understood systemically, taking account of the interrelationships among the parts and the functioning of the system as whole.

GenerativeSolutions are planned or emergent?

Future is familiar and predictable.

Solutions from the past or other places can be repeated or replicated.

Future is unfamiliar and unpredictable.

Solutions cannot be calculated in advance based on what has worked in the past. Emergent solutions have to worked out as situations unfold.

SocialSolutions come from leaders or from participants?

People involved have common assumptions, values, rationales and objectives.

A leader or expert can propose a solution with which everyone agrees.

People involved look at things very differently.Solutions cannot be given by authorities; the people involved must participate in creating and implementing solutions.

April 23, 2013



APLN Chicago

Cynefin Framework

http://upload.wikimedia.org/wikipedia/commons/4/45/Cynefin_framework_Feb_2011.jpeg

April 23, 2013



APLN Chicago Software Development as a Complex System with Adaptive

Control

Acceptance Tests

Influence

Complex Adaptive System

∑

Realized Scope (Working Software)

Perceived Scope

Error = Perceived – Actual Scope

Effort (Knowledge)

feedback

feedforward

April 23, 2013



APLN Chicago Software Development as a Complex System with Adaptive

Control• When demystified, we have what is referred to in Control

Theory as an Optimal Control Problem.• Specifically, management beyond just the application of

people serves as the project initiation document controller within a closed-loop, socio-technical system.

• When one learns about the sub-branch of the General Systems Theory called Control Systems Engineering, it becomes very clear that the true universal that must be in place to yield an optimal delivery is negative feedback at the correct frequency, with adaptive structure and gain scheduling applied as the system's environment changes.

• This was what the folks who articulated the Agile Manifesto and various Agile methods, albeit anecdotally and tacitly, where trying to say.

-- Mark Kennaley, SDLC 3.0: Beyond a Tacit Understanding of Agile (see

http://blogs.pmi.org/blog/voices_on_project_management/2010/11/can-agile-conquer-the-physics.html#comment-55595)

http://blogs.pmi.org/blog/voices_on_project_management/2010/11/can-agile-conquer-the-physics.html

http://blogs.pmi.org/blog/voices_on_project_management/2010/11/can-agile-conquer-the-physics.html

April 23, 2013



APLN Chicago Agility and Rapid Response

Responding quickly and effectively to change is easiest to do when you can minimize the following:– the cost of knowledge-transfer between individuals– the amount of knowledge that must be captured in intermediate

artifacts– the duration of time between making a project decision, and exploring

its results to learn the consequences of implementing that decision“The team can be more effective in responding to change

if it can reduce the elapsed time between making a decision to seeing the consequences of that decision, and reduce the cost of moving information between people.” —James Highsmith

“One of several reasons why agile techniques are so effective is that they reduce the feedback cycle between the generation of an idea (perhaps a requirement or a design strategy) and the realization of that idea. This not only minimizes the risk of misunderstanding, it also reduces the cost of addressing any mistakes.” —Scott Ambler

April 23, 2013



APLN Chicago Requirements for Attaining Agility

In order to be Agile in responding to change, the following are necessary …1. Quick Customer feedback 2. Plans must be quick+easy to change3. Team Communication must be quick+effective4. Artifacts (Specs/Design/Code) must be quick+easy to

change5. Validation must be quick+easy to perform6. Processes must be quick+easy to change

This applies to EACH feedback loop at each level!

Download - An Agile Practice Framework for Scaling Agile Adoption in an Enterprise

Top Related