20161115 Agile in Automotive: "Balanceability is the new 'Agile'"

CC SSE Much | 2016-10-15 | Agile in Automotive 2016 | Public | © Elektrobit Automotive GmbH 2016.All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.

BalanceabilityTM

is the new “Agile”

Alexander Much2016-11-15



Overview

BalanceabilityTM is the new “Agile”

• Unbalanced: “Agile” Consulting

• No-go’s

• Balanceing

• Beyond “Agile”

2


About EB


3

Technical competenciesEB’s technical core competencies are development of automotive-grade (software) products and engineering services.

EmployeesMore than 1,900 employees worldwide. Spans three continents and nine countries.

Continental AGWholly owned subsidiary of Continental AG.

90+ millionOver 90 million vehicles on the road and 1 billion embedded devices.

Global presenceDevelopment and business offices in Austria, China, Finland, France, Germany, India, Japan, Romania and USA.

Consistent growthHeadcount growth in 2015: 7.2 %


EB –Automotive Software


4


Unbalanced:Today‘s „Agile“ Consulting



Agilista


6

„A practitioner of Agile Software Development who is fanatical about hewing to the Agile Manifesto.”

Urban DictionaryCoined by J.F. Kelley for a Keynote Address given to the World Usability Day conference in Dayton, OH, November

2007.

Further uses can be found:Gabrielle Benefield: „Agilistas are killing the planet“ in „If Agile is so good, why are our Products so bad?“ (Presentation, Video)

http://www.urbandictionary.com/define.php?term=Agilista

http://gotocon.com/dl/goto-aar-2012/slides/GabrielleBenefield_FrankenbuildsIfAgileIsSoGoodWhyAreOurProductsSoBad.pdf

https://www.youtube.com/watch?v=2JNXx8VdbAE


Lean / Taylor Test


7

Do you think people are the problem and process is the solution?

You are a taylorist thinker

Do you think process is the problem and people are the solution?

You are a lean thinker

Do you think this attitude is a problem?

Found in a scrum group on LinkedIn

Read up on „Taylorism“. „Lean“ and „Scientific Management“ are opposing? Really?

https://en.wikipedia.org/wiki/Scientific_management


Example: How to sell “Scrum”


8

“The expected return on investment of Scrum is usually around 1:10.”

(The same source claims a return on invest for XP of 1:37 … )

“The average cost for introducing Scrum into an organization is approximately $7,500 for every employee for training and guidance.” [Consultants: ]

“With an ROI of 1:10 the realistic return [!] on this investment is $75,000 per employee per year”.

“The most important added value of Scrum, however, is the increase in agility. In the current market it’s essential to be able to respond to change quickly. The practical costs of not being able to change directions are very high. Sometimes you’ll even end up paying the ultimate price”. [FUD* usually does the trick ]

It needs to be noted: “Scrum” has nothing to do with an organization being “flexible”, “adaptive”, “resilient”, “controlled”, “agile” or being able to change itself.

It’s a pseudo-team model with iterative planning. Rini van Solingen, SCRUM for Managers, 2015

*Fear, Uncertainty and Doubt


“Stone Age” vs. “New World”


9

0

5

10

15

20

25

Programming(Craftsmanship)

SW Engineering(Taylorism,

"Command & Control")

XP, Scrum, et al("Agile")

Scrum + Lean (?); DevOps (?)

The Mind-Setting Curve

"Productivity" (not really defined)

Time


The Consultant‘s „Neat Solutions“


10

For a consultant it is tempting to sell the same solution to many customers:

“I don’t know your problem,

but I have a solution for you”

“[…] there is always a well-known solution to every human problem — neat, plausible,

and wrong.”H. L. Mencken, New York Evening Mail, 1917

https://en.wikiquote.org/wiki/H._L._Mencken


Example: „Agile“ Trainings


11

Can be performed by consultants with only moderate or no knowledge of “XY”.

“Traditional” outcome: a person is trained by a specialist in “XY” for 3 days.

“Agile” outcome: a person is trained by a specialist in “XY” for 1 day.

Even worse: it may just be about selling certificates.

XY„Agile“ Training

1 day 1 day ½ day: „merge“ & discussion½ day: certificate


The „good old days“ of Consulting


12

“Never promise more than ten percent improvement.”

“If you happen to achieve more than ten percent improvement,

make sure it isn’t noticed.”

G. Weinberg, The Secrets of Consulting, 1985


Satire (?): The Anti Agile Manifesto


”We have suffered through countless consultants and hours of meetings. Through this we discovered that Agile is simply the obfuscation of common sense – the bewitchment of the mind through language. We have learned that

epics are really just projectsstories are really just use cases

sprints are really just workstand-ups are really just meetingsiterations are really just versionsbacklogs are really just to do lists

backlog grooming is really just planningburn-down charts are really just earned value charts

velocity is really just outputand that tasks, in fact, are really just tasks.

That is, while the concepts on the left are often presented as groundbreaking or unique, they are merely weakly defined versions of those on the right.”

13

http://antiagilemanifesto.com

http://antiagilemanifesto.com/


No-Go‘s



No-go #1: User Stories are Requirements


Reason 1:

• User stories are part of planning and project activities.

• User stories do not reflect the product!

• But: requirements do, they are a property of the product

Reason 2:

• Lack of up-front generalization („do the simplest solution“)

• The system won‘t work for any other use-case (-> similar to TDD)

• Non-functional requirements or system aspects are not taken into account

15


No-go #2: YAGNI (You Ain‘t Gonna Need It)


„And those things called requirements?

They are really candidate solutions; separating requirements from implementation is just another form of handover.“1

Do you want Reuse? Changeability? Maintainability? Portability?

• All these need to be explicitly designed.

• Rejecting the concept of generalization is just bad engineering.

• „Agile“ projects require excellent impact analysis capability => tracing more important!

• Latest related hypes „inner source“, „minimal viable product“.

„A product may happen to be software,

but software itself is never a product“2

16

1Poppendieck, 20102G. Weinberg, 1985


Complexity: „additive“ and „multiplicative“


Additive complexity: the features are simple and you can add them one by one

Multiplicative complexity: the features are already complicated and they interact with each other.

„I can live with something simple that works properly. The complexity can be folded later.“ (from collab.net)

„These days we do not program software module by module, we program software feature by feature.“ (Cohn 2006)

„Experience to date indicates that low-cost refactoring cannot be depended upon as projects scale up.“ (Boehm, 2004)

People need to be aware of non-linear effects and relations in system engineering!

17

Lasagne (additive)

Linguine (multiplicative)

See e.g. Neil Johnson, „Two‘s Company, Three is Complexity“, 2007


No-go #3: Take it (all) or leave it


Some “Agile” approaches state and consultants measure the “agileness” as achievement:

take it

or

leave it

I.e. “Our method only works if applied fully and unchanged”.

A social dynamic then unfolds, often ending in a “Police State”:

“If the project failed or is in trouble, you weren’t ‘Agile’ enough”

See G. Weinberg’s “First Law of Bad Management”:

“If something doesn’t work:

do more of it”

18


Balanceing



About „Agile“ Texts


Some „Agile“ methods are amongst the most important contributions to software and systems engineering of the last decade.

But:

„Agile“ texts aren‘t easy to read, there is a mixture of:

• Brilliant insight

• Harmless platitudes

• Freakish advice guaranteed to damage your software process and products

Depending on the author „Agile“ texts sometimes or frequently contain:

• Partisanship: religious favor which often defies rational discourse

• Intimidation: established approaches are „passé“, they are simply labeled „waterfall“, „taylorists“, „command & control freaks“, „waste“, etc.

• Extremism: „take all or leave it“, „my methods works for all organizations“20


Some Reading #1 (“basics”)


21

This list is not meantto be „complete“!


Some Reading #2 (“Agile”)


22

This list is not meantto be „complete“!


Where is the Enemy?


„Agile“ is defined negatively, not positively: „I‘m not this“ or „I‘m less of this“.

The „waterfall“ in its idealized form

is an „Agile“ invention!

Here is the real reason for religious zeal and unfruitful discussions:

A non-existing enemy that you can attribute to all negative things you want.

Sceptical? Find out yourself, e.g.:

Royce, 1971, „Managing the Development of Large Software Systems“ (the „evil“ paper)Weisert, 2003, „There‘s no such thing as the Waterfall Approach!“Olson, 2014, „Waterfall“ (most comprehensive)Boehm, 2006, „A View on 20th and 21st Century Software Engineering“

23

https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

http://www.idinews.com/waterfall.html

http://www.bawiki.com/wiki/concepts/sdlc-process-models/waterfall/

http://sunset.usc.edu/events/2006/CSSE_Convocation/publications/BoehmViewof20thand21stCenturySE.pdf


Process and Method Comparison


24

Levels of Concern Life Cycle Coverage Main Areas

Meth

od

Bu

siness

Enterp

rise

Bu

siness

System

Mu

lti-team

Single-Team

Ind

ividu

al

Co

ncep

t

Req

uirem

ents

Design

Develo

pm

ent

Main

tenan

ce

Man

agemen

t

Techn

ical

Risk /

Op

po

rtun

ity

Measu

remen

t

Scrum

Lean

Crystal

XP

RUP

PSP

TSP

CMMI

Barry Boehm, Balancing Agility and Discipline, 2004(shortened and re-ordered)


The Spread of Scrum


Scrum is by far the most common “Agile” method nowadays.

• Team setup easy to understand. (Only at first! Then it’s a nightmare.)

• Methods for organizing things.

• Requires no knowledge about technology, of the organization or the domain.

Shift from technical (e.g. XP) to organizational-only methods.

Therefore: it is the darling of the consultants and now feeds an entire industry.

E.g. see the attempts to “scale” Scrum or use it for non-software areas (“’Agile’ Gardening”).

See, e.g.M. Church, “Why ‘Agile’ and especially Scrum are terrible”H. Makabee, “The End of Agile: Death by Over-Simplification”

S. Wolpers, “Why Engineers Despise Agile”

O. Vishnepolsky, “Agile does not work! And never did!”

25

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

http://effectivesoftwaredesign.com/2014/03/17/the-end-of-agile-death-by-over-simplification/

https://age-of-product.com/engineers-despise-agile/

https://www.linkedin.com/pulse/agile-does-work-oleg-vishnepolsky


A Consultant “measures” “Agility”


Organizational need: “We need better communication”.

Consultant: “Introduce a scrum-by-the-book meeting setup”.

1. Conduct trainings, perform frequent coaching, etc. ($$$)

2. Introduce Scrum-Meetings. Terminate established communication channels.

3. Use checklists, e.g. “project teams perform daily stand-ups”.

4. Measure the “degree of agility” by measuring compliance.

Do you get better communication?

• Very often fewer meetings are then considered “not ‘Agile’ enough”.

• Fallacy: you measure “effort spent”, but not what has been achieved!

Focus on outcomes! Not methods or compliance!

26

See e.g. G. Benefield, „Agilistas are killing the planet“

http://gotocon.com/dl/goto-aar-2012/slides/GabrielleBenefield_FrankenbuildsIfAgileIsSoGoodWhyAreOurProductsSoBad.pdf


Introducing „Agile“ the Right Way


“The change to agile methods will be most successful in those organizations with an agile management approach to converting to agile methods.

Unfortunately, I’ve observed a number of organizations where agile methods are introduced like a waterfall project: a huge up-front planning effort, then an attempt to convert an entire organization at one fell swoop.

To be successful, the conversion has to be in small increments, with corrections made at each increment.”G. Weinberg, Agile Impressions, 2015

This also means that you cannot know in advance what the result will be.

Change needs to be actively managed! That’s what management is for!

(That‘s why the same consultants now sell you „change management“ ;-))

27See G. Weinberg, Software Quality Management IV, „Anticipating Change“


Example: Selecting Projects and Methods


Influencing factors:

1. Type of personnel

2. Dynamism

3. Culture

4. Size

5. Criticality

The selection of methods depends on business needs, the culture, the organization, the project and the people.

Balanceability is the key.

28© B. Boehm, Balancing Agility and Discipline, 2004


Example: SPI Manifesto (2010)


A balanced approach that combines people, processes, business and change.

292010, http://www.eurospi.net/images/documents/spi_manifesto.pdf

http://www.eurospi.net/images/documents/spi_manifesto.pdf


Example: AAMI TIR45, Medical Devices


AAMI TIR45:2012, „Guidance on the use of AGILE practices in the development of medical device software“.

Very interesting merge of big-scale company processes, regulatory requirements and agile development.

Balanced approach

30


Beyond „Agile“



The Future of „Agile“


“First we will drop the capital A.”

“Then we will drop the term ‘agile’ altogether.”

“Agile methods will be successful if and when we stop seeing them as anything other than normal, sensible, professional methods of developing software.”

Maybe it’s BalanceabilityTM and I get all the money.

32G. Weinberg, Agile Impressions, 2015.

Get in touch!

[email protected]

www.elektrobit.com


https://www.facebook.com/EBAutomotiveSoftware

https://www.facebook.com/EBAutomotiveSoftware

https://twitter.com/EB_automotive

https://twitter.com/EB_automotive

https://www.youtube.com/user/EBAutomotiveSoftware

https://www.youtube.com/user/EBAutomotiveSoftware

https://www.linkedin.com/company/elektrobit-eb-automotive

https://www.linkedin.com/company/elektrobit-eb-automotive

mailto:[email protected]

20161115 Agile in Automotive: "Balanceability is the new 'Agile'"

Software

Transcript of 20161115 Agile in Automotive: "Balanceability is the new 'Agile'"