[PPT] - The conflict between agile and architecture ? y t i l a e r PowerPoint Presentation

SLIDE 1

Simon Brown

The conflict between agile and architecture M y t h

r

r e a l i t y ?

SLIDE 2

simon.brown@codingthearchitecture.com

@simonbrown on Twitter Jersey, Channel Islands

SLIDE 3

I help software teams understand

software architecture, technical leadership and the balance with agility

(I code too) Training Book Speaking

SLIDE 4

What is

agile?

SLIDE 5

What is architecture?

As a noun...

Structure

The definition of something in terms

f its components and interactions

As a verb...

Vision

The process of architecting, making (significant) design decisions, etc and

SLIDE 6

The conflict between agile and architecture

M y t h

r

r e a l i t y ?

SLIDE 7

Myth

There is no conflict between agile and architecture All software projects need structure and vision

SLIDE 8 Dedicated software architect Single point of responsibility for the technical aspects of the software project Everybody is a software architect Joint responsibility for the technical aspects of the software project

1. A conflict in team structure

vs

SLIDE 9

I’m a

software architect

Big up front design

and analysis paralysis

UML Waterfall Ivory Tower

Architecture Astronaut

PowerPoint Architect

SLIDE 10

AaaS ... architecture as a service

Software development is not a

relay sport

S

f

t w a r e A r c h i t e c t u r e D

c

u m e n t

SLIDE 11

Architects?

We don't need no stinkin’ architects!

SLIDE 12 Developer Developer Developer Developer Developer

Small teams of generalising specialists, everybody does everything

With agile, there is often a perception that you must have self-organising teams

SLIDE 13

2. A conflict in process

S

f

t w a r e A r c h i t e c t u r e D

c

u m e n t Big up front design Requirements capture, analysis and design complete before coding starts Evolutionary architecture The architecture evolves secondary to the value created by early regular releases of working software /// <summary> /// Represents the behaviour behind the ... /// </summary> public class SomeWizard : AbstractWizard { private DomainObject _object; private WizardPage _page; private WizardController _controller; public SomeWizard() { } ... }

vs

SLIDE 14

The conflict relates to the desired

approach

Moving fast, embracing change, delivering value early, getting feedback U n d e r s t a n d i n g e v e r y t h i n g u p f r

n

t , d e f i n i n g a b l u e p r i n t f

r

t h e t e a m t

“

f

l

l

w

” vs

SLIDE 15

Responding to change

ver

following a plan

This doesn’t mean “don’t do any planning”! Manifesto for Agile Software Development, 2001

SLIDE 16

Modern software development teams

ften seem afraid of doing

analysis

SLIDE 17

Big

design up front

N

SLIDE 18 Agile software team

We don’t need software architecture; we do TDD

SLIDE 19

The result of the

conflicts?

SLIDE 20

Chaos!

Does the team understand what they are building and how they are building it?

SLIDE 21

Chaos!

Does the team understand what they are building and how they are building it? No defined structure, inconsistent approaches, big ball of mud, spaghetti code, ...

STOP

Slow, insecure, unstable, unmaintainable, hard to deploy, hard to change,

ver time, over budget, ...

SLIDE 22

Shared vision of

WTF?!

SLIDE 23

Software architecture

in the

21st century

SLIDE 24

Chaos!

Does the team understand what they are building and how they are building it? No defined structure, inconsistent approaches, big ball of mud, spaghetti code, ...

STOP

Slow, insecure, unstable, unmaintainable, hard to deploy, hard to change,

ver time, over budget, ...

Let’s agree

n some things

L e t ’ s m a k e t h e i m p l i c i t ,

e x p l i c i t

Put some boundaries and guidelines in place

SLIDE 25 Dedicated software architect Single point of responsibility for the technical aspects of the software project Everybody is a software architect Joint responsibility for the technical aspects of the software project

1. A conflict in team structure

vs

SLIDE 26

Every software development team needs a master builder

1 or many

SLIDE 27

Depth

Deep hands-on technology skills and knowledge

Breadth

Broad knowledge of patterns, designs, approaches, technologies, non-functional requirements ... Awareness of options and trade-offs Good software architects are master-builders

Generalising Specialist

SLIDE 28 From chaos to self-organising Dedicated software architect Single point of responsibility for the technical aspects of the software project Everybody is a software architect Joint responsibility for the technical aspects of the software project

The software architecture role

Elastic Leadership (Roy Osherove) C h a

s

( c

m

m a n d a n d c

n

t r

l

) , l e a r n i n g ( c

a

c h i n g ) , s e l f

r

g a n i s i n g ( f a c i l i t a t i

n

)

SLIDE 29

2. A conflict in process

S

f

t w a r e A r c h i t e c t u r e D

c

u m e n t Big up front design Requirements capture, analysis and design complete before coding starts Evolutionary architecture The architecture evolves secondary to the value created by early regular releases of working software /// <summary> /// Represents the behaviour behind the ... /// </summary> public class SomeWizard : AbstractWizard { private DomainObject _object; private WizardPage _page; private WizardController _controller; public SomeWizard() { } ... }

vs

SLIDE 30

How much up front design should you do?

Big design up front? Emergent design? (or none, depending on your viewpoint!) Something in between?

Waterfall

SLIDE 31

You should do

“just enough”

I s n ’ t a g i l e a b

u

t b e i n g f l e x i b l e a n d a d a p t i n g t

t

h e c

n

t e x t ? :

)

SLIDE 32

What’s important?

Understanding the significant elements and how they fit together Significant decisions Low-level details Class and sequence diagrams covering every user story Defining the length of all database columns Understanding how security will work

SLIDE 33

Just enough up front design to

understand the structure

f the software and

create a shared vision

for the team

SLIDE 34

You need to

identify and mitigate

your highest priority

risks

T h i n g s t h a t w i l l c a u s e y

u

r p r

j

e c t t

f

a i l

r

y

u

t

b

e f i r e d ! A g i l e s

f

t w a r e p r

j

e c t s d

h

a v e r i s k s , r i g h t ? :

)

SLIDE 35

Probability Impact

Low (1) Medium (2) High (3) Low (1) Medium (2) High (3)

1 2 2 4 3 3 6 6 9

SLIDE 36

Risk-storming

A collaborative and visual technique for identifying risk

SLIDE 37 /// <summary> /// Represents the behaviour behind the ... /// </summary> public class SomeWizard : AbstractWizard { private DomainObject _object; private WizardPage _page; private WizardController _controller; public SomeWizard() { } ... }

“just enough”

software architecture The role The process Understand how the significant elements fit together I d e n t i f y a n d m i t i g a t e t h e k e y r i s k s Provide firm foundations and a vision to move forward S

f

t w a r e A r c h i t e c t u r e D

c

u m e n t

SLIDE 38

Is a collaborative and lightweight approach to software architecture the missing piece

f the jigsaw?

SLIDE 39

you

Do whatever works for

simon.brown@codingthearchitecture.com @simonbrown on Twitter

SLIDE 40

Buy the ebook for only

$10

1GfwZBLaUKAM

(code expires 8th May 2013)