Is agile product development and the application of engineering practices a contradiction, can they be combined or do they even complement each other? In this article we want to investigate this question.
Engineering without Agility
Many engineering practices have been devised in the last century, many of them to make complex systems and dependencies within this system manageable, enable reuse, encapsulate complex technology and clarify feasibility quickly and with as little effort as possible.
In the worst case, this creates a waterfall-like approach , ie the purely plan-driven implementation of early-identified requirements, adherence to plans and a change system that focuses on “being back on schedule”.
Favorably, a not so strict plan arises, which can be changed at milestones by change management , but mostly only produces less optimally through (too) early conceptual decisions, or repeatedly produces similar products.
Agility without Engineering
When introducing agility, it is often suggested to the teams that architecture and design decisions are now made entirely in the team, i.e. by everyone. The statement that agile protagonists like to make that agile architectures are created within the team means that they should not be created outside the team. However, this does not necessarily mean that everyone in the team can and should have an equal say. Otherwise, that would feel good for the team members somehow, but would lead to vague, democratic design decisions that should somehow please everyone, or it would lead to no decisions at all.
A second aspect is that with the purely user-driven development, which is often postulated in agile environments, a good solution emerges for the user group under consideration, but the solution is suboptimal for other, poorly represented stakeholders or in other contexts. In pure software development, this can be changed more easily through subsequent refactoring measures than in physical product development, where such design decisions have a much more drastic and long-term effect, right up to need of completely new developments.
Agility needs engineering!
The above statements mean that, especially with complex physical systems, design decisions should be well-founded and with a deliberate broad view of stakeholders and the various application contexts. And here, again, established engineering practices are used, such as Requirements Collection and Analysis , Concept Development and Evaluation , as well as Feasibility Studies .
The following backlog elements are available for Requirements Collection:
- Stakeholder needs correspond to the basic requirements of the various stakeholders at a very high altitude
- System Features reflect functional requirements. These can be modeled through user stories and / or use cases . A group of system features describes a system or a system variant as a Feature Set when thinking in platforms and / or market variants.
- The Quality Attributes correspond to non-functional requirements (NFRs) that have to be balanced against each other and that restrict the system concepts
- Constraints are also NFRs, which represent hard boundary conditions and also restrict the system concepts.
By prioritizing the requirements, i.e. defining the “importance” of the requirements by weighing the needs of the stakeholders, system concepts can be evaluated well.
The next level of System Concepts is about finding suitable solutions, forming variants and evaluating them against each other. System concepts describe solution variants for a feature set, which are analyzed and refined by the development work to such an extent that the most suitable variant remains through a selection and exclusion process and is further developed to market maturity.
Evaluation criteria for system concepts are, for example:
- Degree of fulfillment of the requirements
- Development costs versus a benefit analysis (profit, strategic benefit)
- Advantages and disadvantages, as well as risks and opportunities
Various engineering practices can be used, such as …
- Morphological box for finding suitable solutions and combinations
- System modeling for the visualization of concepts (e.g. using SysML )
- Decision matrix in which the different evaluation criteria are given different priorities (weights) and the overall degree of fulfillment is determined by the sum of the weighted individual degrees of fulfillment.
Established systems engineering practices have also proven their worth in test engineering and integration. The more frequent building of prototypes in agile product development means that also more tests are necessary. Therefore, test automation is a useful, almost necessary discipline. Other fields with high potential include rapid prototyping and digital simulation.
How much agility is possible, how much engineering is needed?
It is important to distinguish which application area we are considering. So do we want to build a website or Berlin’s new airport? This raises questions about possible technologies, solution concepts (e.g. building blocks, platforms) and their uncertainties as well as the clarity of system requirements. I refer to this as Development Complexity .
Another aspect is how much time and money is needed to generate a sample. I call this Realization Complexity .
Other driving factors
- the level of technological innovation : the less known the technology, the more you have to try and learn
- the degree of application-related innovation : is the technology accepted by users in the market? Here, too, you have to learn together with the market and users as quickly as possible
- the knowledge of the organization and the teams involved in terms of technology and application
- The degree of regulation of product development : The “sharpness” of the rules manifests itself in the amount of documentation, evidence and engineering practices, whereby regulators have also come to appreciate the advantages of early tests of iterative-incremental and agile procedures
Goals affect balance
Agility focuses on learning in fast cycles and often building prototypes . Possible mistakes are consciously accepted, because we also learn from them.
Engineering focuses on achieving a high level of quality while using as few prototypes as possible . Possible delays are consciously accepted.
The organization’s product development goals determines the balance between agility and engineering. Cost, schedule and product quality are weighed up.
Unfortunately, the belief (or hope?) still predominates today, that good engineering practices with a few prototypes lead to the goal faster and more effectively than the building prototypes more frequent and let engineers and users iterative learn together .
What is your experience in your market segment and in your organization? Comments and discussions are appreciated.
[Cover photo from freepik.com].