Software Architecture

with Agile Teams

Chris F. Carroll&

Alan Gawthorpe

photo: http://d.lib.ncsu.edu ua023_025 copyright not known

First, a couple of questions...

Agile vs ArchitectureDestined to Fight?

Individuals & Interactions over processes and tools

Working Software vs comprehensive documentation

Customer Collaborationover contract negotiation

Responding to Changeover following a plan

ITABOKISO 42010

40 years of experience!

Agile & ArchitectureCommon Priorities

“Our highest priority is to satisfy the customer ...”

ISO42010 Systems & Software Engineering — Architecture Description

Architecture with Agile TeamsQuestions & Issues

• Methodologicalo Scaling agile – howo Architecture in an agile lifecycle – where/wheno Enterprise concerns: governance, risk, adoption,

maturity – how

• Personalo How can an agile team and an architect relate

effectivelyo How do I the architect add value effectively

• Technicalo Agility as a software qualityo What kind of architecture might count as agile

Summary of Agile

Achitecture with Agile TeamsQuestions & Issues

• Methodologicalo Scaling agile – howo Architecture in an agile lifecycle – where/wheno Enterprise concerns: governance, risk, adoption,

maturity – how

• Personalo How can an agile team and an architect relate

effectivelyo How do I the architect add value effectively

• Technicalo Agility as a software qualityo What kind of architecture might count as agile

How does Agile Scale?

“Out of the box ‘core’ agile methods do not give adequate consideration to the risks associated with delivering solutions on large enterprise projects and as a result we're seeing organizations investing a lot of effort creating hybrid methodologies ...”

Ambler & Lines, Disciplined Agile Delivery, 2012

Scaling Agile:Enterprise-level Methodologies

Agile Unified Process & Agile Modeling

– Scott Ambler, 2005

Open Unified Process

– Eclipse Foundation, 2005

MSF4ASD

– Microsoft, 2005

agile@scale – IBM-Rational, 2008

Disciplined Agile Delivery

–Scott Ambler & Mark Lines, 2012

Disciplined Agile: •Risk-Value lifecycle•Self-organised within governance framework •Full delivery cycle

IBM: Agile Scaling Model

Core Agile: •Value Driven•Self-OrganisedFocus on Construction

Agility@Scale: •Disciplined with scaling factors applied

Scaling Agile: OpenUP

Scaling Agile:Agility@Scale Scaling Factors

How does agile scale? The same way as all software:

• By scaling the methodologyo http://disciplinedagiledelivery.com/o SlideShare: “IBM Rational Achieving Agility at Scale,

Alan Brown”o IBM Developerworks: Agility@Scale

• By doing architecture

“It’s not agile that’s hard to scale, it’s software that’s hard to scale.” Tom McMillen, CTO intilery.com

Architecture in an agile lifecycle?

Options for Where, as in, when

Scrum / XP ☛ Architecture SpikeSprint Zero

Unified Process ☛ Inception & Elaboration

Poppendieck, “Lean Toolkit…”Fairbanks,”Just Enough…”

☛ Continuously with Feedback

Architecture in Core Agile:Architecture Spike or Sprint Zero

Before development, have just enough architecture, design decisions, tool & environment work to support it.

Architecture in UP-derivatives:Inception and Elaboration

To leave Elaboration you must:

Design, implement, validate, and establish the baseline for the architecture and test a skeleton structure of the system ...

This is an executable architecture.

Architecture in UP-derivatives:Construction

• The Agile Development phase – full steam ahead

• The Evolutionary Architecture practiseo Perform architecture work “just in time”o Document key architectural decisions and outstanding issueso Implement and test key capabilitieso In spite of the name, it is still assumed that the bulk of architecture

work is done during elaboration

G. Fairbanks, 2010:Just Enough Software Architecture

Architecture and design activities during each phase, addressing architecture and risk in each sprint alongside features

Architecture & Agile Methodology

o Are there 'enterprise level' agile methodologies?

o How does agile scale?o Where & how does architecture fit in an agile lifecycle?o How are ‘enterprise’ concerns addressed

o maturityo governanceo risko adoptiono ...

GovernanceArchitecture & Agile Methodology

• Addressing governance is perhaps the cutting edge of agile adoption

• Traditional governance may be anti-agile

• You may benefit from critically assessing whether your governance framework is cost-effective

Governance for Agile DeliveryNational Audit Office, July 2012

• Governance should mirror the philosophy of Agile methods – only do a task if it brings value to the business and does not introduce delays

• Light touch and proactive

• Focus on the activities and on value, in contrast to traditional methods which check what the team has done to improve predictions and estimates and reduce the variation between the baseline and forecast

http://www.nao.org.uk/wp-content/uploads/2012/07/governance_agile_delivery.pdf pp8–10

Governance for Agile DeliveryAmbler & Lines, Disciplined Agile Delivery

Q: Is your governance strategy designed to enable the work or control the workers?

“Three Bold Claims”

• Agile teams are significantly easier to govern than traditional teams.

• Traditional approaches to governance are guaranteed to harm agile teams.

• Disciplined Agile Delivery teams must demand good governance by their organization.

Risk Management in Agile

Agile brings two big guns to risk management

• Emphasis on plenty of communication between customer and development team

• Early & continuous delivery of software with feedback

These must be in addition to – not instead of – your existing approaches. Agile doesn't answer all the questions.

Risk Management in Agile Methodologies

• UP-inspired approaches still follow the UP mantras: Attack risks early, before they attack you, and the architecture is a risk.

• Fairbanks’ “Just Enough Software Architecture” is a risk-centric approach:

1. Identify and prioritize risks

2. Apply relevant architecture activities

3. Re-evaluate

FairbanksJust Enough Software Architecture

A quick test : Are your risks written down?

Developers probably have a written list of features to develop but the list of risks is often made up on the spot.

⚐Agile usually gives public visibility to progress.

When risks other than non-delivery are an issue, give the same visibility to risk as is given to delivery

Risk mitigation strategies typically rejected in agile

• Trying to predict the future in detail

• Doing detailed design without code & test

• Gathering detailed requirements in a setting where they will be outdated by the time you've delivered them

• Believing that the right process allows you to plug anyone in as an interchangeable resource

Architecture with Agile TeamsQuestions & Issues

• Methodologicalo Scaling agile – howo Architecture in an agile lifecycle – where/wheno Enterprise concerns: governance, risk, adoption,

maturity – how

• Personalo How can an agile team and an architect relate

effectively?o How do I the architect add value effectively?

• Technicalo Agility as a software qualityo What kind of architecture might count as agile

Threats in RelationshipsThe Architect vs. the Agile Team

“The chief measure of progress is working software” so what value are you adding?

“Your up-front design won’t solve our actual problems or help us respond to change”

Architect & Agile Team RelationshipsThe power of metaphor

Architect is to builder & bricklayer

as

Software architect is to _______________ ?

Architect & Agile Team RelationshipsThe power of metaphor

But coding is design, not bricklaying.

Otherwise robots would do it.

If you relate to developers by tossing blueprints over the wall, saying ‘here, implement this’ then your brightest and best will go either elsewhere or will want to be architects instead of developers.

Architect & Agile Team RelationshipsThe power of metaphor

software delivery is to manufacturing

as

coding & testing is to product development

Coding is not stamping out identical copies, it is always developing something new.Copying we can automate; coding we can’t.

Poppendieck & Poppendieck, Lean Software Development, 2003

The Architect vs. the Agile TeamThreats

“Architect”

is a

high-prestige

word and

may imply

a claim to

superiority

http://clutchtees.com/

The Architect and the Agile TeamRoles for the Architect?

If the “best software architectures emerge from self-organising teams” then your choices are

• Join the team

• Adopt the Consultant or Coach or Servant role

• Be a validator/peer-reviewer

• Be the Architecture Product Owner

The Role of the Agile Architect

Hands-On

Hands-Off

vs

Architecture with Agile TeamsQuestions & Issues

• Methodologicalo Scaling agile – howo Architecture in an agile lifecycle – where/wheno Enterprise concerns: governance, risk, adoption,

maturity – how

• Personalo How can an agile team and an architect relate

effectivelyo How do I the architect add value effectively

• Technicalo Agility as a software qualityo What kind of architecture might count as agile

An Agile Technical Architecture–What would it look like?

Three possible ways to see this question:

• Doing architecture within the agile lifecycleo Methodology

• Doing architecture in the spirit of agile valueso How you relate to people

• Present an architecture that enables agile developmento What might an agile architecture look like?

Coplien & Bjørnvig, 2010: Lean Architecture for Agile Software Development

• Getting the right architecture enables rapid agile development.

• “Lean” does mean thinking ahead.

Agility as a Software Quality Attribute?

Agility would be a kind of modifiability that enables:

• Self-organising teamso Allow teams to work autonomously

• Continuous deliveryo Adding features & improvements to a software system over an

extended period

• Responding to changeo Delivering unpredicted requirements at acceptable cost

We should be able to describe scenarios/measures for agility, and describe tactics to achieve it.

The scenario is largely fixed: The team is presented with requirements at the start of a sprint and responds by delivering an increment of working software

• Measure 1: Cross-team dependencies should be rare

• Measure 2: Velocity should not nose-diveo “The team should be able to deliver software at

similar velocity in months N1-N2 of the project as they did in the first few months.”

• Measure 3: Responsiveness to change should be higho “The team should be able to deliver on new

requirements in each sprint at similar velocity as they can deliver on known-beforehand requirements”

Agility as a Quality Attribute:Proposed Measures

Tactics for Agility:The Growable Walking Skeleton

Lean Architecture for Agile Software:Coplien & Bjørnvig's Partitioning Steps

1) Distinguish

What the system is

vs

What the system does

A kind of “partition by rate of change”:

Stable domain knowledge

vs

Volatile functionality

Lean Architecture for Agile SoftwareCoplien & Bjørnvig's Partitioning Steps

2) Partition to maximise the autonomy of teams

• You can't fight Conway’s Law

“Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of those organizations”

Let the human considerations drive the partitioning, with software engineering concerns secondary

Lean Architecture for Agile SoftwareCoplien & Bjørnvig's Partitioning Steps

3) Respect domain knowledge

• Partition around domains–which should in fact match business structure

• Don't split a domain across geographic locations or across architectural units

• Re-use existing products & product lines to bolster domain partitioning

• Co-ordinate with Conway's Law; it shouldn't take a village to raise a module.

• Elicit and use the End-User Mental Model

Tactics for Agility:Architecture as a ‘space’ for functionality

Consider how the architecture for a hotel enables the functionalities of hotelling, e.g. eating and sleeping.

It does so by providing spaces within which the functions can take place.

So the growable skeleton should have identified places where an expanding series of use-cases can be added.

(Software has expandable walls)

OO principles such as SOLID

XP practices & simple design

YAGNI

DoTheSimplestThingThatCouldPossiblyWork

Agility as a Quality Attribute:Tactics to achieve it

Agility as a Quality Attribute:Tactics to achieve it

• An early walking skeleton with identifiable space for use-cases to expand in

• Partition by: rates of change, team structure and domain knowledge

• Architect the spaces for adding functionality

• YAGNI and Simple Design

Architecture with Agile TeamsThank You For Participating!

• Methodologyo Scaling agile – howo Architecture in an agile lifecycle – where/wheno Enterprise concerns: governance, risk, adoption,

maturity – how

• Personalo How can an agile team and an architect relate

effectivelyo How do I the architect add value effectively

• Technicalo Agility as a software qualityo What kind of architecture might count as agile

Software Architecture

with Agile Teams

Alan Gawthorpe

&Chris F. Carroll

photo: http://d.lib.ncsu.edu ua023_025 copyright not known

http://future-thought.co.uk/abouthttp://www.cafe-encounter.net/about