What's Missing from the Agile Software Development Paradigm?

What's Missing from the Agile Software Development Paradigm?

Agile software development is framed by a?manifesto, a set of 12 principles and several?methods. These are all focused on?developing software and delivering that software to those paying the developers.

A fundamental critical success factor needs to be added to this paradigm.

The customer is accountable for knowing what Done Looks Like (in Units of measure meaningful to their domain. which start with Measures of Effectiveness and Measures of Performance , supported by Key Performance Parameters and their Key Performance Indicators)

Most customers have yet to be exposed to a paradigm that is the basis of everything we do in our Software Intensive System of Systems (SISoS) domain. [7]

Systems Engineering

Systems engineering is a methodical, multi-disciplinary approach to a system's design, realization, technical management, operations, and retirement. A system is the combination of elements that function together to produce the technical and operational capabilities required to meet a need. The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose, all things required to produce system-level results. The results include system-level qualities, properties, characteristics, functions, behavior, and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected. [1]

Systems Engineering looks at the big picture to make technical decisions. Systems Engineering assesses processes for achieving stakeholder functional, physical, and operational performance requirements in the intended use environment over the planned life of the system within cost, schedule, and internal and external constraints. Systems Engineering is the methodology that supports the containment of the life cycle cost of a system.

Systems Engineering is a Logical way of Thinking.

Systems engineering is the art and science of developing operable systems capable of meeting requirements within opposing constraints. In our Software-Intensive Systems of Systems (SISoS) domain, Systems Engineering is the holistic, integrative discipline, with contributions from architects, developers, testing, database designers, security, performance engineers, User Experience, and User Interface designers, and other disciplines are evaluated and balanced, against another, to produce a coherent whole that is not dominated by the perspective of a single discipline. [2]

Systems Management is the Science of Systems Engineering

Systems Management focuses on rigorously and efficiently managing the development and operation of complex systems. Effective systems management requires applying a systematic, disciplined engineering approach that is quantifiable, recursive, repeatable, and demonstrable. The emphasis of Systems Management is on organizational skills, processes, and persistence. Process definition and control are essential to effective, efficient, and consistent implementation. They demand a clear understanding and communication of the objectives and vigilance, ensuring and assuring all tasks directly support the objectives.

Systems management applies to developing, operating, and maintaining integrated systems throughout a project or program’s lifecycle, which may extend for decades. Since the lifecycle may exceed the memory of the individuals involved in the development, it is critical to document the essential information.

We must blend technical leadership and systems management into complete systems engineering to succeed. Anything less results in systems not worth having or failing to function or perform. [3], [4]

Why This Missing Concept is Important to Agile Software Development??

Agile is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer/end users. Agile is the ability to create and respond to change. It is a way of dealing with and ultimately succeeding in an uncertain and turbulent environment.

Agile software development is more than Scrum, Extreme Programming, or Feature-Driven Development (FDD) frameworks.

Agile software development is more than practices such as pair programming, test-driven development, stand-ups, planning sessions, and sprints.

Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. When you approach software development in a particular manner, it's generally good to live by these values and principles and use them to help figure out the right things to do, given your particular context. Those 12 Principles are simply 12 principles of project management .

One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context. [5]

This last statement is the principle of Systems Management

So What's The Point??

Without knowing what Done Looks Like in units of Measures of Effectiveness (MOE) and Measures of Performance (MOP). These MoE's and MoP's and other measures start at the systems level [6]

  • Technical Performance Measures?(TPM) are defined at the start of a program—the planned progress of selected technical parameters. They provide a warning to systems engineers of technical problems and an assessment of the impacts of proposed changes in system performance. They assist in decision-making (performance or resource tradeoffs) by comparing actual vs. projected performance. TPM parameters that especially need to be tracked are the cost drivers on the program, those that lie on the critical path, and those that represent high technical risk items. System performance requirements are testable and measurable.
  • Key Performance Parameters (KPP) are essential for successful mission accomplishment. KPPs represent those capabilities or characteristics so significant that failure to meet the threshold value of performance can cause the concept or system selected to be reevaluated or the program to be reassessed or terminated. Each KPP has a threshold and an objective value. Trade studies typically may trade off everything except a KPP. In other words, KPPs are non-tradeable. They flow from the operational requirements. They are documented in the Operational Requirements Document, the Capability Development Document, or the Capability Production Document.
  • Key System Attributes (KSA) are considered most critical or essential for an effective capability but not selected as KPPs. KSAs provide decision-makers with an additional level of capability prioritization below the KPP. A KSA does not have to be related to a KPP and there is no implication that multiple KSAs equal a KPP.
  • Measures of Effectiveness (MOE) measure how well an operational task or task element is accomplished through a system. The data used to measure the effect (mission accomplishment) comes from using the system in its expected environment. MOEs often have green/yellow/red limits established early in the program and are tracked until they turn green or are demonstrated to be unachievable. The MOE can be stated either as a question or a declarative statement. The MOE is often stated in terms of accomplishment gained per cost incurred.
  • Measures of Performance (MOP) - are components, or subsets, of MOEs. The degree to which a system performs is one of several possible measures of how well a system's task is accomplished. MOPs can be accumulated to assess an MOE that is not directly measurable. Several MOPs may be related to the achievement of a particular MOE. MOPs supply supporting data to determine MOE status as it evolves over the life of a program. Together, they determine what constitutes successful operations for the system. MOPs and MOEs are derived from requirements or the Concept of Operations. Their selection should be based on their ability to discriminate between good performance levels.

So What Does This Mean to Agile Software Development??

With a clear, concise, measurable description of Done, the probability of success for the project arriving on time, on budget with the needed capabilities is high. None of the MOE's MOPs, KPPs, KSAs, and TPMs are addressed in Scrum, XP, or similar Agile Software Development methods.

This last part is addressed in one Agile development process we use in our Complex Software Intensive System of Systems (SISoS) domain - Scaled Agile for Enterprise (SAFe). But SAFe is the evil empire for many agilest.

References?

[1]?Systems Architecting of Organizations: Why Eagles Can't Swim , Eberhardt Rechtin

[2] "Systems Engineering and the Two Cultures of Engineering," D. Griffin, NASA Administrator?

[3] "The Art and Science of Systems Engineering ," Michael Ryschkewitsch, Dawn Schaible, and Wiley Larson,?Systems Research Forum, Vol. 3, No. 2, pp. 81-100, 2009.

[4] One of my Masters is in Systems Management, University of Southern California.

[5] "What is Agile?", Agile Alliance

[6] "Technical Measurement Guide," Gary Roedler and Cheryl Jones, INCOSE-TP-2003-020-01, December 2005.

[7]?Designing Software-Intensive System of Systems, Methods, and Principles, Pierre F. Tiako, Information Science Reference, 2009.?

Louise Landry

Executive Business Analyst @ L. & L. Distribution | BA, SE, SOA Secretary Admin. Assistant Project Management, Technical and Business Lead, Office Manager, Consultant, Representative, Sales Marketing, Manager.

1 年

Major element is resumed here "We must blend technical leadership and systems management into complete systems engineering to succeed." What is missing is that, meaning dedicated global framework oversight as a step of effectiveness. Thank you!

回复
Larry Moore

IT Project Management Specialist

1 年

Glen Alleman: I am a bit confused by something you presented in your post. You show a graphic labeled as "AGILE" that seems to describe the following process: First, we PLAN, then we DESIGN, then we DEVELOP, then we TEST, then we DEPLOY, then we REVIEW, then we LAUNCH. (By "launch" I assume you mean "put into production.") To me, that does not look like "Agile." Instead, it looks like a purely sequential "Waterfall" approach. What was your intent in showing us this graphic? What am I missing here? On the other hand, what I read in your article seems to make a great deal of sense. I am just confused by the graphic.

回复
Randy Spires

Product, Program, and Project Portfolio Management Executive | Digital Transformation | Organizational Development

1 年

Glen, great article and great points. I have had to engage in many 'agile' transformations that fail on the numerous points you make in this and other articles.

回复

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

社区洞察

其他会员也浏览了