agile project management is systems management
DESCRIPTION
TRANSCRIPT
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.