agile doesn`t scale brian cronauer ... - sei digital library · us eu #engineers © fraunhofer iese...

© Fraunhofer IESE

1

Agile Doesn`t Scale … Without Architecture

SATURN 2012St. Petersburg, FLMay 10, 2012

SATURN 2012St. Petersburg, FLMay 10, 2012 architecture.iese.fraunhofer.dearchitecture.iese.fraunhofer.de

Brian Cronauer, John DeereAndreas Huber, John DeereMichael Höh, John DeereThorsten Keuler, Fraunhofer IESE

© Fraunhofer IESE

2

Starting Point

Experiences

What have we learned?

Transition towards Agile

Scalability of SW Development

© Fraunhofer IESE

3

© Fraunhofer IESE

4

John Deere – Display Development

KLOC

MLOC

10xMLOC

?

Time

Size &Complexity

© Fraunhofer IESE

5

Starting PointSystems

Engineering• Requirements

Specification

Design & Implementation

• Design Specification• Code

Verification & Test

4

15

20

50

10

80• Unit Test• Integration• Regression

& Field Test

EarliestCustomer feedback

EUUS

#engineers

© Fraunhofer IESE

6

Large‐Scale Transition Towards Agile

Iterative WaterfallPure Agile

#engineers < 20

#engineers > 180

~1 year

© Fraunhofer IESE

7

Starting Point

Experiences




© Fraunhofer IESE

8

What is the Scale in „Large‐Scale“?

Speed of development

#Developers#SW units

TheoryPractice

© Fraunhofer IESE

9

Inhibitors to Scalability

Speed of development

System complexity#developers/#teamsDistribution of teams

#Developers/SW unit

Complexitydrivers

Architecturalprinciples

Key

© Fraunhofer IESE

10

Classes ofInhibitors Technologies

Processes

Roles & Capabilities

SW Structures

© Fraunhofer IESE

11

Starting Point

Experiences




© Fraunhofer IESE

12

Transition to Agile

© Fraunhofer IESE

13

Effects

Prototyping with one team

worked well with one team

faster delivery

© Fraunhofer IESE

14

Reasons

Small scale

Co-located developers

Small system scope

© Fraunhofer IESE

15

“Power of the Team”

© Fraunhofer IESE

16

Effects

Java vs C++

Deletion of work

Coding guidelines not followed

communication overhead

© Fraunhofer IESE

17

Reasons

Clear phases are gone

Rules & standards?

Specs -> user stories

„Do what you want“

© Fraunhofer IESE

18

“With great Power comes great Responsibility”

© Fraunhofer IESE

19

© Fraunhofer IESE

20

Communicationvs

Documentation

© Fraunhofer IESE

21

Effects

… we don’t document

… we don’t do architecture

… we don’t think about next PSI

… YAGNI

© Fraunhofer IESE

22

Reasons

Agile Agile Techniques

Philosophy ClashesC_

© Fraunhofer IESE

23

Philosophies – Revisited

http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf

© Fraunhofer IESE

24

„Disciplined agile teams …“ … work closely with their stakeholders, including bothoperations and support staff

… invest time at the beginning of the project to identify thehigh‐level scope in a light‐weight, collaborative manner

… will also identify a viable architectural strategy which reflectsthe requirements of their stakeholders and your organization’soverall architectural strategy

© Fraunhofer IESE

25

Comm/Doc – Rule of Thumb

Temporal validity

Comm/DocStyle

Face-to-face

Whiteboarding

Model-based

© Fraunhofer IESE

26

Requirements

© Fraunhofer IESE

27

Effects

Late Detection of Quality issues

Incompatible solutions for crosscutting concerns

© Fraunhofer IESE

28

Reasons

NF requirements implicit

Big Picture?

Feature-based development

© Fraunhofer IESE

29

“Tooling War”

© Fraunhofer IESE

30

Effects

Replaceability of teams

Exchangeability of artifacts

© Fraunhofer IESE

33

Component‐based vs Feature‐based

Component-based Feature-based

Team A

Team B

Team C

Team A Team B

© Fraunhofer IESE

39

Common Technical Framework Architecture Description

Transformation Chain (Acceleo)

Generated Glue Code

ManualC++ Code

© Fraunhofer IESE

42

What have we learned?Understand Change

Classify change ‐> Is it architecturally‐relevant?

Costly to change?

Impact on multiple teams?

Impact on many software parts?

Act on Change

Management commitment ‐> Who pays for “infrastructure” change?

Architecture and Agile are not Adversaries

Combine the best of both worlds!

© Fraunhofer IESE

43


Unification

Solid basis for scaling development

Agreement on technologies

True commitment to

architectural rules

Reasonable design “look ahead”

Check scalability across inhibitors

Architecture

Technologies

Roles

Processes

SW Structures

© Fraunhofer IESE

44

ContactDr. Thorsten KeulerPhone: +49 631 6800 [email protected]://architecture.iese.fraunhofer.de

Thank you for yourattention!

… Questions?http://architecture.iese.fraunhofer.de

agile doesn`t scale brian cronauer ... - sei digital library · us eu #engineers © fraunhofer iese...

Documents