2009 scrum & architecture

Scrum & Architecture
Dr. Andreas Wintersteiger
Objectbay Software & Consulting GmbH
andreas.wintersteiger@objectbay.com
1
Nov 2009

© 2006 - 2010 Objectbay Software & Consulting GmbH, Austria www.objectbay.com
Agenda
Scrum in a Nutshell
Architecture
Evolving Architecture in Agile Dev
How to do Architecture with Scrum
2
Antoine de Saint-Exupéry, 1900 – 1944
“Perfection is achieved not when ther is nothing more to add,
But when there is nothing left to take away.“

3 Roles, 3 Artifacts
3

5 Ceremonies (Sprint + 4 Meetings)
4

Sprints deliver working software
Fixed lenght development cycles
Originally one month duration
Some teams use two or three weeks
Establish a sustainable rhythm
All needed development activities
Potentially shippable product-increment
Scrum development: sequential series of „iterations“
5

Product increments are vertical
6
User Interface
Business Logic / Workflow
Database
Infrastructure
Increment1
Increment2
Increment3
... and include all previous increments!

All phases are all done within the sprint ...
7
... but in cycles and countinuously!
(not as a mini-waterfall)

Agenda
Scrum in a Nutshell
Architecture
8

What is Architecture by the way?
Structure
Abstraction
Perspectives
A Framework for Change (Tom DeMarco)
Extendability
The Result of a design process
Granularity
9

Architectural Granularity is a Spectrum
Architectural Styles
Define the overall style of an application architecture, such as layered/n-tier, message passing, store & forward,
pipes & filters, finite state machine, peer to peer, service oriented ...
A set of ground-breaking decissions
Enterprise / Design Patterns
Describe finer grained patterns of architecture elements
Many patterns available
All based on GoF patterns
10

The role of Requirements
Functional Requirements
They have impact on architectural decissions on a high level
Top-level requirements should be known upfront
Detailed requirements drive more the detailed design
Non-functional
May have an impact on high level design (Performance,
Extensibility, Availability)
Imply risks - we want to know them early (fail fast)
11
Architectural
Styles
Design
Patterns

Architecture is an asset
Focus on the long term
Stability of the system
Extensibility
Represents an asset value for the company
The Architect is a Stakeholder
Not seldomly sitting in the ivory tower
But without power ...
12

Architecture implications
User Interface
„The interface is the program“ (Raskin)
Organizational Structure
Conway‘s Law
13

Agenda
Scrum in a Nutshell
Architecture
14

Evolution is the best Architect
Evolutionary design is the kind of design that
survived (evolutionary) ...
Plants, Animals and other living beings in nature
The human body
Early and continuous feedback
Allow for failure
Inspection & Adaption
15

16
Evolutionary
Design
Examples
The evolution of the command
service module starting with the
module designed for Gemini-2
mission (left) to the command module
for the Appollo-XIV mission.

Evolution of NASA Space Suits
17

Apple Mac - Evolution of a Computer 1984-
2009
18
1984

Did they think upfront?
Yes, but the question is how much ....
19
When was the last time
you did see an architecture
drawn on the board by an architect, that
actually came into being
as originally designed?

BDUF / Waterfall - did never work! Really.
20
Let‘s think of software
Fear of not knowing enough is an omnipresent pattern in all organizations
Enterprise Architects do not code ...
„Beautiful piece of ficition“
„Architecture is not living in a document - it is living in code“ (James Coplien)

NDUF - No Design upfront
21
see Ron Jeffries: XP installed

NDUF didn‘t work either - well, most of the time ...
22
In some cases, ...
Only for really typical architectures (Java EE 3-tier) plus design driven processes (XP, TDD)
Almost no risks
Familarity with the environment / architecture for the last 20 years
This is why Agile/XP and Architects really got into a bad relationship in some companies

RUFD - the right upfront design
23
„rough“ design
Architectural vision („Product Vision“)
Keep the desing upfront short
Not too short
term coined by Jim Coplien

Incremental Design... so often misunderstood
Key is to keep the code easily changeable
We need clean code for this
Easy to understand
No redundancy - DRY
Decoupled
We stop anticipating future unknown requirements
We start with a rough design and refine further on
We maintain a changeable code
24

Architecture in an agile light
Architecture embodies the critical design decissions
that typify a system
The significance of decissions needs to be
understood and assessed
Significance of decissions is reduced
Key decissions reduce significance of other decissions
Doing the hard ones first make the easier ones easier,
doing the easy ones first make the hard ones harder.
25
Source: James Coplien, 2008

Agile embraces evolving Architecture
Agile: The right detail in the right time
Architectural Styles and
Design Patterns set the frame
Use Test Driven Design to focus on the details
26

Agenda
Scrum in a Nutshell
Architecture
27
Niels Bohr, ...
„Be careful about predicting things,
Especially when it is about the future.“

Architecture & Scrum
Basically, Architecture is treated as all other aspects of development (e.q. Quality) in Scrum
Enterprise Architects should be part of the daily game
They are treated as customers or stakeholders - move them out of the ivory tower
They define concrete requirements, constraints, specifications
Architects should be team members (and yes, coding)
Level of trust
Communication
Credibility
Build an architecture Board or “Community of Practice”.
28

Architecture & Scrum (2)
Feed the experience into the process
This can only be done „at the working line“
Have engineering practices in place
Test Driven Development
Continous Integration
Frequent and automated Releases
Metrics, Code Evaluation
Architecture is part of the planning game in Scrum (Sprint Planning 2)
29

Architecture & Scrum (3)
Architecture lives in code
Team‘s responsibility is the quality of the code
And therefore also architecture
Architecture is documented in code
Tests are the best and up-to date documentation of specs
Who is responsible?
In Scrum the P.O. decides on priorities but is consulted by an architect (team)
How much upfront?
It depends.
30

Architecture Sprints
First have a Product Vision in place - P.O.
This includes an Architectural Vision - P.O. and team
Second, do the high level decisions - Decide on Architectural Styles
And refine only if necessary (Patterns)
Design as you go during the Sprint, Refactor permanent
It is ok to have an “Architecture Sprint”, but ...
Remember, Scrum demands working code at the end of a sprint
So, build tests (interfaces) and a rough implementation that proves that the architecture works
Refine the architecture on an ongoing basis - do the fine grained decisions as needed
Keep your entire software asset changeable
31

2009 scrum & architecture

More Related Content

Similar to 2009 scrum & architecture (20)

Recently uploaded (20)

2009 scrum & architecture