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 Much
2016-11-15

Overview
BalanceabilityTM is the new “Agile”
• Unbalanced: “Agile” Consulting
• No-go’s
• Balanceing
• Beyond “Agile”
2

About EB
3
Technical competencies
EB’s technical core competencies are
development of automotive-grade
(software) products and engineering
services.
Employees
More than 1,900 employees worldwide.
Spans three continents and nine countries.
Continental AG
Wholly owned subsidiary of Continental AG.
90+ million
Over 90 million vehicles on the road and
1 billion embedded devices.
Global presence
Development and business offices in
Austria, China, Finland, France, Germany,
India, Japan, Romania and USA.
Consistent growth
Headcount 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 Dictionary
Coined 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)

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?

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

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 projects
stories are really just use cases
sprints are really just work
stand-ups are really just meetings
iterations are really just versions
backlogs are really just to do lists
backlog grooming is really just planning
burn-down charts are really just earned value charts
velocity is really just output
and 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

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, 2010
2G. 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 meant
to be „complete“!

Some Reading #2 (“Agile”)
22
This list is not meant
to 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

Process and Method Comparison
24
Levels of Concern Life Cycle Coverage Main Areas
Method
Business
Enterprise
Business
System
Multi-team
Single-Team
Individual
Concept
Requirements
Design
Development
Maintenance
Management
Technical
Risk/
Opportunity
Measurement
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

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“

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“ ;-))
27
See 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.
29
2010, 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!
alexander.much@elektrobit.com
www.elektrobit.com

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

More Related Content

What's hot

Viewers also liked

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

Recently uploaded