{"id":857,"date":"2020-05-03T17:52:58","date_gmt":"2020-05-03T15:52:58","guid":{"rendered":"http:\/\/blog.hardscrum.com\/?p=857"},"modified":"2021-10-30T14:41:56","modified_gmt":"2021-10-30T12:41:56","slug":"agility-vs-engineering","status":"publish","type":"post","link":"https:\/\/blog.hardscrum.com\/en\/agility-vs-engineering\/","title":{"rendered":"Agility vs. Engineering"},"content":{"rendered":"

Is agile product development and the application of engineering practices a contradiction, can they be combined or do they even complement each other? <\/span><\/span><\/span><\/span><\/span>In this article we want to investigate this question.<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n

<\/p>\n

Engineering without Agility<\/span><\/span><\/span><\/span><\/span><\/span><\/h2>\n

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.<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n

In the worst case, this creates a <\/span><\/span><\/span><\/span><\/span><\/span>waterfall-like approach<\/span><\/span><\/span><\/span><\/span><\/span><\/a> , ie the purely plan-driven implementation of early-identified requirements, adherence to plans and a change system that focuses on “being back on schedule”.<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n

Favorably, a not so strict plan arises, which <\/span><\/span><\/span><\/span><\/span>can be changed <\/span><\/span><\/span><\/span><\/span>at <\/span><\/span><\/span><\/span><\/span><\/span>milestones<\/span><\/span><\/span><\/span><\/span><\/span><\/a> by <\/span><\/span><\/span><\/span><\/span><\/span>change management<\/span><\/span><\/span><\/span><\/span><\/span><\/a> , but mostly only produces less optimally through (too) early conceptual decisions, or repeatedly produces similar products.<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n

Agility without Engineering<\/span><\/span><\/span><\/span><\/span><\/span><\/h2>\n

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. <\/span><\/span><\/span><\/span><\/span>The statement that agile protagonists like to make that <\/span><\/span><\/span><\/span><\/span><\/span>agile architectures are created within the team<\/span><\/span><\/span><\/span><\/span><\/span><\/span> means<\/span><\/span><\/span><\/span><\/span><\/span> that they should not be created outside the team. <\/span><\/span><\/span><\/span><\/span>However, this does not necessarily mean that everyone in the team can and should have an equal say. <\/span><\/span><\/span><\/span><\/span>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.<\/span><\/span><\/span><\/span><\/span><\/span><\/p>\n

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. <\/span>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.<\/span><\/span><\/p>\n

Agility needs engineering!<\/span><\/span><\/h2>\n

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. <\/span>And here, again, established engineering practices are used, such as <\/span><\/span>Requirements Collection and Analysis<\/span><\/span><\/strong> , <\/span><\/span>Concept Development and Evaluation<\/span><\/span><\/strong> , as well as <\/span><\/span>Feasibility Studies<\/span><\/span><\/strong> .<\/span><\/span><\/p>\n

To support this, there are <\/span>suitable <\/span>backlog elements<\/span><\/a> in our scaled agile <\/span><\/span>P4 framework<\/span><\/span><\/a> that <\/span>promote <\/span>simple and lean <\/span>system engineering<\/span><\/a> .<\/span><\/span><\/p>\n

The following backlog elements are available for Requirements Collection:<\/span><\/span><\/p>\n