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

The conflict between agile and architecture ? y t i l a e r h t y M r o Simon Brown

simon.brown @ coding the architecture .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... Structure The definition of something in terms and of its components and interactions As a verb... Vision The process of architecting, making (significant) design decisions, etc

The conflict between agile and architecture ? y t i l a e r h t y M r o

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

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 and analysis paralysis UML I’m a software architect Ivory Tower PowerPoint Architect Architecture Astronaut

Software development is not a relay sport e a r w t o f S e u r c t e i t h r c A n t e m u o c D AaaS ... architecture as a service

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

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

2. A conflict in process /// <summary> /// Represents the behaviour behind the ... /// </summary> public class SomeWizard : AbstractWizard e a r w { f t o S vs private DomainObject _object; r e u c t private WizardPage _page; e h i t c A r private WizardController _controller; t e n m u c o D 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, embracing p u g n change, delivering value i h t y r e v e g n d i n a t s r e d n t U n i r p early, getting feedback e u l b a g n i n f i e d , t vs n o r f ” w o l l o f “ o t m a e t e h t r o f

Responding to change over following a plan Manifesto for Agile Software Development, 2001 This doesn’t mean “don’t do any planning”!

Modern software development teams often seem afraid of doing analysis

Big o N design up front

We don’t need software architecture; we do TDD Agile software team

The result 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 t , i c i l p m i e h t e k a on some things m s ’ t e No defined structure, L t i c i l inconsistent approaches, p x e 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 of options and trade-offs Good software architects are master-builders

The software architecture role From chaos to self-organising Dedicated Everybody is a software architect software architect Elastic Leadership (Roy Osherove) , Single point of responsibility for o l ) Joint responsibility for the r n t o c d a n d n m a m o c ( s o h a C the technical aspects of the technical aspects of the g ) , n h i c o a c ( n g n i r e a l software project software project n ) o t i t a l i c i f a ( g i n i s a n g o r - l f s e

2. A conflict in process /// <summary> /// Represents the behaviour behind the ... /// </summary> public class SomeWizard : AbstractWizard e a r w { f t o S vs private DomainObject _object; r e u c t private WizardPage _page; e h i t c A r private WizardController _controller; t e n m u c o D 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” g n i e b t u o b a e l g i a t ’ n s I g n t i p a d a d n a e b l i x e l f ) - : ? t x e t n o c e h t o t

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

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 e s u a c l l i w t a h t s g n h i T l a i f o t t c e o j r p A g i l e s o r f t w a u r e p r o o j e c y t s ! d e r i f e b o t u d o o h a v e y r i s k s , r i g r h t ? : o - )

Probability High (3) Medium (2) Low (1) 3 2 Low (1) 1 Medium (2) Impact 6 4 2 9 6 3 High (3)

Risk-storming A collaborative and visual technique for identifying risk

“just enough” software architecture Understand how the significant elements fit together The role e t a g i t i m d n a y f i t n e d I s k s i r y e k e h t Provide firm foundations and a vision to move forward /// <summary> /// Represents the behaviour behind the ... /// </summary> public class SomeWizard : AbstractWizard r e w a o f t S { e t u r private DomainObject _object; t e c c h i A r The process private WizardPage _page; t e n u m o c private WizardController _controller; D public SomeWizard() { } ... }

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

you Do whatever works for simon.brown @ coding the architecture .com @ simonbrown on Twitter

Buy the ebook for only $10 1GfwZBLaUKAM (code expires 8th May 2013)