Richard Turner Stevens Institute

Transcription

1 RT-35/35A Agile-Lean Systems Engineering: Kanban in SE Richard Turner Stevens Institute 5 th Annual SERC Research Review Mar 19, 2014 USC

2 Heilmeier Criteria 1. What are you trying to do? Articulate your objectives using absolutely no jargon. 2. How is it done today, and what are the limits of current practice? 3. What's new in your approach and why do you think it will be successful? 4. Who cares? If you're successful, what difference will it make? 5. What are the risks and the payoffs? 6. How much will it cost? How long will it take? 7. What are the midterm and final "exams" to check for success? SSRR

3 Basic Information RT35/35A [H-1, H-2] Starting question: How can we replace IMSs? Researchers: Richard Turner: Stevens; Boehm, Lane, Ingold: USC; Madachy: NPS; Industry Working Group Task start: August 2011 Deliverables: 4 Conference Presentations: 13 Papers Published: 8 (all to refereed conferences or journals) Workshops: 4 SSRR

4 Traditional systems engineering assumptions [H-2] Requirements are predefined and generally stable Resources and technologies are predictable and stable Values remain stable There is sufficient time to complete the work Reductionism is the best way to approach large problems SSRR

5 The Results [H-2] The V model Focus on plans/schedules rather than value and solutions Focus on requirement precision and coherence (if not accuracy) Change (and the customer who wants it)seen as the enemy Reductionism and deep engineering specialization Local process & design optimization SSRR

6 More Results [H-2] SE Disengaged from SwE Poor management visibility into relationships between products, requirements, architecture, change impacts Operational environment overwhelms traditional governance methods SSRR

7 System contexts have multiplied Change in needs and solution technologies has accelerated Requirements are less tangible, evolving, and often emergent Systems are complex and constantly adapting Actual terrain has changed, we need new maps, tools and techniques The World is Changed SSRR

8 The venerable PMI has (finally) adapted 5 th Edition of the PMBOK Guide provides for both predictive (plan-driven) and adaptive (agile) project lifecycles! A new PMI/IEEE-CS SW Extension is now available that deals specifically with software management issues Need Proof Of The Change? SSRR

9 Values Agile: Flexibility, Evidence Lean: Value, Flow Fundamental things apply Principles Stakeholder Valuebased Evolution Incremental Commitment and Accountability Concurrent Multidiscipline Engineering Evidence- and Riskbased Decisions Adapted from The Incremental Commitment Spiral Model Boehm, Lane, Koolmanojwong, and Turner (2014) SSRR

10 Key takeaways of the research so far [H-2] One definition of systems engineering: The Right People, the Right Information, at the Right Time, Making Good Decisions Understand Real Capacity for Work Continuously Value Work Holistically Use Service Model To Ensure Communications ShareValue, Capacity and Status Information Across the Enterprise SSRR

11 Some Answers? There is still no Silver Bullet ICSM principles Service orientation is promising Trust is a key ingredient and often difficult to find Maybe is better than Hell, No! Executive/Management patience, not abdication Believing Creativity and Collaborationcan be better than Command & Control Santayana was half right it s only the mistakes that you don t want to repeat, not the successes SSRR

12 Caution! Specific Target Environment for the SERC Research Under Way [H-4] Systems engineering where rapid response software development projects incrementally evolve capabilities of existing systems or SOSs That does NOT, however, preclude it from being applicable outside that target; of course it doesn t guarantee it, either. SSRR

13 Sticking Points [H-5] Large-scale budgeting and estimation Long-lead items Operational systems of independently evolving systems Highly regulated domains (e.g. defense, financial, health) Command and control environments (low trust, bureaucratic) SSRR

14 Better visibilityand coordinationmanaging multiple concurrent development projects More effective integrationand use of scarce SE resources Increased project and enterprise valuedelivered earlier More flexibilitywhile retaining predictability Less blocking of product team tasks waiting for SE response Lower governance overhead Predicted (Desired) Results [H-1] SSRR

15 Agile/Lean Community Connections Industry Working Group David Anderson (David J. Anderson and Associates) Jabe Bloom (The Library Corporation) Hillel Glazer (Entinex) Curtis Hibbs(Boeing) Suzette Johnson (Northrop Grumman) Larry Maccherone(Rally Software) Don Reinertsen(Reinertsen& Associates) David Rico (Boeing) Garry Roedler(Lockheed Martin) Karl Scotland (Rally Software, UK) Alan Shalloway(NetObjectives) Neil Shirk (Lockheed Martin) Neil Siegel (Northrop Grumman) James Sutton (Jubata Group) AFEI-ADAPT INCOSE LSS NDIA PMI SSRR

16 Our Concept [H-3] Pull (kanban) scheduling Value-based selection Limited WIP Classes of Service SE as a Service Scarce resource-driven Collaborative/Negotiated Integrated work and data flow Information radiators at all levels A Multi-level Network of Kanban-based Scheduling Systems Dash Execu ve/stakeholder Management (Customer) SLA establishment and monitoring Strategic planning Capability priori za on Dash Capability Engineering Analyze needs and alterna ves Refine capabili es Develop requirements Allocate requirements Form cross organiza onal teams Cross-product and specialty engineering Validate and fully enable capabili es KSS KSS Needs Backlog* Work Flow Visibility * All organiza ons can contribute to the Needs Backlog Dash Dash KSS KSS Product/Domain Engineering KSS KSS KSS Users User Support Individual Product Team Pharmacy Domain Team Network Domain Team Customer rela ons Ini al Triage Product SE Iden fy SW Features Allocate features to SWDT Integrate features into requirements SW Development Team SSRR

17 A Generic Kanban-based Scheduling System Upstream Customers Work (Backlog ) Ready Queue (Limit=6) Ac vity (WIP Limit=8, Resources=4) Completed Work NCoS, (WL=5) Work Flow Ex Ex 1 2 SCoS, WL=1 (included In ac vity WL) ECoS, WL=1, (extends ac vity WL if necessary) WIP Ex Work Item wai ng for selec on Normal Class of Service Work Item (NCOS) Special Class of Service Work Item (SCOS) Expedite Class of Service Work Item (ECOS) 1 Resource (Individually numbered) SSRR

18 Examples of Networked KSSs SSRR

19 SE activities need to be defined and available for projects and the system owners to select for the ready queue The concept of services fits the need to encapsulate work, and provide a common value stream among project development personnel, SE, and the enterprise Rationale for SE as a Service SSRR

20 Value/Priority in Servicing Maintaining prioritization across stakeholders is resource-intensive Kanban forces stakeholders to agree about next item in queue Stakeholders include customers/users, projects, executive management, and higher level systems engineering management Value functions balance local and SoS-wide priorities SSRR

21 Custom software SoSconstituent systems include patient management, pharmacy, laboratory, radiology, and telemetry Systems share a single database for all patients and personnel related to a given health care site Interfaces to other health care systems are maintained. Key overarching requirements are to ensure patient-safety and to protect patient information Healthcare SoS SSRR

22 Information/Work Structure MC 1 MC 2 MC 3 R 1 R 2 R 3 R 4 R 5 R 6 R 7 R 8 Product 1 Product 2 Product 3 Product 4 SSRR

23 Proposed KSS Network Structure Dash Execu ve/stakeholder Management (Customer) SLA establishment and monitoring Strategic planning Capability priori za on KSS Dash Product/Domain Engineering KSS Users User Support Customer rela ons Ini al Triage Dash Capability Engineering Analyze needs and alterna ves Refine capabili es Develop requirements Allocate requirements Form cross organiza onal teams Cross-product and specialty engineering Validate and fully enable capabili es KSS Needs Backlog* Dash KSS KSS Individual Product Team Product SE Iden fy SW Features Allocate features to SWDT Integrate features into requirements SW Development Team KSS Pharmacy Domain Team Work Flow Visibility * All organiza ons can contribute to the Needs Backlog KSS Network Domain Team SSRR

24 Classes of Service SSRR

25 Flow among and between KSSs SSRR

26 New Capabilities Interface to a new health insurance company requires capture of additional information about patients, diagnoses, and physician orders Integrate and analyze information from multiple patient telemetry systems to improve diagnostic capabilities COTS option: Identify and evaluate any COTS data fusion products that apply to the telemetry devices, select the best one, then integrate it into the enterprise If no COTS available for all telemetry systems, two options: o Change non-compatible telemetry systems for more compatible ones and use a COTS product to integrate/analyze the desired information o Develop a custom application to do the integration and analysis. SSRR

27 Upgrade and Enhancement User response improvement system response time is unacceptably slow and is potentially putting patient safety at risk evaluate alternatives for improving the user response time and recommend one or more for funding. Periodic upgrade of pharmacy formulary information Data on formularies and drug interactions updated quarterly (subscription service) Updates analyzed against existing DB structures, any necessary updates to the data structures made, data structure updates tested and deployed, then populated with updated data SSRR

28 Normal Capability Development SSRR

29 Critical Issue: Interoperability Problem Feature to electronically send patient records to an external health care system was implemented, fully tested and seemed to function well during the first 30 days after deployment Late one night, a physician noticed that an important entry by external health care system not entered properly in the time log SSRR

30 Critical Task Operation SSRR

31 Results Aligned, unified view of work in progress and status of work Predictability through measures easily SPC d and projected Value-based scheduling considers all priorities Better use of C/SE resources; better servicing of team SE needs Unlinks planning, scheduling, integration, and deployment cadences Enhances decision making Supports continuous improvement Provides for right conversations, right people, right time SSRR

32 Next Steps [H-6, H-7] Proposal in coordination Continue KSSN Research o Develop additional mechanisms to support value-based scheduling, SE as a service, etc. Better define characteristics for value elements and value functions o Refine simulations to include new mechanisms o Investigate use of agent-based simulation to model human behavior of kanbankanban coordination o Build transition package o Support lean and agile enablers INCOSE, NDIA, SEI and other organizations have working groups on agile-lean SE Participate in and leverage working groups, conferences and Symposia Industry Pilots o Build collaborations and infrastructure for in vivo KSSN piloting Use FedGovOps announcement and requirements to eliminate conflict of interest issues o Conduct pilots SSRR

33 Questions? SSRR

34 References 1. Boehm, Barry and Turner, Richard (2004).Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison Wesley. 2. LarmanC. and Vodde, B. (2009). Scaling Lean & Agile Development.Boston, MA: Addison Wesley. 3. Poppendiek, Mary. (2007).Implementing Lean Software Development.Boston, MA: Addison Wesley. 4. Turner, Richard and Wade, J. (2011). Lean Systems Engineering within System Design Activities, Proceedings of the 3rd Lean System and Software Conference, May 2-6, 2011, Los Angeles, CA. 5. NDIA-National Defense Industrial Association (2010). Top Systems Engineering Issues In US Defense Industry. Systems Engineering Division Task Group Report, < SystemsEngineering/Documents/Studies/Top%20SE%20Issues%202010%20Report%20v11%20FINAL. pdf>, September, Turner, R. A Lean Approach to Scheduling Systems Engineering Resources, Crosstalk, May/June, Anderson, David. (2010).Kanban: Successful Evolutionary Change for Your Technology Business. Sequim, WA: Blue Hole Press 9. Burrows, Mike. (2010). Kanban in a Nutshell. Blog post. < kanban-in-a-nutshell/>, March, Reinertsen, Donald G. (2010). The Principles of Product Development Flow.Redondo Beach, CA: CeleritasPublishing. 11. Boehm, B. et al. Applying the Incremental Commitment Model to Brownfield Systems Development, Proceedings, CSER 2009, April Boehm, B., and Lane, J., Using the ICSM to Integrate System Acquisition, SE, and Software Engineering, CrossTalk, October 2007, pp Turner, R., J.A. Lane, D. Ingold, R. Madachy, and D Anderson. An event-driven, value-based, pull systems engineering scheduling approach. Systems Conference (SysCon), 2012 IEEE International,. IEEE, Office of the Deputy Under Secretary of Defense for Acquisition and Technology, Systems and Software Engineering (2008). Systems Engineering Guide for Systems of Systems, Version 1.0. Washington, DC: ODUSD(A&T)SSE, SSRR