Agile methods across all disciplines:
Leveraging modern prototyping tools like 3D printing and rapid
PCB manufacturing brings agility to hardware-, software- and
mechanical-engineering
Modularity through facet-oriented design:
Facet-orientation means focusing on a cohesive functionality or
set of features that span multiple disciplines. Think of it as
tackling cross-disciplinary development from top to bottom to
validate both the design and concept. This approach naturally
breaks the overall project into iterative, manageable
segments.
Decoupling multidisciplinary dependencies:
Project requirements can tightly link disciplines, but these
connections should only be made intentionally and alternatives
be considered. Regularly addressing them helps prevent costly
shortcuts down the line.
To implement MSD in a project the participants should follow these
guide-lines:
Synchronize scrum sprints across all disciplines.
Schedule periodic touchpoints involving all
disciplines.
Focus on improving the ability for adjacent disciplines to
work efficiently.
Share responsibility for iteratively refining product
requirements.
Design for modularity and change-readiness across all
disciplines.
Track and reduce the number of singularly essential
components.
Agile Product Development
The overarching characteristics of the agile software development
process is to define and refine requirements iteratively in small
steps converging towards the final product as seen in Fig.1.
Fig.1 - Define requirements in small iterations
instead of all in one go.
The MSD workflow spans the disciplines of mechanics,
hardware, procurement, and software development. Each discipline
progresses independently yet remains interconnected
through feedback loops. Since digital hardware typically requires
software to operate, verification becomes a multi-disciplinary
effort, requiring software developers not only to develop
functionality but also to support hardware verification.
For this to work synchronizing of scrum sprints across all
disciplines is required with scheduled periodic multi-diciplinary
touchpoints.
This is illustrated in Fig.2.
Fig.2 - Iterative workflow for MSD integrating
mechanical, hardware, and software development, including
touch-points with procurement.
As project progresses deliberate multi-versioning of hardware is
created and maintained - each supporting different agendas:
Developer-friendly: Focus on development
speed, with easy-to-access test points and easily modifiable.
Test-friendly: For testing and validation,
with needed interfaces for probing and text-fixtures.
Shippable: Targeting mass-producability,
scaled down and cost-down as needed with the correct component
variants
Key insight is continued focus on developer-friendly and
test-friendly variants instead of the traditional focus on final
shippable product only.
All three hardware variants must remain equivalent so, for
example, bugs discovered in the shippable product version can be
reproduced on the development-friendly version.
To get started an initial hardware is made based on off-the-shelf
components such as evaluation boards and test-wires.
This first version can be used for validating
the initial functional concept and from there next versions can be
made.
As shown in Fig.3, staggered hardware releases during intital
sprints are to be expected so the initial sprint-durations may
vary and be decision-driven rather than calendar-driven.
As the project gains momentum, the release/sprint-cycles will
converge to a steady pace as known from a classic scrum sprint
process.
Fig.3 - Hardware versions are not all created from
the beginning but rather made as the development progresses -
usually starting with the developer-friendly one.
Shared Focus and Responsibility
The cross-team touch-points ensures that learnings from each
dicipline are collected and used for input for upcoming
sprints.
Focus must be on improving the ability for adjacent disciplines to
work efficiently as well as share the responsibility for
iteratively refining product requirements.
As a rule of thumb, new hardware is developed each sprint
reflecting the latest requirements and features, as the project
progresses.
An example of how learnings from each dicipline are fed into the
others can be seen in Fig.4.
Fig.4 - The content of each sprint is based on the
outcome of the previous sprint in the adjacent
diciplines.
Design for Modularity and Interchangeability
When planning the progress of the project it should be made with
focus on vertical slices across all diciplines to keep the
development focused. This is illustrated in Fig.5.
Fig.5 - The way to work on functionalities in
vertical slices across diciplines in a modular way.
The main aim of design for modularity and change-readiness makes
it possible to make fundamental changes to the project, such as
changing a micro-controller, whenever needed with minimal impact
to the development process across disciplines.
This again requires minimizing the number of singularly essential
components which again adds the requirement of a flexible
architecture in both software, electronics, hardware and mechanics.
