Relating Agile Development to Agile Operations Rick Dove and Garry Turkington

Transcription

1 Relating Agile Development to Agile Operations Rick Dove and Garry Turkington initiating research into life cycle migration issues within and across system generations an investigation of Response Ability Principles (RAP) and their ability to illuminate agile system issues and enablers Rick Dove, Stevens Institute of Technology CSER 2008, Redondo Beach, CA April 4, 2008 attributed copies permitted 1

2 Engineering of Agile Systems and Enterprises 1/4 of Graduate Certificate in Agile Systems and Enterprise Fundamentals of Analysis, Synthesis, and Performance SDOE 678 Class 1 Agility: Reconfigurable Systems Based on research funded by OSD/DARPA managed by NSF/Navy Purpose: Identify and understand the next competitive paradigm Lehigh University, Agility Forum, and ~1000 people from ~250 organizations

3 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 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 *RAP: Response Ability Principles *ASD: Agile Software Development rick.dove@stevens.edu, attributed copies permitted 3

4 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 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? 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? rick.dove@stevens.edu, attributed copies permitted 4

5 Perceived Effectiveness 100% iteration In-agile system Development Operation Time Delivery life-cycle end attributed copies permitted 5

6 Perceived Effectiveness 100% iteration In-agile system Development Operation Time Delivery Agile system would continue ROI, but does age, and can suffer integrity failure life-cycle end attributed copies permitted 6

7 RAP: Seven Thought-Guiding Frameworks Response requirements categories (4 reactive and 4 proactive elements): Reactive: correction, variation, expansion, reconfiguration Proactive: creation, improvement, migration, modification Response performance metrics (4 elements): Response: cost, time, quality, scope Response-enabling design principles (10 elements): Encapsulation, Compatibility, Reusability, Redundancy/Diversity, Scalability, Distributed, Loose, Deferred Commitment, Self-Organizing, Evolving Standards Design quality principles (3 elements): Requisite 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-configuration Module Evolution, Infrastructure Evolution An architectural conceptual pattern: Drag-and drop modules in a plug-and-play infrastructure rick.dove@stevens.edu, attributed copies permitted 7

8 RAP: Seven Thought-Guiding Frameworks Response requirements categories (4 reactive and 4 proactive elements): Reactive: correction, variation, expansion, reconfiguration Proactive: creation, improvement, migration, modification Response performance metrics (4 elements): Response: cost, time, quality, scope Response-enabling design principles (10 elements): 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, Harmony An overarching architectural philosophy (3 elements): Reusable modules Reconfigurable in a Scalable architecture (RRS) System integrity responsibilities (4 elements): Module Inventory, System Re-configuration Module Evolution, Infrastructure Evolution An architectural conceptual pattern: Drag-and drop modules in a plug-and-play infrastructure rick.dove@stevens.edu, attributed copies permitted 8

9 Proa active Proactive Change Domains Domain Definition and General Issues General Characteristics Creation (and Elimination) Improvement Migration Modification (Add/Sub Capability) Make or eliminate something. Issues are generally involved with the development of something new where nothing was before, or the elimination of something in use. Incremental improvement. Issues are generally involved with competencies and performance factors, and are often the focus of continual, open-ended campaigns. Foreseen, eventual, and fundamental change. Issues are generally associated with changes to supporting infrastructure, or transitions to next generation replacements. Addition or subtraction of unique capability. Issues are generally involved with the inclusion of something unlike anything already present, or the removal of something unique. Proactive changes are generally triggered internally by the application of new knowledge to generate new value. They are still proactive changes even if the values generated are not positive and even if the knowledge applied is not new self initiation is the distinguishing feature here. A proactive change is usually one that has effect rather than mere potential; thus, it is an application of knowledge rather than the invention or possession of unapplied knowledge. Proactive change proficiency is the wellspring of leadership and innovative activity. rick.dove@stevens.edu, attributed copies permitted 9

10 Agile System: Class 1 Reconfigurable Drag-and-Drop Reusable Components Component mix: Who? Component inventory: Who? System assembly: Who? Infrastructure evolution: Who? Plug-and-Play Evolving Active Infrastructure Responsible-Party Designation Examples of Typical Reconfigurable/Scalable System Configurations Plug-and-Play Evolving Passive Infrastructure Rules/Standards/Principles Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc rick.dove@stevens.edu, attributed copies permitted 10

11 Agile System: Class 2 Reconfiguring Drag-and-Drop Reusable Components Component mix: What? Component inventory: What? System assembly: What? Infrastructure evolution: What? Plug-and-Play Evolving Active Infrastructure Systemic Regulation Examples of Typical Reconfigurable/Scalable System Configurations Plug-and-Play Evolving Passive Infrastructure Rules/Standards/Principles Variety/Time/Maturity/Range/Increments/Migrations/Evolutions/etc rick.dove@stevens.edu, attributed copies permitted 11

12 4 Integrity Responsibility Elements The 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, user representatives intimate with next stage feature development needs, etc), infrastructure 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). rick.dove@stevens.edu, attributed copies permitted 12

13 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 rick.dove@stevens.edu, attributed copies permitted 13

14 Manifesto for Agile Software Development 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 tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice. rick.dove@stevens.edu, attributed copies permitted 14

15 Quote From the Preface Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Rather than shrink from change, Agile organizations harness or embrace change by being better than competitors at responding to changing conditions and by creating change that competitors can t respond to adequately. However, companies must determine what level l of agility they require to remain competitive, Agility is only an advantage relative to competitors a copper mining company doesn t need to be as 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 organizations 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 everything changes all the time, forward motion becomes problematic. Agile organizations understand that balancing on the edge between order and chaos determines success. rick.dove@stevens.edu, attributed copies permitted 15

16 Agile Software Development Process (casting ASD as RAP architecture) Drag & Drop Modules Integrity Management Module maintenance Module inventory System assembly developers team leaders owners/users processes tests codes Infrastructure evolution PM PM PM Active Infrastructure Passive Iteration 1 Iteration 2 Iteration n Emergent requirements Iterative convergence Incremental delivery Self organizing Plug & Play Rules Time rick.dove@stevens.edu, attributed copies permitted 16

17 Agile Software Development Process (casting ASD as RAP architecture) Drag & Drop Modules Integrity Management Module maintenance Module inventory System assembly developers team leaders owners/users processes tests codes Infrastructure evolution PM PM PM Active Infrastructure Passive Iteration 1 Iteration 2 Iteration n Emergent requirements Iterative convergence Incremental delivery Self organizing Plug & Play Rules Time rick.dove@stevens.edu, attributed copies permitted 17

18 Agile Software Development Process Q1: Can domain dependent ASD concepts be cast as domain independent RAP architecture? = Yes Drag & Drop Modules Integrity Management Module maintenance Module inventory System assembly developers team leaders owners/users processes tests codes Infrastructure evolution PM PM PM Active Infrastructure Passive Iteration 1 Iteration 2 Iteration n Emergent requirements Iterative convergence Incremental delivery Self organizing Plug & Play Rules Time rick.dove@stevens.edu, attributed copies permitted 18

19 Agile Development-thru-Operations Process (moving responsibilities to operating personnel) Drag & Drop Modules Integrity Management Module maintenance Module inventory System assembly developers team leaders owners/users processes tests codes Infrastructure evolution PM PM PM PM Active Infrastructure Passive Development Migration Operation Emergent requirements Iterative convergence Incremental delivery Self organizing Plug & Play Rules Time attributed copies permitted 19

20 Agile Development-thru-Operations Process Q2: Could ASD cast as RAP architecture help reveal useful values and concepts? Stability of architecture t and perplexity of choice are two problems that t may be mitigated with this RAP view. Drag & Drop Modules Integrity Management Module maintenance Module inventory System assembly developers team leaders owners/users processes tests codes Infrastructure evolution PM PM PM PM Active Infrastructure Passive Development Migration Operation Emergent requirements Iterative convergence Incremental delivery Self organizing Plug & Play Rules Time rick.dove@stevens.edu, attributed copies permitted 20

21 Q3: Could ASD cast as RAP architecture provide a migration path for extending development-phase agility into the operational phase? Nothing 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. ty rick.dove@stevens.edu, attributed copies permitted 21

22 Encapsulated Implementation Process Silterra Semiconductor Fabrication Facility, circa 2000 actual example Develop Develop Manage Conduct Architecture Business Rules Outsourced Testing and and Design and Specs Development User Training 3-Phases ssa 120 days Prog. Mgr bsa bsa bsa 60 days Proj. Mgr bsa bsa Days Days Template V V 2 V V bsa V 2 bsa V IT V 3 IT V 3 Alpha ssa ssa bsa bsa bsa.. bsa IT.. IT bsa V 2 V 2 V 3 V 3 Beta - Designed to Accommodate Requirements Evolution - bsa: business system analyst ssa: strategic system analyst V n : vendor rick.dove@stevens.edu, attributed copies permitted 22

23 Effective Predictability this approach has worked ERP on time, below budget, on spec 3 months: functional ERP "best practice" (Phase 1) 3 months later: preferred business processes (Phase 2) 3 months later: refined business processes (Phase 3) Wish Typical Imp Actual Imp ERP in 12 mos total mos 12 1,2 75% of license budget % 75% $10 Million (5 + 5) $15-25 Million $9 Million HRM in 6 mos mos 5 mos rick.dove@stevens.edu, attributed copies permitted 23

24 Concluding Remarks RAP includes a design ethos that a good system satisfies three quality principles: i Requisite it 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 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 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 e progress, as the goals keep changing. g The RAP view depicted here provides a solid unchanging basis to the ASD processes 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. rick.dove@stevens.edu, attributed copies permitted 24

25 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 the operational phase. Realizing 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 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 p that provide reasons for believing ROI will occur. 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. rick.dove@stevens.edu, attributed copies permitted 25

26 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 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 the flexibility side of the definition and rigor focuses on the structured side. We suggest the focus is a temporary artifact act of introducing ASD into a plan-driven world, and that ASD as espoused by its leaders is extremely rigorous. It is time for ASD 2.0 rick.dove@stevens.edu, attributed copies permitted 26

27 CSER Paper (April 2008) Perceived Effectiveness 100% In-agile system Development Operation Time Delivery life-cycle end Agile system would continue ROI, but does age, and can suffer strategy-lapse integrity failure Perceived Effectiveness 100% GLOGIFT Paper (July 2008) Module Mix Modifications Infrastructure Migration agile system Development Gen 1 Operation Time Delivery Gen 2 Operation rick.dove@stevens.edu, attributed copies permitted 27

28 Hi-Fi Migrates to 2 nd Gen Home Entertainment Systems Drag & Drop Components Integrity Management Component Mix: amplifiers speakers Mfgrs signal tuners playback units (tape, CD, DVD) ) video displays (TV, computer) content sources (TIVO,P2P) Component inventory: Stores System assembly: User/Owner Infrastructure evolution: Industry Assoc Active Infrastructure Passive Audio tape Video media Net in/out Physical connection Analog interconnect Power Plug & Play Standards roughly Video/Surround Digital/Internet 50s 90s 00s rick.dove@stevens.edu, attributed copies permitted 28

29 Internet Protocol Migration Drag & Drop Components Integrity Management Component Mix: routers switches DNS Servers Vendor Community filters (eg IDS, Firewall) appliances (eg, xml) end points, NICs, NOMs Component inventory: Vendor Community System assembly: Subnet Owners Infrastructure evolution: IETF Active Infrastructure Passive NCP era IPv4 era IPv6 era NCP Wire standards Plug & Play Standards rough operational start TCP/IPv4 Wireless stds Optical stds IPv6 60s/ 60s 80s/ 90s 00/ 10s attributed copies permitted 29

30 Class 1 Agile Systems are Reconfigurable atyrosado.com/ Naty Rosado, Useful Metaphors: Plug-and-Play Drag-and-Drop Class 2 Agile Systems are Reconfiguring ls, html?l=w&p=6 Helen Well Useful Metaphors: Ecologies and Evolution rick.dove@stevens.edu, attributed copies permitted 30

31 SDOE 675 SDOE 678 SDOE 679 SDOE Thinking 678 Engineering 679 Architecting 683 Designing attributed copies permitted 31