agile in practice, development – critical systems – …...the team spirit and the growing...

Technical Article1 / 12

Agile in Practice

Development – Critical Systems – Scaling Agile

Agile techniques are the main facilitator for flexibility and efficiency. But how to implement agility

especially in critical systems? Methods from the textbook are hardly suitable for practice. Critical

systems with cybersecurity, functional safety or hardware components need tailored and

scalable agility. Vector has summarized here best practices for implementing agile in practice.

The article provides experiences from ABB, Bosch, Essence, Ford, ZF and Vector. Hands-on

industry case studies emphasize how to master the agile transformation for development of

critical systems.

“Agile development is applicable to practically all industries, but demands tailoring to deliver expected

improvements.” This is the summary of Dr. Christof Ebert, CEO of Vector Consulting Services, from

his experiences with introducing agile transformations worldwide. Agility helps in improving cost and

efficiency. Yet, challenges are high. Critical systems should be developed flexible and lean, but also

with distributed teams, expandable and comprehensible. Governance and compliance need to be

balanced with lean practices in the specific context. For instance, governance is necessary in safety-

critical domains and for cybersecurity to have traceable design decisions. Classic agile methods from

textbooks do not scale and are thus not fit for practice. More recent frameworks like SoS, LeSS and

SAFe are suitable for big projects, but at the same time are complex and thus bear many implementation

risks – aside from not really being agile.

Cost and efficiency has been the leading short-term challenge in the Vector customer survey "Industry

Trends 2018" (www.vector.com/trends). Vector invited companies from different industries to share their

experiences and distill guidance for engineers and decision-makers. ABB, Bosch, Essence, Ford, ZF

and Vector amongst others shared their experiences with agile transformations. Dr. Ingo Alfter, Manager

for Software at ZF set the stage with elaborating agile for critical automotive systems. Alexander Gygax,

the head of hardware development at ABB framed scaled agility for embedded systems and how

companies can benefit from such frameworks. Walter Bernet, a principal consultant at Vector brought

his many experiences and benchmarks from scaling agile in practical development projects. Edith Bakst,

the head of quality at Israeli security expert Essence shared hands-on insights from embedded agile for

IoT (Internet of Things). Helmut Bunge, manager at Bosch software campus, considered the often-

neglected activities of verification and validation of critical systems in agile development. Frank Kirschke-

Biller, manager of global software processes at Ford, integrated the experiences of an OEM on the next

higher level of agile systems engineering.

Vector connected decision makers and agile experts from various industries such as automotive OEM

and suppliers, transport, finance and IT to share their experiences and to network. This white paper

provides highlights and many take-aways on how to best implement agile in practice.


Agile Transformation

Agile is the highest-ranking technology in terms of past and future impact. This was the result of a recent

survey of prestigious industry journal “IEEE Software” together with Vector. Agile methods have been

successfully used on team level for three decades. Methods such as Scrum can be used in practically

all industries and disciplines. Even surgery teams in hospitals today use such methods to emphasize

the team spirit and the growing dependencies on each other. The problem is that such agile methods

do not scale easily. While companies with organization-wide agile culture clearly financially outperform

their peers, agility is far from trivial. To put it black and white: Agile is often considered as throwing away

established process culture, as Vector observes from the task forces it is called into when projects are

about failing.

The necessity of culture change is often overlooked. From Vector industry surveys and many worldwide

projects one figure has been constant over the years. One third of companies reach their ambitions with

change projects. More than half fail because they underestimate the change needs. Vector sees four

clusters of companies with about even distribution: One fourth of companies are agile. another fourth

are mere start-up, thus being agile almost per definition, one fourth are in bureaucratic mode, and the

final quarter is trapped in change. To summarize, half of companies practice agile, while the other half

try or do not even dare.

Agile today is everywhere in social networks, conferences and journals. There are many agile textbooks,

and it looks trivial to just copy-paste the processes described in such books. Agile practices have

evolved at a steady pace. During the early nineties Microsoft invented most of what was later called

agile. Driven by the fast-growing complexity in their Windows and Office suites, Microsoft very early

advanced concepts such as continuous build, feature-driven teams, and a close connect of business

needs with requirements and architecture flexibility. A key milestone was the Internet Explorer which

was fully re-developed in the late nineties to allow for flexible and scalable evolution. These practices

later found their way to the early agile frameworks. The initial agile manifesto based on experiences of

Microsoft, IBM and others primarily collected principles and practices. The label “agile” was a wonderful

marketing stimulus and immediately triggered a hype, specifically with small teams and low-risk

products.

But how do they scale to distributed teams for critical systems with high product liability? Industry has

realized that critical systems need more than an agile manifesto. Industry-scale software development

typically does not fit to the high constraints of early agile practices, such as extreme programming.

Projects easily take several years and span teams around the globe. Global software engineering

demands scalability of agile practices. Safety-critical systems need thorough documentation, once

neglected by agile proponents. Innovative product development with novel technologies, complex

systems, several disciplines, high compliance needs for functional safety and cybersecurity across


locations and with complex supplier networks demand highly tailored agile techniques which consider

the specific culture and constraints of the respective company. Agile must and can scale for real industry

needs (fig. 1).

Agile in Practice

Dr. Ingo Alfter, Manager for Software at ZF, has successfully completed the agile transformation on

basis of scrum for critical systems. They embedded the existing processes into scrum covering

functional safety, system engineering, software architecture and testing in the scrum team. Scrum rules

for critical systems were developed and strictly applied (fig. 2). Specifically, a “Definition of Done” was

enforced as exit criteria which maps to the ZF process expectations. All work products under version

management and planned in the same tool. Alfter claims that “transparency and participation to team

meetings is the key to success with agile.” The team was centered around architecture and integration

to ensure the consistency of work products across domains. At the same time integration focus allowed

to scale the approach across teams and sites. With this set-up ZF could prove feasibility and benefits

using agile methods for development of safety critical systems up to ASIL D, large projects with hundred

developers, and projects with different stakeholders and suppliers. The effects are obvious: Much faster

flow of information and reduced effort for communication, less misunderstandings, better alignment of

decisions, less emails and interaction with line managers, better transparency of project status and

reporting, faster risk mitigation and reaction on issues and thus significant improvement in velocity and

product quality and in-time deliveries.

Project size at ABB is even bigger with a heavy share of mixed hardware and software development.

Alexander Gygax, the head of hardware development at ABB highlights the specific challenges and

ABB solutions. Scaled agile was used as knowledge base of proven, integrated patterns for

implementing lean-agile development. Around 20 teams with over 200 engineers are synchronized to

sprints and program increments, practicing agile ceremonies, such as daily scrum, sprint planning and

review, retrospectives, inspect and adapt, system demo, scrum of scums, etc. The main principles are

continuous integration, develop on cadence and release on demand, supported by build and test

automation. Collaboration across very different product lines was achieved with a rather traditional

release model enhanced with a sophisticated interface between agile and waterfall methods. This

coexistence allows a smooth transition with classic to agile development. Hardware development is also

part of the agile development (fig. 3). ABB runs a parallel and synchronized hardware specific agile

release train which delivers in a defined rhythm. His recommendations to transfer the results:

Implement strong requirements engineering for effective handling of scope changes;

Increase productivity while optimizing the agile overhead,

Remove old roles when adding new agile roles;

Simplify capacity planning and extract performance metrics with adequate tool support


Use one tool for development for all agile teams rather than organically grown multiple tool

environments

Try things out, explore the unknown, create opportunities. When you fail, just iterate

Results speak for themselves. The program Increment planning enables the Business Owners to refine

the scope according to latest market needs. Scope changes do not mess up project plans anymore but

help us to be faster (when needed), more customer oriented and more cost effective. And most relevant

for any development organization: On-time delivery of committed milestones has improved.

Business models in software-driven systems have evolved to flexible eco-systems. Walter Bernet, a

principal consultant at Vector, points out that the classic functional split demanded by legacy-driven

architectures is replaced by a more service-oriented architecture and delivery model. Recent technology

trends such as three-tier cloud architectures, adaptive component frameworks, and connectivity for

Internet of Things (IoT) and Internet of Services (IoS) facilitate new business models and scalable reuse

across companies and industries. Scaling of agile practices is necessary to cope with these industry

constraints. However, scaling is not easy, as large projects often are globally distributed, and have many

teams that need to collaborate and coordinate. So far proven models have not been available. He

outlines four case studies form very different industries and with different scope. They have in common

that they address critical systems. Requirements, architecture, dependability and organization are the

four dimensions which Vector addresses with its ACE (Agile for Critical Engineering) method. A

cornerstone as ZF already pointed out is agility for requirements and architecture (fig. 4). Bernet uses

the “triple peak” analogy to synchronize early between requirements, architecture and test. He

concludes from Vector projects that agile must be scaled according to the specific environment which

needs experienced support. The current large recipe-style frameworks often do not address the real

industrial needs, such as compliance. In line with ABB he emphasizes the symbiosis of agile elements

with state-of-the-art engineering methods, rather than only thinking agile – and missing on content and

integration.

“Agile is not a process, it is a state of mind” underlines Edith Bakst, the head of quality at Israeli security

expert Essence. In line with ABB and Vector she emphasizes the need for gradual process

implementation. Agile methods are necessary also for the agile transformation itself. Increments

facilitate fast learning and roll-out. Agile change teams ensure that people are on board. There is no

“out of the box”, and one should not assume that just using some parts will provide early pay-back. Agile

is a transformation and as such must start in the minds of employees to be ingrained into the company

culture. Applying agile to critical systems such as IoT demands an even more comprehensive look to

change management. There are many functions and experiences to be considered in such change

program. Rather than simply looking to a process or workflow like in the mainstream agile frameworks,

Bakst suggests working in a phased and hybrid approach which allows a steady evolution of process,

roles and tools in parallel (fig. 5). Her claim: It is not only the team level that needs to transform, but the

whole organization. And this takes time, budget and senior management commitment.


Safety is a key concern in most critical systems. Agile development is necessary due an increasing

number of updates after SOP, for instance security driven. This requires fast update of safety analysis

and related documentation. Helmut Bunge, manager at Bosch software campus, underlines:

“Development releases have to always know the safety status of all underlying artefacts.” Cycle time

must improve but quality must not be compromised. His vision at Bosch is quite simple. There should

be processes for a safe and secure product release within four hours with formal approval process incl.

documentation. This allows to react fast to cybersecurity attacks with safety impact. The challenge is

that frequent and late changes in safety related product development are often hindered because they

take too much effort to release with right quality level. But he thrives on Bosch solutions. With his projects

he concludes that integration of safety and cybersecurity in agile projects is possible and has benefits if

the following conditions are fulfilled: The safety team is integrated in the agile team with safety manager

and safety engineer. The agile team has necessary safety and security competences. There is sufficient

tool based traceability with requirements, architecture, tests, change sets etc. is established. Safety

tooling must support interfaces to design tools covering system, software and hardware engineering (fig.

6).

Systems engineering brings even higher challenges in agile adoptions. Frank Kirschke-Biller, manager

of global software processes at Ford, highlights the major demands. Systems Engineering, including

requirements Engineering and MBSE (model based systems engineering) is an engineering discipline

that can be implemented using different approaches, such as classic project management, covering

waterfall with staged-sequential or concurrent deliveries, incremental, and agile project management.

The main challenge in agile systems engineering is that the target is defined and evolving during

development based on iterations. As such the development is not primarily driven by a process but much

more by the product. A cornerstone at Ford is a feature-based process utilizing features broken down

into functions and software components based on information model, enterprise wide feature dictionary,

feature implementation planning as backlog input for ECU development in an orchestrated approach,

prioritization and definition of minimum viable product, and periodic integration phases for the solution

train. As an OEM he sees the critical dependencies on suppliers: “Agile systems and vehicle engineering

demands full transparency from and with suppliers” underlines Kirschke-Biller. This includes regular

software maturity reports from suppliers with alignment on delivery dates, feature based implementation

and test status report ro allow earned value management, full transparency on open issues, tool

integration with defined interfaces between OEM and supplier, and coordination and traceability of

distributed features to close the loop.

Agile Evolution

Agility has arrived in real-world development, beyond mere software applications. Development of even

critical systems will evolve to a continuous process which will fully decouple the rather stable hardware

from delivered services driven by continuous software upgrades. Agile service delivery models

combining DevOps, micro-services and cloud solutions will allow functional changes far beyond the


traditional V approach. Hierarchic modeling of business processes, functionality and architecture from

a systems perspective allows early simulation while ensuring robustness and security. Development

processes across the entire life-cycle from vision to concept to operations and service will follow this

trend to fluid delivery models.

Since constraints vary across application domains, such as liability and governance risks, agile practices

need to be tailored to needs and risks. To address such tailoring, companies use agile scaling

frameworks. They seem to provide a complete framework for the whole organization. From working with

many companies worldwide on introducing agile scaling frameworks we underline that agile means a

change of culture and mindset. It requires long-term commitment, big investments and customization to

each company’s specific situation.

Here are some practical recommendations that we identified in Vector projects:

Move from classic functional responsibilities to cross-functional flexible teams. Grow

methodologies and the underlying technologies to agile engineering.

Enhance the lifecycle for continuous development. Using frequent synchronization points

change the V model to the W model. Focus on integrity by establishing flexible synchronization

points between hardware, software, and service development along the lifecycle.

Empower distributed teams, both internal as well as suppliers and eco-system partners to drive

design decisions at their respective level. Ensure consistent documentation with collaborative

workflow tools.

Grow continuous integration of systems and services. Introduce integrated processes and a

systematic methodology based on application life-cycle and product-lifecycle management

(ALM/PLM) tool chain.

Ensure robust system-level design. Approach novel technologies at the system level: system-

on-chip, microservices, and cloud solutions for innovative products and services.

Master relevant quality requirements for critical systems. Cybersecurity, functional safety,

service orientation, and usability must be designed and achieved on the systems-engineering

level.

Enhance reuse across platforms, products, and markets. Evolve to self-x-type architectures and

technologies such as self-aware adaptive systems to cope with fast-changing components and

environments.

There are no limits anymore which would prohibit using agile. Globally distributed teams, large projects,

safety-critical systems or hardware and systems engineering all have showed that agile technologies

can be adopted and adapted. Agile scaling is not about tailoring a model, but ensuring that the agile

culture arrives at the engineers and their management. The biggest and the most difficult change is the

mindset change. Changing only the practices does not make a company agile if the underlying culture

and thinking does not change. Dr. Christof Ebert of Vector demands that organizations move ahead and


quotes famous writer and politician J.W Goethe: “Knowing is not enough, you must apply. Willing is not

enough, you must do.”

For more information on agile transformation and current technology advances plus access to the

mentioned presentations and videos, please visit: www.vector.com/consulting


Figures:

Figure 0 / Teaser image

Image rights: Vector Consulting Services

Figure 1: Scaling Agile for Industry Needs.



Figure 2: Scaling Scrum.

Image rights: ZF

Figure 3: Scaled Agility for Embedded Systems with Hardware Focus.

Image rights: ABB


Figure 4: Scaling for Requirements: The Initial Step to Value Creation


Figure 5: Gradual Process Implementation

Image rights: Essence


Figure 6: Tools support for consistency in agile development

Image rights: Robert Bosch

Figure 7: Agile Systems Engineering

Image rights: Ford


Author:

Dr. Christof Ebert is Managing Director of Vector Consulting Services. Tel. +49-711-80670-1525 E-Mail: [email protected]

Revised: 17. August 2018

Character count: 3100 words, 21500 characters (including space characters)

Press Contact: Vector Consulting Services, Germany Stuttgart Ms. Anh KIm Phone: +49 711 80670-1535 E-mail: [email protected]

About Vector Consulting Services (Revised: August 2018):

Vector Consulting Services is a globally active consulting firm with focus on development and IT, transformation processes and

interim management. Renowned companies from automotive, information technology, manufacturing, transport and aerospace

rely on the professional solutions and pragmatic implementation. A subsidiary of the Vector Group with over 2000 employees,

VCS supports its clients worldwide with sustainable consulting solutions covering the entire life cycle and the related

infrastructure. To ensure independent and customer-oriented consulting the firm is managed by partners.

Details and further information: www.vector.com/consulting

agile in practice, development – critical systems – …...the team spirit and the growing...

Documents