View
213
Download
0
Category
Preview:
Citation preview
RT-35/35A Agile-Lean Systems Engineering:
Kanban in SE
Richard Turner Stevens Institute rturner@stevens.edu
5th Annual SERC Research Review
Mar 19, 2014
USC
www.sercuarc.org
SSRR 2014 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 2014 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 2014 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 2014 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 2014 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 2014 7
The World is Changed
•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
SSRR 2014 8
Need Proof Of The Change?
•The venerable PMI has
(finally) “adapted”
―5th 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
SSRR 2014 9
“Fundamental things apply”
Principles
•Stakeholder Value-based Evolution
•Incremental Commitment and Accountability
•Concurrent Multi-discipline Engineering
•Evidence- and Risk-based Decisions
Adapted from
The Incremental Commitment Spiral Model
Boehm, Lane, Koolmanojwong, and Turner (2014)
Values
•Agile: Flexibility, Evidence
•Lean: Value, Flow
SSRR 2014 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
• Share Value, Capacity and Status Information Across the
Enterprise
SSRR 2014 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 Collaboration can 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 2014 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 2014 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 2014 14
Predicted (Desired) Results [H-1]
• Better visibility and coordination managing multiple concurrent development projects
• More effective integration and use of scarce SE resources
• Increased project and enterprise value delivered earlier
• More flexibility while retaining predictability
• Less blocking of product team tasks waiting for SE response
• Lower governance overhead
SSRR 2014 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 2014 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
Capability Engineering
Individual Product Team
Execu ve/Stakeholder
Management (Customer)
SLA establishment and monitoring
Strategic planning
Capability priori za on
Dash
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
Network Domain Team
Pharmacy Domain Team
Users User Support
���
Product/Domain Engineering
KSS
KSS
Dash
KSS
Customer rela ons
Ini al Triage
Product SE
Iden fy SW Features
Allocate features to SWDT
Integrate features into requirements
SW Development Team
Dash
KSS
KSS
KSS
Dash
Work Flow
Visibility
KSS
Needs
Backlog*
* All organiza ons can contribute to the Needs Backlog
A Multi-level Network of
Kanban-based Scheduling Systems
SSRR 2014 17
A Generic Kanban-based Scheduling System
Ac vity
ECoS, WL=1, (extends
ac vity WL if necessary)
SCoS, WL=1 (included
In ac vity WL)
Ready Queue
Work
Flow
Normal Class of Service Work Item (NCOS)
WIP
Ex
Completed
Work
Special Class of Service Work Item (SCOS)
Ex
(WIP Limit=8, Resources=4)
1 Resource (Individually numbered)
1
2
3
4
1
NCoS, (WL=5)
Ex Expedite Class of Service Work Item (ECOS)
(Limit=6)
Upstream
Customers
Work (Backlog )
Work Item wai ng for selec on
SSRR 2014 19
Rationale for SE as a Service
•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
SSRR 2014 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 2014 21
Healthcare SoS
• Custom software SoS constituent 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
SSRR 2014 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 2014 23
Proposed KSS Network Structure
Capability Engineering
Individual Product Team
Execu ve/Stakeholder
Management (Customer)
SLA establishment and monitoring
Strategic planning
Capability priori za on
Dash
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
Network Domain Team
Pharmacy Domain Team
Users User Support
���
Product/Domain Engineering
KSS
KSS
Dash
KSS
Customer rela ons
Ini al Triage
Product SE
Iden fy SW Features
Allocate features to SWDT
Integrate features into requirements
SW Development Team
Dash
KSS
KSS
KSS
Dash
Work Flow
Visibility
KSS
Needs
Backlog*
* All organiza ons can contribute to the Needs Backlog
SSRR 2014 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 2014 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 2014 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 2014 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 2014 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 kanban-
kanban 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 2014 34
References
1. Boehm, Barry and Turner, Richard (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison Wesley.
2. Larman C. 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, <http://www.ndia.org/Divisions/Divisions/ SystemsEngineering/Documents/Studies/Top%20SE%20Issues%202010%20Report%20v11%20FINAL. pdf>, September, 2010.
6. Turner, R. “A Lean Approach to Scheduling Systems Engineering Resources,” Crosstalk, May/June, 2013.
8. 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. <http://positiveincline.com/index.php/2010/03/ kanban-in-a-nutshell/>, March, 2010.
10. Reinertsen, Donald G. (2010). The Principles of Product Development Flow. Redondo Beach, CA: Celeritas Publishing.
11. Boehm, B. et al. “Applying the Incremental Commitment Model to Brownfield Systems Development,” Proceedings, CSER 2009, April 2009.
12. Boehm, B., and Lane, J., “Using the ICSM to Integrate System Acquisition, SE, and Software Engineering,” CrossTalk, October 2007, pp. 4-9.
13. 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, 2012. 1-7.
14. 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, 2008.
Recommended