4 Agile Best Practices for Mechanical and Electrical engineering project - ALTEN Group (2023)

Agile methods are now popular in the software development world. However, it is not common to implement this type of iterative approach in engineering, mechanical and electrical design projects. Syncroness, a subsidiary of the ALTEN group, successfully combines the agile method and the industrial V cycle in several space embedded hardware projects. Their innovative approach has been published on AAIA, the largest American community of aerospace engineers.

Until now, the development of critical embedded systems (e.g. trajectory ECUs, etc.) has always been carried out with a rigorous process and clearly defined specifications from the start of the project. Nevertheless, this conventional approach is starting to show its limits faced with the rapid evolution of electrical technologies and changing market demands. The product can be already obsolete upon introduction, because the technology is outdated or the features do not meet anymore the market’s demand.

The agile method (in particular the Scrum) consists in dividing a complex project into several sub-projects. Instead of delivering a complete software in two years, the development team delivers a module or an evolution of the software every one or two weeks. Between each “sprint”, the development team is in contact with the end customer to define what needs and technologies to adopt. This “agility” allows the designer to react quickly to deviations (e.g. new user request, new technology…).

However, can the method be suitable for the design of integrated systems (mechanical and electrical) such as the development of an embedded system? We will therefore look at the differences, from an engineering project point of view, between software development and the design of electrical-mechanical systems.

Software vs hardware engineering: Why Scrum is not compatible?

As can be seen in the table opposite, electrical/mechanical design has very different constraints from software development.

Prototyping and industrializing equipment is expensive, as is modifying the definition of a system if it affects the test and production phases. Quite the opposite of the computer world.

This explains the conventional approach applied in the industry: extremely clear and well-defined specifications, multiple validation steps between each design phase (e.g. technical specification, architecture, detailed design, test, etc.). This top-down approach, following a rigorous process (V-cycle), minimizes the risk of last-minute changes.

This fundamental difference explains the reluctance of the sector to adopt the Scrum approach, and those who have tried have encountered enormous difficulties (See the publication Case Study of a Mechanical Product Development Team using Scrum).

Nevertheless, the world of embedded software development has unanimously accepted the agile method already. Syncroness notes the following: given the complexity of modern systems and the need to integrate several skills, a coordinated approach is required to complete successfully development projects. It is no longer possible to adopt two different project methods: for the hardware team on the one hand and the software team on the other.

Four agile method tools applied to mechanical and electrical engineering projects

Under the guidance of its software development team, Syncroness studied how to implement the main principles of the Agile method in different aspects of product design. The advantages are numerous: faster delivery times, better quality of deliverables, risk reduction, continuous improvement, transparency between the development team and the end customer…

After going through a lot of literature, Syncroness engineers discovered that the main principles of the agile manifesto have a lot in common with Lean (a method from the production world). Today, what is currently lacking is practical guidance for how any company or project can start implementing Agile principles without upending their entire product development process.After studying the principles and experimenting with the method in concrete projects, Syncroness identified the four most impactful tools: Incremental development, Visual task boards, Daily stand-ups and Demonstrate value often.

1. Incremental Development

A key characteristic of agile project execution is breaking up the traditional phased approach into several increments (called “sprints” in the Scrum method). Each “sprint” or increment is operated as a mini V-cycle, with defined objectives and a set of tasks to be performed.

Not only does the team get a regular sense of accomplishment, but also the stakeholders receive tangible value more often.

By prioritizing features, risk is reduced earlier and core features are emphasized, leading to a clearer understanding of project goals.

Finally, feedback is encouraged and can be incorporated before it becomes too expensive to implement.

There are three key meetings that bound and define a sprint: Sprint Planning, Sprint Review and Sprint Retrospective.

• Sprint planning
  
  This involves determining the objectives of the sprint, its duration and the tasks/features to validate in priority. The goal of each sprint is to demonstrate something tangible during the Sprint Review. Preferably, the goal is to produce a set of features and related functionality. The initial focus is on high-risk aspects of the design and core functionality; this way we are actively reducing risk and building a good framework for the rest of the product. Let us not confuse objective and task. For example, “work on mechanical design” is not a goal. It is a task. A good sprint goal for a mechanical project would be “Demonstrate prototype design of the housing”. Concerning the duration of the sprint, it is up to the team to decide. ALTEN group engineers have found that a 2-weeks delay is appropriate for most engineering projects, although the literature recommends 1-4 weeks.

All the features/components to be developed for the system, and the associated tasks, constitute a list (the “backlog”). This list is evolving. At each increment, according to the defined goal, the development team determines the tasks of the backlog to move in the list of validated tasks. These tasks must be performed during this sprint. In addition, any unfinished tasks from the prior sprint i are automatically pulled into the current sprint i+1.

• Sprint review
  
  The sprint review meeting closes out a sprint. This is not as formal as a gated review, but it allows the stakeholders to visualize the progress and deliverables. This demonstration is the key part of the sprint review. Of course, in IT it is easier, for example with an operational mobile application. In hardware, the demonstration of a product can be done with CAD models, mock-ups or working hardware. This is an opportunity for the end customer/stakeholder to give feedback to the development team. With a changing market needs, new requirements can be added, new features are added to the backlog and new goals are defined for the next sprint.
• Retrospective
  
  This meeting happens after the Sprint Review, or just after the next sprint has started. The development team can use this opportunity to identify ways to improve the team’s working process. After reviewing the previous retrospective action items, the meeting focuses on the following questions: What went well? What did not go well? What can we improve in the next sprint? The best way to do this is to gather answers in a round robin so that everyone has a chance to express himself or herself. A final question is suggested to gauge team happiness: What is one thing that will make you happier in the next sprint? This question will often find people’s deep-seated concerns about the project.

2. Visual Task board

When the sprint has started, engineers need a tool to communicate within the team about what task they are working on (in case there are dependencies), as well as their status. A dashboard is an effective way to track tasks and communicate status. You can use sticky notes on a wall, but you can also use Excel or digital tools like Trello, Axosoft and Jira.

All tasks scheduled for a sprint are therefore added to this dashboard. The different columns are:

• Approved: These are the tasks the team assigned to the current sprint during the Sprint Planning meeting. They are prioritized; the most urgent tasks and unfinished tasks from the previous sprint are on Top.
• In Progress: These are the cards that the team is actively working on. Whenever a team member starts a new card, they transfer it from the “Approved” column to “In Progress”. To limit inefficient multi-tasking, each team member ideally works on one card at a time, although this is not always possible.
• Blocked: The progress of certain tasks may be blocked by external or technical factors. For example, a delay in the delivery of definitions or components. The team leader or other members will then have to find alternative solutions to unblock the situation.
• In review: When a member has completed a task, he moves it to the list “In review”. The reviewer (e.g. system lead, project manager, etc.) reviews the completed work against the acceptance criteria on the card (which we will see immediately afterwards). If the work output meets the acceptance criteria, the reviewer moves the card to the “Complete” column. Otherwise, the card goes back to “Approved” for additional work.
• Complete: As stated above, cards in the “Complete” column have passed independent review against their acceptance criteria and are closed.

The team’s goal is to move all of the cards through the workflow, from “Approved” to “Complete”. Each task in a sprint should last between half a day and three days, have an explicit definition when a task is done. Breaking up tasks takes a little bit of practice. Tasks that are too big or inadequately defined may suffer from the “80%” or “almost” done syndrome, and inhibit quick progress and demonstration.

For example, high-level tasks in hardware design may be “Design the housing” or “Design the circuit board”.

However, if we break down the tasks, it would look like this:

When using a Visual task Board, we recommend creating a card for every task. This card contains information about the task such as title, description, owner, subtasks and acceptance criteria. As an option, the card can also be tagged with a discipline (mechanical, electrical, etc.) and project-specific fields.

With this dashboard system, there is no ambiguity around whether a task is complete and thus speeches such as “it’s 90% over” are avoided. Blocked tasks tend to be an eyesore on the board, which encourages escalation and resolution. Each completed task demonstrates visible and incremental value for the stakeholders.

3. Daily Stand-ups

They are brief daily meetings carried out by the team (standing) in order to determine possible dependencies and the follow-ups that result from them. The objective is to identify problems quickly in order to solve them as early as possible. It is very easy in theory, but in reality, you can get to that very rapidly:

There are a number of best practices to make daily stand-ups smooth running and useful:

• Set the proper cadence: some projects do not require a daily meeting.
• Limit the meeting to 15 minutes.
• Use the project manager or system engineer to ensure these meetings: they are the ones who have the overall view of the project and the product specifications in mind.
• Structure the meeting: 15 minutes is short, so each member should be focused on answering the following questions: “What have you done since the last stand-up? “, “What are you working on next? “, “Is anything blocking?”
• Look at the task board: this is not the time to manipulate it; it is up to the members to do it later. The meeting allows everyone to see the impact of task status on the work of others.
• Book a follow-up meeting.

To carry out the daily stand-up, you must absolutely avoid sitting, having an outdated dashboard, being off topic, or having too many people involved.

4. Demonstrate value often

Our goal in product development is to deliver value to the stakeholders as quickly and inexpensively as possible while still creating a quality product.

With traditional development approaches, by the time the stakeholders sees a deliverable, many decisions have been made and locked into the design. If the stakeholders disagree with the design team’s decisions, this could leads to arguments about changing requirements,… That is why Syncroness uses the concept of “Demonstrate value often”:

• Demonstrate: This is an actual demonstration of the latest features at the end of a sprint. It does not have to be a production-ready demonstration – any demonstration of the product deliverables adds value.
• Value: “All project value is embodied in its deliverables.” A deliverable is any tangible item that contributes to the commercialization of a new product. A document, a drawing, a decision, a report, a prototype, a piece of hardware or software, etc. Deliverables are outcomes of tasks and activities.
• Often: By doing demos often, we have a regular opportunity to get face time with the stakeholders. The development team can frequently compare their design with the needs of the client. The design is made more robust throughout the project.

What form can a deliverable in electrical and mechanical systems engineering take?

• Mechanical design: Brainstorming sketches, renderings, CAD mock-ups, analysis or rapid prototypes.
• Electrical: schematics, analysis, layouts, breadboards, or prototype PCBAs.
• Both: vendor selection, bill of material, cost estimates, or lead time estimates.

Each of the items above represents an incremental improvement in the evolution and understanding of the final product design. With the many deliverables that we confront the client with, we reduce risks and uncertainties, without having to build an expensive prototype.

In the field of embedded systems, integrated prototypes play an extremely important role.

Their construction allows the team to understand better the actual assembly, system behaviour, interactions between different skills, interface compatibilities, etc.

Matching the demonstration of these prototypes with the Sprint reviews requires some early planning, as the pace differs between embedded software development, mechanical design and electrical design teams.

2 examples of engineering projects carried out by ALTEN using these Agile methods

Syncroness, a subsidiary of the ALTEN group, has been able to carry out several embedded system development projects using the Agile approach described above. In particular, ALTEN group engineers have developed, from start to finish, an engine controller for a space manufacturer specialising in deployable antennas and solar panels, and critical avionics systems for the launcher industry.

• Satellite – engine controller: A new customer proposed to Syncroness to design, fabricate, assemble, test and deliver an Engineering Demonstration Unit (EDU) and a Flight Model (FM), with a 7-month deadline and a fixed budget. The product must be extremely reliable, of high quality and must meet the rigorous requirements of the American aerospace industry (AS9100 standard). In order to respect these constraints, Syncroness decided to approach the project with Agile methods. The “demonstrate value often” approach has enabled us to maintain a relationship of trust with this new customer. The greatest validation of this process was the customer feedback that “the controller continues to be a rock of reliability” throughout the testing and delivery of the overall product.

• Launcher – avionics: Syncroness has also used the Agile approach to develop a Launch Sequencer for sun-syncronous orbit satellites, or even the development of spacecraft avionics hardware. The customer was satisfied with our methodology and progress in developing their critical embedded systems, despite an “aggressive planning”.

Thanks to the application of this methodology, the engineers of the ALTEN group were able to develop the hardware within the time and budget allocated. The advantages of Agile methods applied to an engineering project are:

• Faster product development
• Higher quality deliverables
• Continuous risk reduction
• Enhanced collaboration both within the development team and with stakeholders
• More transparent and accurate project status

Publication on AIAA : Agile Hardware Development Approaches Applied to Space Hardware