Relating Agile Development to Agile Operations › Files › PsiDocs › Pap080404Cser2008... · (establishing efficacy and promise of RAP* tools) Agile Enterprise and Agile Software

Relating Agile Development to Agile OperationsRick Dove and Garry Turkington

initiating research into life cycle migration issueswithin and across system generations

an investigation ofan investigation ofResponse Ability Principles (RAP)

and their ability to illuminate agile system issues and enablers

Rick Dove, Stevens Institute of TechnologyCSER 2008, Redondo Beach, CA

April 4 2008

[email protected], attributed copies permitted 1

April 4, 2008

Engineering of Agile Systems and EnterprisesEngineering of Agile Systems and EnterprisesFundamentals of Analysis, Synthesis, and PerformanceFundamentals of Analysis, Synthesis, and Performance

SDOE 678SDOE 6781/4 of Graduate Certificate in Agile Systems and Enterprise

Based on research funded by OSD/DARPA managed by NSF/Navy 1991-1997

Class 1 Agility: Reconfigurable Systems

y g y yPurpose: Identify and understand the next competitive paradigmLehigh University, Agility Forum, and ~1000 people from ~250 organizations

Purpose: Lay a Foundation for Student Project Research(establishing efficacy and promise of RAP* tools)

Agile Enterprise and Agile Software Development (ASD): concepts with considerable exposure in the language.

Agility in the enterprise context – usually refers to system operation.Agility in the software context usually refers to system developmentAgility in the software context – usually refers to system development. Both are concerned with systems that must

deliver satisfaction in an environment of uncertainty and change.

This initial work began with the observation that ASD processes

generally ignore the agility of the resultant system.

The investigation:1) established commonalities across ASD processes 2) cast these common concepts in the domain independent

Response Ability architecture that grew from work at the Agility Forum 3) modeled how this development characterization could be extended into the

operational phase consistent with observed operational agility


operational phase consistent with observed operational agility

*RAP: Response Ability Principles*ASD: Agile Software Development

Observations

ASD is focused on brand-specific procedural gnits & gnats

Many people are trying to reach “accommodation” between CMMI and ASD

CMMI is measured by repeatability of the processCMMI is measured by repeatability of the process

ASD is measured by customer satisfaction

How to migrate toward ASD is a major & critical issue for many

Reality:

Requirements uncertainty on the increase?q y

Deadlines coming sooner?

Systems complexity on the increase?

Management wants plan-driven predictability, needs agile-driven quality?

Govt customers want plan-driven predictability, need agile-driven quality?


PerceivedEffectiveness100%

In-agile systemiteration

DeliveryTime

life-cycle end

OperationDevelopment


PerceivedEffectiveness

Agile system would continue ROI,but does age and can

100%

iteration In-agile system

DeliveryTime

life-cycle end

but does age, and cansuffer integrity failureOperationDevelopment


Response requirements categories (4 reactive and 4 proactive elements):R ti ti i ti i fi ti

RAP: Seven Thought-Guiding Frameworks

Reactive: correction, variation, expansion, reconfigurationProactive: creation, improvement, migration, modification

Response performance metrics (4 elements):Response cost time q alit scopeResponse: cost, time, quality, scope

Response-enabling design principles (10 elements):

Encapsulation Compatibility Reusability Redundancy/Diversity ScalabilityEncapsulation, Compatibility, Reusability, Redundancy/Diversity, Scalability,Distributed, Loose, Deferred Commitment, Self-Organizing, Evolving Standards

Design quality principles (3 elements):Requisite Variety Parsimony HarmonyRequisite Variety, Parsimony, Harmony

An overarching architectural philosophy (3 elements):Reusable modules Reconfigurable in a Scalable architecture (RRS)

System integrity responsibilities (4 elements):Module Inventory, System Re-configurationModule Evolution, Infrastructure Evolution


An architectural conceptual pattern:Drag-and drop modules in a plug-and-play infrastructure

Response requirements categories (4 reactive and 4 proactive elements):R ti ti i ti i fi ti

RAP: Seven Thought-Guiding Frameworks

Reactive: correction, variation, expansion, reconfigurationProactive: creation, improvement, migration, modification

Response performance metrics (4 elements):Response cost time q alit scopeResponse: cost, time, quality, scope

Response-enabling design principles (10 elements):

Encapsulation Compatibility Reusability Redundancy/Diversity Scalability

This paper’s focus

Encapsulation, Compatibility, Reusability, Redundancy/Diversity, Scalability,Distributed, Loose, Deferred Commitment, Self-Organizing, Evolving Standards

Design quality principles (3 elements):Requisite Variety Parsimony HarmonyRequisite Variety, Parsimony, Harmony

An overarching architectural philosophy (3 elements):Reusable modules Reconfigurable in a Scalable architecture (RRS)

System integrity responsibilities (4 elements):Module Inventory, System Re-configurationModule Evolution, Infrastructure Evolution


An architectural conceptual pattern:Drag-and drop modules in a plug-and-play infrastructure

Proactive Change Domains

Domain Definition and General Issues General CharacteristicsDomain Definition and General Issues

Proactive changes are generally triggered internally by the application of new k l d t t

Make or eliminate something. Issues are generally involved with the development of something new where nothing was before or the elimination of

General Characteristics

Creation(and

Elimination) knowledge to generate new value. They are still proactive changes even if the values generated are not positive and

nothing was before, or the elimination of something in use.

Incremental improvement. Issues are generally involved with competencies

Elimination)

activ

e

g peven if the knowledge applied is not new – self initiation is the distinguishing feature here. A proactive change is usually one

g y pand performance factors, and are often the focus of continual, open-ended campaigns.

F t l d f d t l

Improvement

Proa proactive change is usually one

that has effect rather than mere potential; thus, it is an application of knowledge rather than the invention or

Foreseen, eventual, and fundamental change. Issues are generally associated with changes to supporting infrastructure, or transitions to next

ti l t

Migration

than the invention or possession of unapplied knowledge. Proactive change proficiency is the wellspring of l d hi d i ti

generation replacements.Addition or subtraction of unique capability. Issues are generally involved with the inclusion of Modification

(Add/Sub


leadership and innovative activity.

something unlike anything already present, or the removal of something unique.

(Add/Sub Capability)

Agile System: Class 1Reconfigurable

Drag-and-DropReusable

Plug-and-Play Evolving Active Infrastructure

Components

System assembly: Who?

Component mix: Who?Component inventory: Who?

Examples of TypicalReconfigurable/ScalableSystem Configurations

Responsible-Party Designation Infrastructure evolution: Who?System assembly: Who?

System Configurations

Plug-and-Play EvolvingPassive InfrastructureRules/Standards/Principles


Rules/Standards/Principles

Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc

Agile System: Class 2Reconfiguring

Drag-and-DropReusable

Plug-and-Play Evolving Active InfrastructureSystem assembly: What?

Component mix: What?Component inventory: What?

Components

Systemic RegulationInfrastructure evolution: What?System assembly: What?

Examples of TypicalReconfigurable/ScalableSystem Configurations

Plug-and-Play EvolvingPassive InfrastructureRules/Standards/Principles

System Configurations


Rules/Standards/Principles

Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc

4 Integrity Responsibility ElementsThe “active” part of the infrastructure

maintaining sufficient inventory of modules ready for use (development people, team leaders, engagement procedures, reusable code modules, reusable test suites, etc), , , ),

new module addition and upgrade as new capabilities are needed (new developer skills, newly developed code modules, new test suites for new code new procedures as indicated by a changing situation usernew code, new procedures as indicated by a changing situation, user representatives intimate with next stage feature development needs, etc),

infrastructure evolution (improvements to existing rules and standardsinfrastructure evolution (improvements to existing rules and standards, new rules and standards, etc), and

assembly of modules into on-demand system configurations suitable for changing response needs (successive iterations in the development process).


Questions

Q1: Can domain dependent ASD* concepts be cast as domain independent RAP* architecture?

Q2: Could ASD cast as RAP architecture help reveal useful values and concepts?

Q3: Could ASD cast as RAP architecture provide a migration path for extending development-phase agility into the operational phase?

*ASD: Agile Software Development


RAP: Response Ability Principles

Manifesto for Agile Software DevelopmentW i b tt f d l i

http://agilemanifesto.org/

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and toolsIndividuals and interactions over processes and tools Working software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

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

Kent Beck James Grenning Robert C. MartinMike Beedle Jim Highsmith Steve MellorMike Beedle Jim Highsmith Steve Mellor

Arie van Bennekum Andrew Hunt Ken SchwaberAlistair Cockburn Ron Jeffries Jeff SutherlandWard Cunningham Jon Kern Dave Thomas

Martin Fowler Brian Marick


Martin Fowler Brian Marick

© 2001, the above authorsthis declaration may be freely copied in any form,

but only in its entirety through this notice. 14

Agility is the ability to both create and respond to change in order to profit in a

Quote From the Preface

respond to change in order to profit in a turbulent business environment.Rather than shrink from change, Agile organizations harness or embrace change b b i b tt th tit tby being better than competitors at responding to changing conditions and by creating change that competitors can’t respond to adequately. However, companies

t d t i h t l l f ilit thmust determine what level of agility they require to remain competitive, Agility is only an advantage relative to competitors – a copper mining company doesn’t need to be

il bi t h l fias agile as a biotechnology firm.Other aspects of agility are also important: nimbleness or flexibility on the one hand, and balance on the other. Agile gorganizations are nimble (able to change

directions quickly) and flexible (able to see how things that worked last week may not work as well next week). An Agile organization also knows how to balance structure and flexibility If


An Agile organization also knows how to balance structure and flexibility. If everything changes all the time, forward motion becomes problematic. Agile organizations understand that balancing on the edge between order and chaos determines success.

Agile Software Development Process(casting ASD as RAP architecture)

Drag & Drop Modules

developers owners/usersteam leaders processes tests codes

Module maintenance

IntegrityManagement

Infrastructure evolution

System assembly

Module inventory

PM PM PM

Infrastructure

Active

I t l d liIterative convergence

Emergent requirements

Iteration 2 Iteration nIteration 1Passive


Self organizingIncremental delivery

Plug & Play Rules Time

Agile Software Development Process(casting ASD as RAP architecture)

Drag & Drop Modules


Module maintenance

IntegrityManagement


System assembly

Module inventory

PM PM PM

Infrastructure

Active







Agile Software Development ProcessQ1: Can domain dependent ASD concepts

Drag & Drop Modules

p pbe cast as domain independent RAP architecture? = Yes


Module maintenance

IntegrityManagement


System assembly

Module inventory

PM PM PM

Infrastructure

Active







Agile Development-thru-Operations Process(moving responsibilities to operating personnel)

Drag & Drop Modules

Module maintenance

developers owners/usersteam leaders processes tests codesIntegrityManagement

PMPMPMInfrastructure evolution

System assembly

Module inventory

PM

Active

Infrastructure

MigrationDevelopment OperationPassive




TimePlug & Play RulesSelf organizing

Incremental delivery

Agile Development-thru-Operations ProcessQ2: Could ASD cast as RAP architecture help reveal useful values and concepts?St bilit f hit t d l it f h i t bl th t b

Drag & Drop Modules

Stability of architecture and perplexity of choice are two problems that may be mitigated with this RAP view.

Module maintenance

developers owners/usersteam leaders processes tests codesIntegrityManagement

PMPMPMInfrastructure evolution

System assembly

Module inventory

PM

Active

Infrastructure

MigrationDevelopment OperationPassive




TimePlug & Play RulesSelf organizing

Incremental delivery

Q3: Could ASD cast as RAP architecture provide a migration path for extending development-phase agility into the operational phase?

N thi f d t ll h ith d li d l t b b ilt hNothing fundamentally changes with delivery: new modules must be built when new requirements surface, and existing modules must be upgraded when they cease to perform effectively due to requirements change.

It matters not if the modules in question are people with certain skills, code that executes on a computer, tests that verify a new addition doesn’t cripple prior capability, procedures that discipline the system sustainment activity, and so on.

What does change is a lessening of development intensity, and an adjustment in who carries out the responsibilities for maintaining and sustaining system integrity.teg ty


Encapsulated Implementation ProcessSilterra Semiconductor Fabrication Facility, circa 2000

actual example

Develop Develop Manage Conduct

actual example

3-Phases

DevelopArchitectureand Design

DevelopBusiness Rules

and Specs

ManageOutsourced

Development

ConductTesting and

User Training

D D Template

Alpha

V2V2 …….. V3V3 ……..

60 days

Days0-90

91-180

Days60-90

150-180bsa

bsa

bsa120 daysssa

p

Beta……..

……..bsabsa V2V2

……..

……..ITIT V3V3

181-270 240-270

bsa bsa

bsa bsa

Proj.Mgr

Prog.Mgr

bsabsa ITITssassa

D si n d t Acc mm d t R quir m nts Ev luti n

V3V3bsa V2V2bsabsa IT


- Designed to Accommodate Requirements Evolution -

www.parshift.com/Files/PsiDocs/Rkd050324CserPaper.pdf bsa: business system analystssa: strategic system analystVn: vendor

Effective Predictability

this approach has worked

ERP on time, below budget, on spec3 months: functional ERP "best practice" (Phase 1)

this approach has worked

3 months later: preferred business processes (Phase 2)3 months later: refined business processes (Phase 3)

Wish Typical Imp Actual ImpERP in 12 mos total 24-36 mos 121,2ERP in 12 mos total 24 36 mos 12

75% of license budget 200-300% 75%$10 Million (5 + 5) $15-25 Million $9 Million

HRM in 6 mos 12-18 mos 5 mos


www.parshift.com/Files/PsiDocs/Rkd050324CserPaper.pdf

Concluding RemarksRAP includes a design ethos that a “good” system satisfies three quality

i i l R i it V i t P i d Hprinciples: Requisite Variety, Parsimony, and Harmony. • Requisite variety would seem to be the driving force behind ASD: the

development process must be able to respond to requirements as they become evident and as they change – and it must be proactive in discovery, reactive in y g p y,accommodation.

• Parsimony is seen throughout the ASD varieties, especially in minimal documentation, deferring action on “possible” future needs, and “lean” avoidance of anything that doesn’t add immediate valueavoidance of anything that doesn t add immediate value.

• Harmony has been the rub: ASD appears in contradiction with acceptable best management practices as measured by plan-driven values.

Common disharmonious pronouncements: • No stability, as the architecture is vague and subject to whimsical change. • No way to measure progress, as the goals keep changing. o ay to easu e p og ess, as t e goa s eep c a g g

The RAP view depicted here provides a solid unchanging basis to the ASDprocesses that should counter the lack-of-stability perception.


As to the need for visible progress measurement, the core metric can only be the nature and speed of convergence on customer satisfaction – an issue we’ve not addressed, as yet.

The drag-and-drop/plug-and-play reconfigurable patterns depicted here are consistent with actual ASD practice and do not represent additional project cost to realize the long term continuation benefit in theproject cost to realize the long term continuation benefit in the operational phase.

Realizing the benefit is a matter of selection criteria in choosingRealizing the benefit is a matter of selection criteria in choosing appropriate user/owners for development-phase participation.

It is suggested that a strategy for continuing the ASD approach pattern asIt is suggested that a strategy for continuing the ASD approach pattern as depicted here, into operations, will lower the barriers for gaining ASD acceptance.

ROI in the operating phase is a requirement of all systems, whether explicitly recognized in system requirement “shall” statements or not, and savvy management responds to value propositions that provide y g p p p preasons for believing ROI will occur.

At today’s technology pace, a system that cannot incorporate new


At today s technology pace, a system that cannot incorporate new technology or respond to new competitive needs and customer demands becomes a liability, often before ROI is realized.

With Respect…

Boehm and Turner (2004) state on page 1: “Agility is the counterpart of discipline.”

We hold that agility is obtained and (especially) sustained only throughWe hold that agility is obtained and (especially) sustained only through discipline, and is a fleeting competency if that discipline is not vigilantly maintained by the four integrity responsibilities.

Highsmith (2002) states on page xxxi“Agility means balancing between structure and flexibility, so rigor is a vital part of any development process Agility focuses on thea vital part of any development process. Agility focuses on the flexibility side of the definition and rigor focuses on the structured side.”

We suggest the “focus” is a temporary artifact of introducing ASD into a e suggest t e ocus s a te po a y a t act o t oduc g S to aplan-driven world, and that ASD as espoused by its leaders is extremely rigorous.


It is time for ASD 2.0

Perceived

CSER Paper (April 2008)

PerceivedEffectiveness100%

TimeDevelopment

Agile system would continue ROI,but does age, and can suffer

strategy-lapse integrity failure

In-agile system

Operation

DeliveryTime

life-cycle end

GLOGIFT Paper (July 2008)PerceivedEffectiveness100%

InfrastructureMigration

Module MixModifications

p ( y )

agile system


DeliveryTime

Development Gen 2 OperationGen 1 Operation

Hi-Fi Migrates to 2nd Gen Home Entertainment Systems

Drag & Drop Components

amplifiers playback units(tape, CD, DVD) )

speakers video displays(TV, computer)

content sources(TIVO,P2P)

Component Mix:

IntegrityManagement

Mfgrs

signal tuners

Infrastructure evolution:

System assembly:

Component inventory:

Industry Assoc

User/Owner

Stores

Infrastructure

Active

PAnalog interconnect Physical connection

Video media Net in/outAudio tapePassive


Power

Plug & Play Standards‘90s

Video/Surround Digital/Internet

‘50s ‘00sroughly…

Internet Protocol Migration

Drag & Drop Components

routers DNS Serversswitches end points,NICs, NOMs

appliances(eg, xml)

Component Mix:

IntegrityManagement

Vendor Community

filters(eg IDS, Firewall)

Infrastructure evolution:

System assembly:

Component inventory:

IETF

Subnet Owners

Vendor Community

Infrastructure

Active

Wire standards NCP

IPv6eraPassive

TCP/IP 4

IPv4era

NCPera


Plug & Play Standards’80s/’90s

TCP/IPv4

IPv6 ’60s/’60s ’00/’10srough operational start…

Optical stds Wireless stds

Class 1 Agile Systems are Reconfigurableg y g

Useful Metaphors:

atyr

osad

o.co

m/

p

Plug-and-Play – Drag-and-Drop

Nat

y R

osad

o, h

ttp://

na

Class 2 Agile Systems are ReconfiguringClass 2 Agile Systems are Reconfiguring

htm

l?l=

w&

p=6

Useful Metaphors:

Ecologies and Evolution

ls, w

ww

.yes

sy.c

om/a

rtis

ts.h


Hel

en W

ell

SDOE 675 SDOE 678 SDOE 679 SDOE 683

678Engineering

679Architecting

683Designing

675Thinking


Documents

Relating Agile Development to Agile Operations › Files › PsiDocs › Pap080404Cser2008... · (establishing efficacy and promise of RAP* tools) Agile Enterprise and Agile Software