Starting Agile Development of Systems – The Top 5 Questions

There is an increasing interest in developing hardware and systems in an agile way. In October 2018, the participants of the Agile Systems Conference in Munich (ASK) discussed some of the most interesting questions within an Open Space.

Agile Development of Hardware and Systems

Agile Systems Engineering (agile SE) is a hot topic in the development community. One the one hand, many people doubt if agile development is possible not only for software but also for hardware and systems. On the other hand, companies like WIKISPEED, SAAB, MAGURA, BLUNK Electronic etc. already build cars, aircrafts, e-mobility components and printed circuit boards in an agile way and with great success.

Open Space Results

The ASK offered an Open Space to discuss questions and topics of participants. The following top 5 questions were discussed. The results reflect approaches when starting agile SE:

1.  How to empower teams?

What is important for agile teams? To answer the question, how to empower teams, we first asked the opposite “How to de-power teams”. A bunch of bottlenecks in teams have been identified:

• No culture of failure:  failure-free results are always expected
• Part time teams: developers work on several projects et the same time. Working on more than one project can incur switching costs and decrease performance.
• Missing “error-culture”: always error-free results are expected.
• Part time teams: every person is juggling with several balls, means that every developer has several projects. To work on multiple projects does not help to multiply the output.
• Procedures for offering and purchasing process are too rigid: Central purchase departments often suffer from fixed offer procedures. Purchaser agents currently prefer to look for the best prices for several months instead of buying fast and driving the project by long-term co-operation with a well-proven supplier.
• Unclear and changing priorities in the project.
• Unclear assignment to a team.
• Projects starting without sufficient resources (e.g. persons or budget) while keeping the project deadline fixed.
• Personal goals, such as career goals, are more important than the project goal.
• Lack of transparency in the processes and the development
• Distributed work: Many people are not used to work with distributed teams.
• No personal engagement for the project.

2. How can hardware and software teams work together?

Most software teams are already working in an agile way, often by applying Scrum. Mapping Scrum directly to hardware teams seems to be a challenge. Most problems seem to arise from fear, uncertainty and lack of knowledge. “Agile” does not mean that everybody can do what and when he/she wants. What are the current problems?

• Different HW and SW life-cycles: People think, that the life-cycles of HW and SW are too different. There exist the fear, that SW has to wait a long time before getting a running HW.

But this fear seems to be an excuse. More important reasons are found in the new “agile” (and thus, unkown) principles and methods:

• People in managing roles fear to lose influence: HW- or SW-“Managers” do not see a adequate agile role for them. So, they are afraid to lose influence in their domain when giving up to work in silos.
• Also engineers fear to lose influence: Some engineers are concerned that their personal  contribution won’t be noticed or respected anymore if the team start working cross-functional. A work environment fostering individual performance, results and competences, using a specific vocabulary more motivating to individual. Silos with its own language and culture will not be understood completely by other domains, so that it creates some impression of “competence” and “excellence”.  “I do not understand” shall lead to “it must be very sophisticated and complicated”. Here, an identification with the overall-system is needed. The agile principles of working feature oriented and creating value frequently would help.

3. How can scaled agile frameworks help?

One focus was on the agile frameworks LeSS and SAFe. Other frameworks, such as Scrum@Scale, Nexus and the Spotify Model were not explicitly addressed in that session.

“LeSS” is a bottom-up approach, seems easier to scale existing agile work. It offers free room for bottom-up structuring.

“SAFe” is better fitting to include existing management into the scaled agile methodology. In the SAFe framework, everyone can keep its old role, but with other names. This is both an advantage and a danger of this approach because the old structure might continue to exist under new names, and the introduction of agile mindset, agile principles may therefore be missed.

Central questions to decide for an agile way are:

• Do I have to work agile or is it only a hype?
• What is the problem I want to solve?
• How many self-organization needs my company
• Where do I start?
• Which framework do I use?

4. What are best practises to start with agile HW and systems development?

To start agile HW development we need some best practices. A better planning and forcasting of HW development is a big topic. We have collected some of the best practices and bottlenecks to avoid:

• Agile HW enlarged: The agile mindset must be enlarged throughout the whole company. Especially in automotive and other very big companies the mindset of processes and plan-driven methodologies is not yet changed to agile.

• Use of an Extended Scrum Board, to better follow the working progress.

• Not only development teams should work agile, but also their environment, like managing, sales and purchasing departments.

• Modularisation: a good and new modularisation of the system enables teams to work agile.

• Do pre-studies. This helps to get the right “big view” for the HW development. A well-thought very-basic architecture of the system right at the beginning is helpful.

• Better preparation of HW development through frontloaded development of some components to mitigate the risks early.

• Too few HW-prototyping are produced. First prototype is often produced very late, e.g. as an so called “A-Sample”, that is already a magic black box. Earlier Prototyping would be very helpful, and eases implementation in steps and leads to a “continuous integration” in long-term.

• Lead times of HW have to be respected and to be integrated. Here, adapt velocity of teams, but not too often.

• Respect velocity in HW in planning and forecast, not only measure it.

• Velocity and Planning Poker works successfully also for HW teams.

• Too many layers: Have only a few layers of the product break-down structure and organisational.

5. Is it time to leave the V-Model paradigm?

The V-Model is a paradigm for development processes. It defines phases in a V-shaped form, defining activities like customer requirements elicitation, requirements quality assessments, certification, tests, acceptance tests, dev-ops concepts, simulation, validation, prototyping. This inherently builds walls between the single process steps. This system currently seems to be overdriven and foolish.

Break the paradigm by replacing it with other paradigms:

1. Simulation and prototyping brings early break throughs in a much faster way.
2. Define more MVPs (Minimum Valuable Products) for simulation and prototypes. For production this means flexible production lines.
3. Infrastructure as code provides a build-in flexibility.
4. Adapt standards and norms for innovative product life-cycles. This needs a lobby.
5. Early prototypes, frequent feedbacks from customer, possibility of back-steps (in layers) must be allowed.

Top-5 Questions as a Booster

Considering these five questions will leverage the start for agile Systems Engineering. Applying Agile in the development of hardware, systems and systems-of-systems stays an interesting field in the near future. A participant even stated: “Our work is currently so inefficient, that a change is in-evitable!”. Although agile doesn’t seem  easy and is not yet a common practice, many companies successfully do agile systems engineering already. The participants of the ASK 2018 were happy about the possibility to collect new ideas and to exchange questions and thoughts. Agility in Systems Engineering is only a question of mind set.  And, as Dr. Jörgen Furuhjelm from SAAB Group commented: “Agile in hardware takes the development to a new level. With the teams working focused and synchronised the efficiency is boosted. SAABs next fighter airplane is developed in record time.”

If You are more interested in agile systems engineering, agile hardware and systems development, and agile requirements engineering, I recommend to follow the Agile Hardware and Systems Group on LinkedIn and XING. And, last but not least, do not miss the greate requirements engineering conference REConf 2019 in Munich, with outstanding workshops, keynotes and presentations. Choose Your preferred days within 11. – 15. March 2019:

•