It's been said by an agile voice that ...
Progress and value delivery are not the same thing. In the end, of course, value (to someone) is important. And in the standard-for-today structure of programming for money, we divide what What from the How. Also, trailing indicator.
This view of the system of producing value in exchange for money ignores the principles of systems engineering.
Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design and manage complex systems over their life cycles. At its core, systems engineering utilizes systems thinking principles to organize this body of knowledge.
The original agile author's quote shows that systems engineering is missing from his development of software using Agile. In the systems engineering paradigm, both the how and the what are tightly coupled. Systems engineering has its roots in the fundamentals, principles, and models of foundational systems sciences, and associated management and engineering sciences. It is applied through the application of systems engineering processes within a managed lifecycle working with a number of other management, engineering, and specialist disciplines. While traditionally applied to product development, systems engineering can also be applied to service and enterprise systems. As systems engineering is a collaborative approach, working with other engineering and management disciplines and specialisms, it relies on enabling competencies and structures at individual, team, and organizational levels.
The elements of Systems Engineering are shown below. This is from the Systems Engineering Body of Knowledge
In this paradigm the what and the how are connected. In most of the software development, this notion is missing - hence the quote that What is divided from How.
This is a serious mistake for any non-trivial project or product that operates in the presence of uncertainty, deadlines, not-to-exceed budgets, and mandatory sets of capabilities that are produced in exchange for money on the planned date.
The second part of that quote is equally troubling - progress and value are not the same things.
Progress and Value are measured with the same in Earned Value Management
In Earned Value Management paradigm, progress is measured as physical percent complete. This physical percent complete is measured as compliance with the Technical Performance Measures of the outcomes of the work efforts, that consume the budget and time for that work. Along with the Technical Performance Measures are three other measures needed to assess progress to plan and production of Value.
- Measures of Effectiveness - are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions. The Measures of effectiveness ...
- Are stated in units meaningful to the buyer,
- Focus on Capabilities independent of any technical implementations
- Are connected to mission or business success
- The MOE's belong to the End User - this is the what part of the development project
- Measures of Performance - characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. The Measures of Performance are ...
- Attributes that assure the system has the Capability and Capacity to perform,
- Assessments of the system to assure it meets design requirements to satisfy the Measures of Effectiveness.
- Key Performance Parameters - are measures that represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing or termination of the program, project, or product. Key Performance Parameters ...
- Have a threshold or objective value,
- Characterize major drivers of Performance,
- Are consider Critical to Customer
To connect What with How we start with the Technical Performance Measures
- Technical Performance Measures - determine how well a system or systems elements are satisfying or expected to satisfy a technical requirement or goal. Technical Performance Measures ...
- Assess design progress,
- Defines compliance to performance requirements,
- Identify Technical Risk,
- Are limited to critical thresholds,
- Include projected performance
Here's an example of putting all these together. How these are delivered are equally as important as What is delivered
When we look at the Root Cause of the failure of non-trivial software projects, we see several sources:
- Unrealistic performance expectations, missing Measures of Effectiveness and Measures of Performance
- Unrealistic cost and schedule estimates based on inadequate risk-adjusted models of performance
- Inadequate assessment of risk and unmitigated exposure to these risks without proper handling plans
- Unanticipated technical issues with alternative plans and solutions to maintain the effectiveness of the resources and the outcomes they produce
So, in the end, anyone claiming what is separate from how needs to read this book
How and the What are inseparable if we are to have any hope of delivering what the customer has asked in terms of Capabilities for the needed Money, on the needed Date. Producing the What is highly dependent on How in terms of technological processes and the programmatic processes.
The original poster seems to have not encountered the principles of Systems Engineering as have many IT and Software development organizations. Which may explain the low probability of success as defined by the Root Causes shown above.
To see how this claim is a fallacy and learn how to apply Systems Engineering, Systems Thinking and connect the How with the What buy and read the book to the left. It will show you the:
- User Requirements Elicitation process - to answer what does the user want? The what of the project. The systems engineering process starts with what needs are dominate today and understand what will be dominant in the future. This user requirements process is different from the rest of the Systems Engineering processes. It is short, intensive and highly interactive. Poor handling of User Requirements causes severe problems later. Many development processes fail to distinguish between User and System requirements. This weakens the role of the User
- Systems Requirements process - explore the solution, but avoid commitment to any specific design. This effort creates a model of the system. These system requirements have distinct uses:
- An abstract view of the system
- Allow trade-offs, exploration, and optimization before committing to a detailed design
- Demonstrate to users that their needs are reflected in the development process
- Provide a solid foundation for the emerging design(s)
- Provide the basis for testing the system as it emerges
- Communicates previous decisions to the developers
- Architectural Design Process - defines clearly what is to be built. The architectural stage includes:
- Production of a design that will meet the user and system requirements with the operational environment
- Define the components to be built, the implementation approach and choice of the core technologies to be used
- Define how the components interact to generate the emergent properties called for in the System Requirements
- Trade-off candidate designs to maximize system effectiveness
- Generate an integration test strategy consistent with the design structure
- {artition the design components for allocation to different groups of implementors
- Define the deliverable items - to be placed under configuration management control
- Estimate the most likely cost and risk, plus the needed contingencies needed to handle these risks
- Ensure that the design work incorporates the results from the previous decisions
- How to integrate all these into an operational system. This involves Integration and Verification. This is performed as a continuous process at the Component Level. This takes place at three levels
- Component Verification - checks components against the design specification
- Integration Verification - checks the interfaces and control mechanisms against the architectural design
- System Verification - checks the finished product against tests based on the system requirements
- How to manage the project and the development processes and the systems processes. There is a direct link between systems engineering and project management
- Systems engineering defines the deliverables - the What
- Project management ensures these deliverables have the budget and schedule needed to produce these deliverables
- Systems Engineering is responsible for creating, defining, and empowering the product
- Project Management is concerned with the delivery of that system on time, on budget, on specification using the development processes - the How
The advantage of not managing the project is that failure comes as a complete suprise, not proceed by months of worry - Sir John Harvey Jones
- How to install a simple life cycle and tailor it. All successful lifecycles require feedback loops
- Feedback from design alters requirements
- Feedback from components alter design and requirements
- Feedback from Assembly, Integration, and Verification (AIV) alters components, design, and requirements
- Operational feedback shapes the requirements, design component development, and AIV through an iterative and incremental development process
- How to manage both the systems processes and the software development processes (this is the missing piece from the OP's understanding). These system processes - the What - are integrated with the development processes - the How. These are iterative and incremental since
- fixing requirements for a complete system without knowledge about the design, risk, and costs of implementation if impractical
- any large system must be handled as a set of concurrent smaller developments
- the management of risk by different participants demands more sophisticated interactions than ant sequential manner
This is why the strawman of Waterfall is not allowed in any mature organization
- How to manage the development of prototypes, how to model the information for the systems and other critical success factors
- In complex systems, separate development projects for each subsystem are usually necessary
- Each project can lead to the creation of further development projects at lower levels
