Is Agile Project Management Systems Engineering?

Systems Engineering ensures the whole product works together with its external systems to meet the needs of the customer

Agile Project Management can be directly derived from Systems Engineering concepts

With a SE approach, agile

PM now has a solid

foundation in theory and in

practice.

―Anecdotes,‖ can be

replaced by academic

foundation

Robust Design and Development

Process and Methodology

Accelerated System Integration and Testing

Agile Systems

Engineering and

Architecting

Agile Product

Development

Strategies and

Approaches

Agile Development Drivers

Technology – Market - Regulations

“Whole” and “external” are core components of systems engineering. They also connect us to agile project management.

Whole: meaning all aspects of product delivery

Technical

Business

Operations

Deployment

Maintenance

Withdrawal

External: meaning

all the participants

Internal customers

External customers

Partners

VARs

ISVs

Funders

The idea of “agile” systems and management goes back long before the current paradigm change in Agile Project Management

Evolution is a technique for producing the appearance of stability. A complex system will be most successful if it is implemented in small steps and if each step has a clear measure of successful achievement as well as a ―retreat‖ possibility to a previous successful step upon failure. You have the opportunity of receiving some feedback from the real world before throwing in all resources intended for a system, and you can correct possible design errors... Tom Gilb, 1976

Traditional approaches to management start with “plans.” These plans are characterized by both their behaviors and their artifacts

Work is planned in stages

Single pass or sequential development of

detail

Doucment driven communication processes

Open loop (sequential) feedback

We’ve known for a long time of the “dangers” associated with sequential, open loop systems, even though we easily fall into the trap is using them in our current work processes

…there are dangers, too, particularly in the conduct

of these [waterfall] stages in sequence, and not in

iteration, i.e., that development is done in an open

loop, rather than a closed loop with user feedback

between iterations. The danger in the sequence

[waterfall approach] is that the project moves from

being grand to being grandiose, and exceeds our

human intellectual capabilities for management and

control. — Mills, 1976.

Systems Engineering impacts on the sequential processes of the past

Systems engineering takes a different

approach to work processes. One based on

the integrated ―whole,‖ defining both the

product and the process in a continuously

evolving improvement paradigm

Systems Engineering touches a variety of topics in a software development project. Not controlling these processes, but integrating there products and processes

Systems engineering

enables subsystems to

interact through a protocol

of interfaces

The rhythm of the project

is built around the flow of

value through systems

engineering

Software

Engineering

Enterprise

Management

Project

Management

Soft Systems

Engineering

Verification

And

Validation

Hardware

Engineering

Human

Systems

Management

Systems

Engineering

Why do we need project management at all in an agile project environment?

Customers demand insight into the use of their

funding from a ―risk management‖ point of view

Measures of progress go beyond the linear

production of code from a customer list of ―stories‖

Coordination extends beyond the boundaries of a

small group of developers into groups of strangers.

Where does the solution to these needs start? Create normative rules of compliance or heuristics to address needs?

Using Rechtin' s four classifications

Normative

Rational

Participative

Heuristic

The normative approach results in ―guidebooks‖ of

how to manage a projects

Rational approaches (Systems Engineering) provide

the basis of Participative and Heuristics methods

What is Project Management?What is Agile Project Management?Why are they different from each other?What does this mean to the profession?

The normative answer is not very satisfying for agile participants

Fernando Flores, PhD Thesis Communication and Management in the Office of the Future, University of California Berkeley, 1982, says it better in our agile vocabulary:

Management is that process of openness, listening, and eliciting commitments, which includes a concern for the articulation and activation of the network of commitments, primarily produced through promises and requests, allowing for the autonomy of the productive units.

Apply the Flores definition to projects and we’ve got an agile view of Project Management through the eyes of a Systems Engineer

Remember the ―whole‖ and ―external‖ attributes of systems

The confusion between traditional and agile starts with the false assumption that “traditional” project management is not concerned about value production

The premise that ―traditional‖ project management is

not focused on the same things ―agile‖ project

management is misguided at best and poorly

informed at worse

―Traditional‖ project managements places these

concerns in the ―business management‖ domain, not

the project management domain

―Traditional‖ project management is focused

Adding business management to project management “may” be the basis of agile project management, but some more thought is needed to understand the consequences

Systems engineering (systems management)

has similar concerns

Product and process performed in parallel

Value focused decision making – trades

Systems Engineering has a firm foundation of

process and theory

Project management is but one part of Systems

Engineering

Why do we care about this definition? How does this definition influence how we talk about project management?

If Project Management is just about the processes then we’re missing the solution to most of the problems Flore’s ―management‖ definition

It’s the People!

The PMI definition is necessary, but not sufficient for success A human centered process are missing

Defining ―what does done look like‖ is the starting point

Long before the current paradigm discovery Iterative Development was the basis of good systems engineering practices

The basic approach [Randell‘s and Zurcher‘s Iterative Development] recognizes the futility of separating design, evaluation, and documentation processes in software-system design. The design process is structured by an expanding model seeded by a formal definition of the system, which provides a first, executable, functional model. It is tested and further expanded through a sequence of models, that develop an increasing amount of function and an increasing amount of detail as to how that function is to be executed. Ultimately, the model becomes the system.

— Lehmann, 1969

Common themes that Agile Project Management professes are claimed to not be present in other approaches

Significantly less documentation is needed to define the needs of the project

Small development cycles

Emphasis on team work and collaboration

Adaptive development processes

What is recognized is – these are the principles of Systems Engineering as well

What is a System and what is the discipline of Systems Engineering?How is this important to Agile Project Management?

System – is an interacting combination of

elements, viewed in relation to function

Machine elements (algorithms, processes, rules)

Environmental elements (external influences)

Human elements (interactive behaviors)

Emergent behaviors (alterations to behavior)

Systems Engineering – is the art and science

of creating complex systems

Complex systems are the target space of Systems Engineering. Integrating the product and the process is the basis of complex adaptive systems. Both interact to form a “system”

The systems approach is fundamentally

different from ―traditional‖ project

management

But, systems engineering still uses core

project management processes

It combines product and process in a single

discipline.

What Are The Elements Of Project Management?

There are several descriptions of ―project

management.‖ The current agile approaches

do not include the normative components, this

is likely a gap that needs to be filled before

they can be applied outside agile software

development

If project management as a profession is well developed, why don’t we recognize the elements of project management in agile project management?

Project Management Institute elements

Software Engineering Institute CMMI IPPD

Project Management

Prince2

What are the elements of a systems management process?

No matter what the software development methodology, a set of systems management processes can be found in some form

Systems management processes are the basis of agile project management

Management – code development needs

Organization – staffing and business

processes

Engineering – building the system requires

more than just stories and coding processes

Management processes involved in the project management activities. These activities involve both people and processes. Scaling these process outside the small group is an issue

Subcontract management

Inter-Group Coordination

Risk management

Tracking and Oversight

Quality management

Configuration Management

Planning

Data management

There are organizational processes involved in project management as well

Competency development

Technology management

Process management and improvement

Environment and Tool support

Systems engineering processes can now be connected to the project management processes

System concept definition

Requirements and

functional analysis

System design

Integrated engineering

analysis

System integration

System verification

System validation

Making this connection

breaks the normative

paradigm

Replacing it with a

participative and heuristic

paradigm of agile project

management

A systems engineering view of requirements

Design ideas can not be judged or

validated except with respect to the

functional, quality, and cost

requirements they must satisfy

– Tom Gilb

Requirements are part of the process not matter the project management method is used – agile or not

How can any software process be successful

if it does not attack the requirements?

Agile methods use testing to provide

validation

Requirements are identified through

prototyping

Agile processes do not explicitly address of

verification

What is requirements management all about? The process of managing change to the requirements for a system

The principal concerns of requirements management Managing changes to agreed requirements

Managing the relationships between requirements

Managing the dependencies between requirements

Managing requirements without traceability? A requirement is traceable is the requestor is known,

the reason the requirement exists is known, how the requirement relates to other requirements and how it related to the architecture, implementation and user documentation.

Stable requirements and volatile requirements –they’re the same and they’re different

It is common in all projects the requirements

chances occur while they are being elicited

Stable requirements concern the ―essence‖ of

the system and its application domain

Volatile requirements are specific to the

instance of the system in a particular

environment or product configuration.

Factors influencing requirements changes can be addressed by project management processes

Requirements errors, conflicts, omissions,

inconsistencies

Evolving customer, market, and user-

knowledge needs

Technical, schedule or cost changes

Changing market or customer priorities

Organizational changes

Volatile requirements is too broad a term to be useful in practice. Here are four simple classes of requirements volatility found in systems engineering

Mutable – environmental changes

Emergent – as the system develops

Consequential – new assumptions of use

Compatibility – equipment or process

Traceability from requirements to deliverable elements of the project forms the basis of “testing” compliance with customer needs

Information used to assess the impact of

requirements changes

Types of traceability

Backward from – links requirements to their source

Forward from – links requirements to design

Backward to – links design and implementation to

requirements

Forward To – links documents to relevant requirements

Verification and Validation are part of the project management domain as well as development

Verification – ―are we building the product

right?‖

Validation – ―are we building the right

product?

Test – validation – is different from inspection

– verification.

The tyranny of requirements is independent of the project management methodology

―If someone is trying to contract for a system, and they can properly identify all the necessary ‗requirements‘, then it makes sense to do so. The preference then usually becomes: ―meet the requirements, and pick the lowest cost.‖ But the reality is, in every complex system I've seen, ―most ‗requirements‘ aren't.‖ Given the right combination, nearly any ‗requirement‘ will be relaxed to obtain some other gain. The real preferences are hidden behind the ‗requirements‘ in some operational analysis space. … As soon as someone lists a set of ‗requirements‘ without indicating what makes one system better than another, they've lost the information for comparison.‖

– Eric Honour, President INCOSE

The inevitable pain of software development comes from the efforts to manage requirements in the presence of change

Every major aspect of software development includes at least one step that is so painful that programmers habitually avoid it. The biggest problem is remembering all the requirements. You get more requirements while working on initial requirements. you forget to write them down in the excitement of coding, and feel guilt if you spend too much time on requirements, instead of coding. Changing requirements cause the most pain of all.

– Dan Berry, University of Waterloo, Waterloo Ontario

Why do we need to augment agile software development with Project Management? Where’s the value to agile software development?

Multiple phases of product development exist

in any sufficiently complex environment

Exploration – research, concept synthesis,

product and market analysis

Development – technical management,

development lifecycle processes

Operations – field operations, minor updates,

anomaly resolutions

Systems engineering processes address the gaps between agile development methods and their business management

Systems engineering considers the Full lifecycle of product development Exploration

Customer needs

Technologies

Concept of operations

Development

Technical management

Operations

Field operations

Maintenance, update and support

How can we recognize the right process when we see it?

Are there work products that go unused?

Documents

Analyses that don’t turn into features

Is product quality at the target level?

Rework

Field problems

Is project performance at the target level?

Cost and schedule performance

Value connected to investment

Project management is really a technical business management discipline. Agile software development is product development. They are not competitors

What is project management? PMI processes: Initiating, Planning, Executing, Controlling,

Closing

CMMI IPPD PM processes: Planning, Monitoring and Control, Supplier Management, Integrated Product Management, Risk Management, Integrated Teaming

The agile paradigm must address each of these traditional process areas If it doesn’t then is agile project management, project

management – or something else?

Primary role of Agile “project management” is focused on the same things as “traditional” PM – the delivery of value to the customer.

Verify that the ―right‖ plan is being followed

Traditional Project Management takes action in the presence of deviations Process areas do not question of the plan is the right plan

Agile Project Management focuses on the flow of ideas rather than task completion Know the Significant Accomplishments

What does ―done‖ look like?

Are we building the right thing?

Technical aspects of Systems Engineering and Agile Project Management

Architecture – existing and new capabilities

Analysis – capacity usage, response time,

allowed usage

Operational concepts – new requirements

Balancing disciplines – overview of all the

aspects of the system

The core of any agile project management process – experimentation

Experimentation matters because it is

through learning equally what works and

what doesn‘t that people develop great new

products, services and entire businesses. But

in spite of lip service that is aid to ―testing‖

and ―learning from failure,‖ today‘s

organizations, processes, and management

of innovation often impede experimentation.‖

Three stages of project control systems. Assessing the stage is critical to assessing the project’s success

Stage 1:

Chaos

Stage 2:

Prescriptive Control

Stage 3:

Adaptive Control

Minimum

controls

―Just do it‖

Undefined

lifecycle

Conformance to

plan

―Plan the work, work

the plan‖

Task based

(horizontal planning)

Conformance to

acceptable results

―Embrace

change‖

Iterative,

incremental and

feature Driven

Tom Glib’s Evolutionary Systems Engineering Approach is a nice bridge between Agile Project Management and Systems Engineering

Decompose the problem by performance results and stakeholders

Do the high risk steps first and learn how the unknowns really perform

Focus on improving the most valuable performance objectives first

Base early evolution on existing frameworks and stakeholders

Design to cost

Design to performance

Invest in open ended architectures early

Motivate the team through results rewards

Prioritize changes by value not by their place in the queue

Learn fast, change fast, adapt to reality fast

Bibliography

B. Randell and F.W. Zurcher, ―Iterative Multi-Level Modeling: A Methodology for

Computer System Design,‖ Proceedings of IFIP, IEEE CS Press, 1968, pp. 867-871.

C. Larman and V. R. Basili, ―Iterative and Incremental Development: A Brief History,‖

IEEE Computer, June 2003, pp. 47-56.