Agile Embedded Software Development, what's wrong with it?

Agile Embedded Software,
what's wrong with it?
We are in 2014 and still someone is challenging the fact that you can't use an Agile
approach to develop embedded systems, why?

agile42 | We make your Agile transition succeed!

www.agile42.com | All rights reserved. Copyright © 2007 - 2014.

Andrea Tomasini
Agile Coach & Trainer
andrea.tomasini@agile42.com
@tumma72
@agile42/coaches



Bent Myllerup
Agile Coach & Trainer
bent.myllerup@agile42.com
@bentmyllerup
@agile42/coaches



A bit of context



What is embedded software development?
In system engineering we refer to embedded software when pointing at
the software required to operate the system. As the system is the
Product, and entails dedicated hardware components, it requires
speciﬁcally developed drivers, and run often on custom real-time
operating systems…



System Engineering = integrated products

Value



Why Agile doesn’t work in
Embedded…



Statement #1

We cannot have potential
releasable functionality in four
weeks or less!


Statement #2

There is to much diversity in the
required skills for a cross functional
team…


Statement #3

First we must develop the
hardware, then comes software. It
cannot be done in parallel


Statement #4

Continues integration and
automated test does not work in
hardware development


Statement #5

“Welcome changing requirements,
even late in development” - Hello,
Earth calling the agile coach!


Statement #6

Lead time can be six weeks or
more…



Statement #7

User stories do not work for
embedded system development



Our Experience…



Optical Network
Infrastructure

Ericsson R&D for Optical Infrastructure


End-to-End global
product development
• Classical Engineering approach
with separation of:
• Requirement Engineering
• Hardware Development
• Software Development
• Distributed teams across the
globe in 4 different locations



Challenges
• Release cycles and feedback loops very long, with major
product releases happening in 12 to 18 months cycles
• Very high business risk, multiple customers requests merging
into a single product release
• high number of competing change requests, very tight
deadlines
• Distributed development requires a lot more of synchronization
to work, and detailed planning up-front (really?)
• Average time before full test integration over 6 months, for ﬁrst
service-able hardware prototypes
• Split responsibility distributed on a large number of roles,
cause delay in decision making, in particular by issue handling


• Fully distributed cross-functional HW+FW+SW Teams with up to 10 people
• Pairing over 2h timezone overlapping (Italy & China)
• Team focusing on Features and not technology


Automated testing
in short cycles
Delivered
serviceable Product
in just 2 months

Release incrementally,
with higher quality



19” Backbone Product

New standards for real time
processing…

From Matrix Organization to Focus on the Business
Project Ofﬁce
Project #4

Project #3

Project #2

Project #1

Business
Unit #1

C

g
Analo

Business
Unit #2

DSP

EMC
Digital

De
sig
n

Digital

t
en

C++

em

DSP

Test C

ag
an
M

EM
C

s

es

Simmulation
User Do main nt
e
m
Tes
ge
t
a
+
an
M
C+
s
es
Design
in
us
B
FPGA

sin

Con
stru
ctio
n

ion
truct
Cons
FPGA
on
mulati
Sim
User Domain

Bu

Product Management
• Business Units formed as selfHardware Line
organized Scrum teams
• High Line
Softwarediversity in skills - true cross
functionality
Mechanical Lineresponsibility for the
• End-to-end
project
Operations (including the business
case)
• Focus was now making fantastic
products rather that being
fantastic at some technical
practice

Ana
log

Business
Unit #3

ain
User Do m
nt
e
m
e
Dig ital
ag
an ++
M C
C
s
s
ne Analog
i
us S
B
im mu
lation
Co
nst
ru
cti
on
Test
EMC
ety DS
Saf
P
FPGA

Operations


New Platform Project the Agile Way

nd
ra
e
?
om e ds
t
s
Cu r Ne
e
Us

Wh

at?

hy
W

?

Technology?

Vision

th
r
Wo g?
in
do

Velocity!

Product Backlog


From First MVP to Final Product
1.

2.

3.



Busting the Myths…



Myth #1
We cannot have potential releasable functionality in four
weeks
!

•The important thing is that you show agreed and valuable
results every sprint. Challenge yourself (and the
organization) to ﬁnd alternative ways to verify your designs


Myth #2
There is to much diversity in the required skills for a
cross functional team
!

•The more the team is cross-functional the less you
will have to deal with hand-over, reducing waste


Myth #3
First we must develop the hardware, then comes
software. It cannot be done in parallel
!

•With cross functional teams and clever ideas on
developing Minimal Valuable Products, that is not
necessarily a fact!


Myth #4
• Continuous integration
and automated test does
not work in hardware
development
!

• Several vendors are
actually offering tools that
can help you with this.
Some times making an
automated test tool is
actually more fun than you
ever expected.


1.

Statement #5

2.
3.

“Welcome changing requirements, even late in
development” - Hello, Earth calling the agile coach!
!

• Building iteratively and incrementally by validating
requirements on the way, reduces the stress of
changes and the risk


Statement #6
Lead time can be six weeks or more
!

• Is this really a “must” or is a choice that can be revised?
It doesn’t have to be the ﬁnal hardware, and you can
decide to reduce the lead time and increase the
production costs, by developing few samples locally…


Statement #7
User stories do not work for embedded system
development
!

• User Stories help focusing on the value instead of
the technology, and allow to develop optimal
technology to solve the given problems


Now let’s look at the culture



Actuality

Agile
Values &
Principles

Cultivation

Control

Competence

Possibility

Impersonal

People

Collaboration

William Schneider - The four Core Cultures

e
Ma
na
g

if
ba t t
h
la
nc e
e

Beliefs

Le

sh

Culture

Actions

ad

Results

coaching is an ongoing
long term investment

Experiences

The “Results Pyramid” is copyright of Partners in Leadership LLC


From Individuals or Groups to Teams

In a complex world, team
organization is the best answer
to coping and handling the
complexity and chaos in projects


1. Agile is simple but isn’t
easy, and applying it to system
development might be tricky…
but worth the effort!

agile42 | We make your Agile transition succeed!building software
advise, train and coach companies

www.agile42.com | | All rights reserved. Copyright © 2007 - 2014.
www.agile42.com
2009.

2. Remember to focus on Value
ﬁrst, and on technology later!


www.agile42.com
2009.

3. Agile is a new paradigm
rather than a new “method”
it’s about thinking different!


www.agile42.com
2009.

4. Start by challenging the
constraints, and understand
how are they limiting you
from delivering shippable
products in short cycles!


www.agile42.com
2009.

k
n
a
h
T
!
u
o
Y



More food for thought...

http://slideshare.net/tumma72


Copyrights notice
All material produced in this presentation is protected by the
Creative Common License 3.0 (by-nc-sa).



Agile Embedded Software Development, what's wrong with it?

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à Agile Embedded Software Development, what's wrong with it?

Similaire à Agile Embedded Software Development, what's wrong with it? (20)

Dernier

Dernier (20)

Agile Embedded Software Development, what's wrong with it?