Agilely Managing Software Intensive System of Systems

Agilely Managing Software Intensive System of Systems

When we hear mention of Agile Software Development in the absence of a domain and a context in that domain - take care. The first question is, does the author have hands-on experience applying agile methods to solve a problem in a specific domain under specific conditions?

My domain is categorized as?Software Intensive System of Systems?(SISoS). In this domain, we applied traditional program and project management?methods at the top level for cost and schedule management. This means a?Capabilities Based Plan?for what business and operational?capabilities?are needed in the needed order to fulfill the Mission and Vision of the enterprise funding the program. Software development and sometimes hardware development is done agilely, using one of several Agile development methods - SAFe, Scrum, for example.

Software Intensive System of Systems

"System of Systems” is not monolithic. They have five characteristics (Maier, 1998) that make the system of systems designation (Krygiel, 1999; Carlock & Fenton, 2001).?A System of Systems possesses:

  1. Operational Independence of the Individual Systems. A system of systems is composed of systems that are independent and useful in their own right. If a system of systems is disassembled into component systems, these component systems can perform useful operations independently of one another.
  2. Managerial Independence of the Systems. The component systems not only can operate independently, they generally do operate independently to achieve an intended purpose. The component systems are generally individually acquired and integrated, and they maintain a continuing operational existence that is independent of the system of systems.
  3. Geographic Distribution. The geographic dispersion of component systems is often large. Often, these systems can readily exchange only information and knowledge with one another rather than substantial quantities of physical mass or energy.
  4. Emergent Behavior. The system of systems performs functions and carries out purposes that do not reside in any component system. These behaviors are emergent properties of the entire system of systems and not the behavior of any component system. These emergent behaviors fulfil the principal purposes of supporting the engineering of these systems.
  5. Evolutionary Development. A system of systems is never fully formed or complete. Development of these systems is evolutionary over time and with structure, function, and purpose added, removed, and modified as experience with the system grows and evolves over time.

In the SISoS domain, several critical success factors may not be found in other domains:

  • Capabilities?drive the development of requirements
  • Measures of Effectiveness, Measures of Performance, Technical Performance Measures, and Key Performance Parameters are the units of measure meaningful to the decision-makers.
  • Cost, Schedule and these?measures?are tightly interconnected.
  • All development occurs in the presence of uncertainty and the risk this uncertainty?produces.
  • Making decisions about any work that impacts the four?measures?in the presence of uncertainty requires that we make estimates. This immutable principle is based on decision-making principles in the presence of uncertainty.

The?system?can be a business system, a collection of hardware and software for defense or space, weapons systems, or business management systems. But these systems all have the same things in common. [1]

Foundation of Successful Management of SWISoS

Here is a starting point for SISoS. These are from the University of Paderborn, Software Engineering Group, which is no longer available, but they are from my library here.

Measures of Success for Complex SISoS

The starting point for any assessment of success is the 4 Systems Engineering measures.

  • Measures of Effectiveness (MOE) - is a measure of the ability of a system to meet its specified needs (or requirements) from a particular viewpoint. This measure may be quantitative or qualitative, allowing comparable systems to be ranked. These effectiveness measures are defined in the problem space. Implicit in meeting problem requirements is that threshold values must be exceeded.
  • Measures of Performance (MOP) - measures a system’s performance expressed as speed, payload, range, time-on-station, frequency, or other distinctly quantifiable performance features. Several MOPs and/or Measures of Suitability (MOSs) may be related to achieving a particular Measure of Effectiveness (MOE).
  • Technical Performance Measures (TPM) - a technique that measures the risks inherent in a technical system element to determine how well that element satisfies specified requirements. Regularly comparing the achievement of chosen technical elements to expectations validates progress and reveals deviations that could jeopardize the fulfillment of the end product requirements.
  • Key Performance Parameters (KPP) are attributes of a system considered critical to developing an effective military capability. The number of KPPs identified by a Sponsor should be kept to a minimum to maintain program flexibility.?Failure of a system to meet a validated KPP threshold/initial minimum rescinds the validation, brings the military utility of the associated system(s) into question, and may result in a reevaluation of the program or modification to production increments. [2]

Increasing Probability of Success for Software Intensive Complex System of Systems using Agile Development and Earned Value Management

Complex Systems Development inclidong Sofwtare Development Lifecycles is straigtforward when there is a Bright Line between the Performance Measurement Baseline (PMB_ and the system edevlopment process that define the Capabilities needed to accomplish a Mission of fullfill a Strategy using the MOEs, MOPs, TPMs and KPPs introduced above

Five Immutable Principles of Project Success no Matter the Domain, Context, Management Tools, or Processes

The basis of success for all project success, no matter the domain, project management process (Agile or Traditional), project management tools, and technology, start by answering the questions posed by the Five Immutable Principles, first published in?Performance-Based Project Management , American Management Association, February 2014.

  1. What does?Done?look like in units of measure meaning full to the decision-makers, starting with Measures of Effectiveness (MOE), Measures of Performance (MOP), Technical Performance Measures (TPM), and Key Performance Parameters (KPP)?
  2. What is the?Plan?to reach?Done, with outcomes fulfilling these measures on the needed date, for the needed cost, to deliver the needed Capabilities to accomplish a mission or fulfill a strategy?
  3. What?Resources?- staff, facilities, funding, and regulatory compliance will be needed to reach?Done?as needed?
  4. What are the Impediments?to reaching?Done?at the needed time, for the needed cost, with the needed Capabilities?
  5. How will?Progress to Plan to?be measured in units of measure meaningful to the decision-makers? The passage of time, consumption of money, production of Stories, and Story points are not measures of progress to Plan. Delivery of Capabilities to accomplish the mission are.

Integration of Program Performance Management with Agile Software Development

Here are the 10 Steps to Integrate Agile Development with Program Performance Management . Starting with the Engineering Estimate, define the deliverables, the plan for their production, their deployment, any variance of effort and cost, and the corrective actions to keep the planned work on plan. These are activities for Program Controls of Scrum development projects based on Product Roadmaps, Release Plans, and measures of Physical Percent Complete at the Sprint level.

Increasing the Probability of Success for Complex System of Systems by Integrating Systems Engineering, Agile Project Management with Program Performance Management

Here is a set of briefings to successfully increase the probability of program success

  1. Getting Started ?- Starting with FAR 34.2 and DFARS 234.2 compliant Systems, System Development, including Software Development Lifecycles (Agile), is straightforward when there is a Bright Line between the Performance Measurement Baseline (PMB) and system development processes.
  2. Executive Overview ?- Systems Engineering, Earned Value Management, and Traditional and Agile development have much in common.
  3. First Comes Earned Value Management ?- EVM and Agile must be deployed together to harmonize with each other.
  4. Opening Background ?- both EVM and Agile measure progress to plan as Physical Percent Complete
  5. Start with the End in Mind ?- the integrated value proposition of Agile and EVM needs to be articulated upfront.
  6. Framing Assumptions ?- define and track key program assumptions made early in the program development.
  7. Foundations of Earned Value Management ?- physical percent complete is the foundation of EVM + Agile.
  8. Performance Planning ?- is performed by objectively assessing accomplishment at the work performance level.
  9. Connecting the Dots Between EVM and Agile ?- sharing a common theme of Progress to Plan measured by Physical Percent Complete
  10. Requirements Elicitation ?- technical and operational requirements are flowed down in traditional programs and emerge from Capabilities in Agile programs.
  11. Planning, Budgeting, and Estimating in Agile ?- using Cardinal Values to estimate work on Agile projects.
  12. Step-by-Step ?- building and executing the Performance Measurement Baseline.
  13. Dependency Management in Agile at Scale ?- with multiple agile teams working System of Systems, dependencies will appear.
  14. Change Control ?- differences between change control on traditional and agile projects.
  15. Physically Connecting the Dots ?- between Agile, Program Planning, and Control, Earned Value Management, and Reporting.
  16. The Dark Side of Agile ?- both EVM and Agile have dark sides.
  17. Failure Modes of Agile Transformation and Program Performance Management ?- finding and handling the root causes of failure.
  18. Maturity Models for Deploying Agile at Scale ?- applying EVM through the CMMI governance framework.
  19. Root Cause Analysis ?- Identify conditions and actions creating root causes of project failure to develop corrective and preventive actions.
  20. Agile Contracts ?- FAR 15.201 and Agile Uniform Contract Formats, agile construction contracts, and other non-IT domains.
  21. Conclusion ?- integrating agile on EVM programs is straightforward once the?bright line?is established between the PMB and Agile release Sprint and Story activities.

Management Processes

Managing projects in the presence of uncertainty means making decisions about cost, schedule, and technical performance, all?risk-adjusted, from the uncertainties that create risk. Here are presentations and papers on how to manage in the presence of uncertainty in a variety of domains.?

Complex Systems Organizations

References and Bibliography

[1]?On the Systems Engineering and Management of Systems of Systems and Federations of Systems , Andrew P. Sage and Christopher D. Cuppan,?Information Knowledge Systems Management?2 (2001) 325–345, IOS Press

[2] Manual for the Operations of the Joint Capabilities Integration and Development System

要查看或添加评论,请登录

社区洞察

其他会员也浏览了