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 18

Examples of Networked KSSs

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 24

Classes of Service

SSRR 2014 25

Flow among and between KSSs

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 28

Normal Capability Development

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 30

Critical Task Operation

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 33

Questions?

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.