agile embedded software development, what's wrong with it?

agile42 | We make your Agile transition succeed! www.agile42.com | All rights reserved. Copyright © 2007 - 2014.

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?


Andrea Tomasini

Agile Coach & Trainer [email protected]

@tumma72@agile42/coaches

mailto:[email protected]


Bent Myllerup

Agile Coach & Trainer [email protected]

@bentmyllerup@agile42/coaches

mailto:[email protected]


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 specifically 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 first 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


Release incrementally, with higher quality

Automated testing in short cycles

Delivered serviceable Product in just 2 months


19” Backbone Product New standards for real time processing…


From Matrix Organization to Focus on the Business

Product Management

Hardware Line

Operations

Software Line

Mechanical Line

Project Office

Proj

ect

#1

Proj

ect

#2

Proj

ect

#3

Proj

ect

#4 Business

Unit #1Business Unit #3

Business Unit #2

Operations

Busin

ess M

anagem

ent

Analog

Analog

Analog

Construction

Construction

Construction

Business Management

Busin

ess M

anagem

ent

DigitalDigital

Digital

FPGA

FPGA FPGA

C++C+

+

C++

DSP

DSP

DSP

Simmulation

Simmulation Simmulation

Safety

Test

Test Test

Design

Design

C

C

C

EMC

EMC

EMC

User Domain

User Domain

User Domain

• Business Units formed as self-organized Scrum teams

• High diversity in skills - true cross functionality

• End-to-end responsibility for the project (including the business case)

• Focus was now making fantastic products rather that being fantastic at some technical practice


New Platform Project the Agile Way

Vision

Custom

er and

User N

eeds?

What?

Why?

Worth

doing?

Technology?

Product Backlog

Velocity!


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 find 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.


Statement #5

“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

1.2.

3.


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 final 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


Cultivation Competence

Control

Peopl

eIm

personal

Actuality

Possibility

Collaboration

William Schneider - The four Core Cultures

Agile Values & Principles


Experiences

Beliefs

Actions

Results

CultureMan

age

Lead

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

shift

the

balanc

e

coaching is an ongoing long term investment


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

agile42 | We make your Agile transition succeed! www.agile42.com | All rights reserved. Copyright © 2007 - 2014.agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.

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


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


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


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


Thank

You!


More food for thought...

http://slideshare.net/tumma72

http://slideshare.net/tumma72

https://itunes.apple.com/de/book/agile-transition-what-you/id550957382?ls=1


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

http://creativecommons.org/licenses/by-nc-sa/3.0/

agile embedded software development, what's wrong with it?

Technology

potential

agile transition

statement

statement

agile coach

automated

rights reserved

earth calling