The conflict between

agile and architecture

M y t h or re al it y ?

Simon Brown
 simon.brown@codingthearchitecture.com
@simonbrown on Twitter

Jersey, Channel Islands

 I help software teams understand

software architecture,
technical leadership and
the balance with agility
(I code too)

Training Book Speaking

 What is

agile ?
 What is architecture?
As a noun...

S t r u c t u r e
fi ni ti o n o f s o m et h ing in te rm s and
The de
it s c o m po ne nt s an d in te ra c ti ons As a verb...
of

Vision
The process of architecting,
making (significant) design dec
isions, etc
The conflict between
agile and architecture
Myth or re al it y ?
Myth
There is no conflict between agile and architecture

ts
All software projec
s t r uc t u r e an d vi sion
need
1. A conflict in team structure

vs
Dedicated Everybody is a
software architect software architect
Single point of responsibility for Joint responsibility for the
the technical aspects of the technical aspects of the
software project software project
Big up front design Waterfall
analysis paralysis
UML
and

I’m a

software
architect
Ivory Tower
PowerPoint Architect
Architecture Astronaut
Software development is not a

relay sport
Software
Architecture
Document

AaaS ... architecture as a service

Architects?
We don't need no
stinkin’ architects!
Developer Developer Developer Developer Developer

n e r a li s in g s p e c ia li s ts ,
Small teams of ge
e ve r y b od y d o e s e ve r y t hin g

a g il e , t h e r e is o ft en a
With
r c ep t io n t h a t y o u must
pe
a ve s e lf - o r g a n is in g teams
h
2. A conflict in process
/// <summary>
/// Represents the behaviour behind the ...
/// </summary>
public class SomeWizard : AbstractWizard

Software
{

vs
private DomainObject _object;

Architecture
private WizardPage _page;
private WizardController _controller;

Document public SomeWizard()

{
}

...

Evolutionary
architecture
Big up front design The architecture evolves
secondary to the value created
Requirements capture, analysis
by early regular releases of
and design complete before
working software
coding starts
The conflict relates to the desired

approach
Moving fast, em
bracing
change, deliverin r y t h in g up
g value t a n di n g eve
early, getting fe Under s p r int
edback ng a b l u e
vs t, d e f in i
fron “ f o l l o w”
e t e a m t o
for t h
 Responding
to change
over

following a plan
Manifesto for Agile Software Development, 2001

This doesn’t mean

g”!
“don’t do any plannin
Modern software development teams
often seem afraid of doing

analysis
 Big
No
design up front
 We don’t need
software architecture;

we do TDD
Agile software team
 result
The of the

conflicts?
Chaos!
Does the team understand what they are building and how they are building it?
 No defined structure,
inconsistent approaches,

Chaos!
big ball of mud,
spaghetti code, ...

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

Slow, insecure, unstable, unmaintainable,

hard to deploy, hard to change,
over time, over budget, ...
Shared vision of

WTF?!
 Software
architecture
in the

21st century
 Let’s agree c it,
e i mp l i
on some things No defined structure, t ’ s ma k e th
Le
i c i t
inconsistent approaches,

ex pl

Chaos!
big ball of mud,
spaghetti code, ...

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

Slow, insecure, unstable, unmaintainable,

hard to deploy, hard to change,
over time, over budget, ...

Put some boundaries

and guidelines in place
1. A conflict in team structure

vs
Dedicated Everybody is a
software architect software architect
Single point of responsibility for Joint responsibility for the
the technical aspects of the technical aspects of the
software project software project
 Every software
development team
needs a
master builder
1 or many
 Generalising

Breadth

Specialist
Broad knowledge of
patterns, designs,
approaches, technologies,
Depth non-functional requirements
Deep hands-on technology ...
skills and knowledge

Awareness
options
of
and trade
-offs
w a r e a r c h it e c ts
Good soft
e r - b ui l d e rs
are mast
 The software architecture role

From chaos to self-organising

Dedicated Everybody is a
software architect software architect
L e a d e r s h ip (Roy Os herove)
Elastic
Single point of responsibility for
o m m a n d a n d c ontrol), Joint responsibility for the
the technical aspects of the Chaos (c technical aspects of the
ing),
software project learning (coach software project
o r g a n is in g ( f a c ilitation)
self-
2. A conflict in process
/// <summary>
/// Represents the behaviour behind the ...
/// </summary>
public class SomeWizard : AbstractWizard

Software
{

vs
private DomainObject _object;

Architecture
private WizardPage _page;
private WizardController _controller;

Document public SomeWizard()

{
}

...

Evolutionary
architecture
Big up front design The architecture evolves
secondary to the value created
Requirements capture, analysis
by early regular releases of
and design complete before
working software
coding starts
How much up front design should you do?
Emergent design?
(or none, depending on
Big design up front? your viewpoint!)

Waterfall

Something in between?
 You should do

“just enough”
b o u t b e i n g
a
Isn’t agile
a n d a d a p ting
flexibl e
o n t e x t ? : -)
to the c
 What’s important?
Significant decisions Low-level details

s s a n d s e q u e n ce
Understanding the Cla
significant elements and gr a m s c o v e rin g every
dia
how they fit together user story

Understanding how
security will work Defining the length o
f
all database column
s
Just enough up front design to

understand the
structure
of the software and

create a
shared vision
for the team
 You need to

identify and mitigate

your highest priority

risks
a t w i l l c a use
Things th
r o j ec t t o f ail Agile software projects
your p
u t o b e f i red! do have risks, right? :-)
or yo
 Probability
Medium (2) High (3)
Low (1)

2 3
Low (1)

1
Medium (2)
Impact

2 4 6

3 6 9
High (3)
R i sk - st orm i n g

A collaborative and visual technique for identifying risk

 “just enough”
software architecture

Understand how the

significant elements
The role fit together
n d m i ti g ate
a
Identify
e k ey r i sks
th
Provide fir
m foundat
ions
and a visio
n
to move f
orward

/// <summary>
/// Represents the behaviour behind the ...
/// </summary>
public class SomeWizard : AbstractWizard
Software {
private DomainObject _object;
Architecture private WizardPage _page;

Document The process private WizardController _controller;

public SomeWizard()
{
}

...

}
Is a collaborative and lightweight
approach to software architecture

the missing piece

of the jigsaw?
 you
Do whatever works for

simon.brown@codingthearchitecture.com
@simonbrown on Twitter
Buy the ebook
for only
$10
1GfwZBLaUKAM
(code expires 8th May 2013)