Agile Teams and

Architecture

Tommy Ågren

Some guiding

values and principles

What is Lean and Agile?

A set of Values and Principles

– That have proven to work!

Lean: Toyota (manufacturing & production)

Agile: Software lightweight methods

2001 Agile Manifesto

Copyright Agesis AB

www.agesis.se 3

Adopting Lean & Agile

Practices, how to do it Processes, Organization, Methods and Tools

Benefits and Why Wanted business effects!

Values and Principles Principles that govern the wanted effects

Creates context and alignment

Copyright Agesis AB

www.agesis.se 4

Try out, learn

and Adapt

Agile & Lean

Agile principles

– Continuous attention to technical excellence and good

design enhances agility

– The best architectures, requirements, and design solutions

emerge from self-organizing teams

– Simplicity is essential

Lean Software principles – Build Integrity in (system integrity and quality)

– No defects!

– The system should function as a cohesive unit

Copyright Agesis AB

www.agesis.se 5

Architecture

Agile Teams

Copyright Agesis AB

www.agesis.se 6

Self-organizing (within a context)

Cross-functional

Long living

Responsible for the result

5-9 members

Copyright Agesis AB

www.agesis.se 7

Roles, Skills and Responsibility

Want to avoid static and

appointed responsibilities!

Want to grow knowledge and skills,

favor collaboration and coach

team members to that take

responsibility for ”the whole”

I’m the Tester

I’m the Java Developer

I’m the Designer

An Agile Architect ?

A person highly skilled in architecture work

Works in, or close with, an Agile Development Team

Embraces the Agile/Lean values and principles • Collaborates with and coaches team members

• Acknowledges and empowers people

• Communicates architecture and decisions (face-to-face)

• Accepts and adapts to ideas from others

• Keeps things simple - travels light!

• Embraces and manages change!

Copyright Agesis AB

www.agesis.se 8

An Agile Architecture ?

Supports Agile Development! • Makes the system easy to understand, maintain and

build upon

• Reduce system complexity

• Makes the system easy to test, integrate and deploy

• Supports change

Copyright Agesis AB

www.agesis.se 9

Examples of Architecture

Requirements (Quality Attributes)

Structural • Modularity

• Maintainability

• Portability

• Reusability

• Integrability

• Testability

• …

Run-time • Performance

• Interoperability

• Scalability

• Reliability

• Availability

• Security

• Safety

• Usability

• … Architectural • Conceptual Integrity

• Correctness and completeness

• …

Copyright Agesis AB

www.agesis.se 10

Agile friendly Architecture

Requirements (QAs), examples

• Modularity

• Maintainability

• Testability

• Integrability

• Conceptual Integrity

• Scaled development

• Interoperability

• Usability (UX)

Copyright Agesis AB

www.agesis.se 11

Product and Anatomy (meta model)

Copyright Agesis AB

www.agesis.se 12

Marketable

“Product/Service” seen from the

Customer perspective

The ”product anatomy/structure” seen as a set

of modules/components/systems/services

A working

potentially releasable

increment

Requirements are described

as customer-oriented

Features

Customers /

Stakeholders

Feature

Feature

Feature

Feature

Smaller organization

One or few independent teams

A cross-functional and self-organizing

Development Team

• The knowledge and the skills needed to build increments of

the end-product, can be captured by one single team

• The team can take responsibility for architecture work

Feature

Feature

Feature

Feature

Feature

Copyright Agesis AB

www.agesis.se 14

working releasable

increment of the product

(Customer perspective)

Smaller organization,

one Development Team

pull

Include Architecture work

in the process events

Copyright Agesis AB

www.agesis.se 15

Daily Scrum

Sprint Review (demo)

Retrospective

Backlog Management

and Preparation

Sprint Planning

Feature

Feature

Feature

Example: Scrum

Development Team

Feature

Definition

of Done SAD

Feature

QAs

Arch.

Arch.

Feature and Component Teams

two Development Team stereotypes

• End-to-End oriented ‒ Take on (pull) customer-oriented Features, and produce

working product increments

• Highly cross-functional – Able to work across the product structure

– Develop, integrate and deploy “components” independently of other teams

Feature Teams

Copyright Agesis AB

www.agesis.se 17

Feature

Working product

increment

Feature

Feature Team

Feature Teams

Copyright Agesis AB

www.agesis.se 18

Feature

Working product

increment

Feature

Feature Team

Address Solution Architecture

+ Realize customer-oriented requirement

+ See to solution consistency

+ Integration, Acceptance Testing and Deployment

+ Address architecture requirements/qualities on solution level

‒ Performance

‒ Communication mechanisms

‒ Availability (overall fault detection and recovery)

‒ Scalability (solution level)

Feature Teams

Copyright Agesis AB

www.agesis.se 19

Feature

Working product

increment

Feature

Feature Team

! Usually need to work in parallel with other teams in the same code base ‒ Consistency and Conceptual Integrity (overall, components)

‒ Infrastructure and tools for cross-product and parallel work (CM, CI, CD)

• Specialists on one particular part of the

product structure - a “component”

– Owns and guards the component

• Develops, builds and delivers the component,

as a result of their work

Copyright Agesis AB

www.agesis.se 20

Component Teams

Feature

Req.

Req.

Component Team

Address “Component Architecture”

+ Integrity and responsibility

+ Testability

+ Maintainability

+ Performance

+ Reliability (robustness & usage, well defined API, …)

+ Availability (fault isolation and detection, recovery, …)

+ Scalability

Copyright Agesis AB

www.agesis.se 21

Component Teams

Feature

Req.

Req.

Component Team

! Need to break down Features into “component-oriented”

requirements

‒ Understanding of the whole picture and Customer value

! Awareness of overall Product Structure and Architecture

‒ Solution consistency and integrity

Copyright Agesis AB

www.agesis.se 22

Component Teams

Feature

Req.

Req.

Component Team

What type of teams to prefer?

• Can mix Feature Teams with Component Teams in

various constellations

– Prefer Feature Teams (focus on making Features done)

– Complement with Component Teams where strategic

• Note: Feature and Component Teams are stereotypes

– Try out what works, reflect and adapt

Copyright Agesis AB

www.agesis.se 23

Scaling up, multiple teams

A more complex product …

Copyright Agesis AB

www.agesis.se 25

working releasable

increment of the product

(Customer perspective)

One single team cannot span all the skills needed to build

increments of the “product”, nor meet the demand of work!

Feature

Customers &

Stakeholders

Feature

Feature

Feature

Feature

Feature

Feature

Higher demand

of work …

A group of Development Teams

with common focus

Copyright Agesis AB

www.agesis.se 26

workflow (end-to-end)

Feature

Customers &

Stakeholders

Feature

Feature

Feature

Feature

Feature Team A

Component Team B

• The teams need to collaborate and build working increments of

the product solution together (common responsibility)

• The teams also need to take responsibility for the architecture!

A cross-functional and self-organizing group of teams

working releasable

increment of the product

(Customer perspective)

Architecture and

code must scale!

Feature Team D

Feature Team C

Feature

Feature

Multiple Development Teams,

Architecture Governance

workflow(s) end-results

Cross-team governance, examples - Architecture

- Strategies for testing

- CM, CI, CD

- Requirements and User eXperience (UX)

- Infrastructure, environment and tools

- …

Multiple Development Teams,

Governance and Support

Copyright Agesis AB

www.agesis.se 28

workflow (end-to-end)

Copyright Agesis AB

www.agesis.se 29

Architecture governance, example

Feature Team C

Feature Team D

Component Team B

Feature Team A

Feature

Feature

I will create a new

asynchronous interface

for our component

Hmm, what is

the point with these

asynchronous calls ..?

Who the heck has

changed the interface?

All integration test

cases fail!

Feature Customers &

Stakeholders

Feature

Feature

Feature

Feature

?!

Architecture Forum, example

Copyright Agesis AB

www.agesis.se 30

Architecture

Forum (e.g. virtual team)

Members from different teams can meet and

coordinate architecture issues in a common

Architecture Forum / Community - Possibly facilitated by a senior ”Agile Architect”

Feature Team A

Component Team B

Feature Team C

• Experts that support and governs the

Development Teams

• Ensure common engineering practices –

overall consistency and integrity

• Works close with the Development Teams

– Communicate and explain the big picture

– Coach, mentor, educate, show how, review …

QAs

Arch.

Arch.

Architecture work, multiple teams

Copyright Agesis AB

www.agesis.se 31

• Need to map architecture work into

a Scaled Agile method/process

• Examples

– Scaled Scrum set-up

– Kanban, project/program/enterprise level

– SAFe (Scaled Agile Framework)

– …

Example, common Kanban workflow

Copyright Agesis AB

www.agesis.se 32

Analyze Develop Waiting for

Validation Validate Waiting for

Dev. Plan Implement Integrated

In Service

Feature

Feature

Feature

Feature

Story

Input

Analyze

• Architecture impact?

• Specify overall solution

• Break down work What team builds what?

Develop

• Plan

• Manage dependencies

• Coordinate and takt work

• Guard conceptual integrity

Validate

• Validate result

(Customer perspective)

• Validate solution

(reflect and improve)

Feature

Feature

Feature

Story

Story

Story

Feature Feature Story Story Story

Feature Story Story Story

Feature Story Story Story

Feature

Story

Story

Story

Story

Story

Story

Story

Story

Feature

Story

Story

Story Story

Story

Story

Note: WIP limits left out for this discussion

Scaling up, multiple workflows

QAs

Epic

Epic

Epic

Epic

Multiple workflows (SAFe)

Portfolio

Copyright Agesis AB

www.agesis.se 34

Epic

Epic

Feature

Feature

Feature

Feature

QAs

Feature Feature

Arch.

QAs

Feature

Arch.

Arch.

Feature

Roadmap

QAs

Epic

Arch.

Need to govern Architecture

within as well as across

the workflows

Solution and “component”

Architecture

Enterprise

Architecture

References and further reading

Agile Architect

http://www.agilearchitect.org

Agile Modeling, Scott W. Ambler

http://www.agilemodeling.com

Scaled Agile Framework (SAFe)

http://scaledagileframework.com

Lean Kanban University, David J. Anderson

http://www.leankanbanuniversity.com

Succeeding with Agile, Mike Cohn

https://www.mountaingoatsoftware.com

www.agesis.se

Om utbildningen !Certifierad IT-arkitekt Master

Michael Thurell Handledare och lärare

Kort om utbildningen

Start 1999

K54 sep 2015 >1500 IT-arkitekter

6 X 2 dagar

Inlämningsuppgifter���&

Arkitekturuppsats

”Alla” IT-arkitekter

Ca 25 lärare Personlig Handledare

Innehåll

Innehåll

1 Vad är IT-arkitektur?

Vad gör en IT-arkitekt?

Begrepp: System, egenskapskrav, ”tactics”,

mönster, ramverk, komponent, tjänst etc.

Standarder & arkitekturramverk:

ISO/IEC/IEEE 42010, Kruchten 4+1,

Rozanski & Woods, RM-ODP, TOGAF, Zachmann

Innehåll 2

Verksamhetsnära IT-arkitektur.

Verksamhetsobjekt och verksamhetskomponenter.

Verksamhetsmodellering.

Övergripande arkitekturarbete

(Enterprise Architecture).

Innehåll

6

3 Teknisk IT-arkitektur.

Arkitektur för distribuerade system.

Infrastruktur, middleware, databaser, säkerhet,

utvecklingsplattformar etc.

Realisering av egenskapskrav.

Innehåll

7

4 Metoder för arkitekturutveckling:

ADD, RUP, etc. Olika typer av Agila metoder etc.

Modellering med UML

Styrning av arkitekturarbete (Governance)

Metoder för arkitekturutvärdering: Scenariobedömningar, ATAM etc.

Innehåll 5

Mönster och stilar för integration.

”Point-to-Point”, ”Buss”, ”Nav” etc. SOA, EAI, ESB, etc.

Molnet.

Innehåll

6 Kvalitet och lönsamhet.

Test.

Ledningens syn på IT-arkitektur.

Trender.

Redovisning av uppsatsarbete.

Vad ”utmärker” en IT-arkitekt ? Egenskaper •  Kommunikativ & pedagogisk

–  förstå olika intressenters synpunkter och krav

–  förmedla, förklara och tydliggöra olika aspekter/vyer av en IT-arkitektur för olika intressenter

•  Analytisk & strukturerad –  se och förstå helheten –  förenkla komplexa frågeställningar –  kunna identifiera de viktigaste

arkitekturdrivande kraven •  Kreativ •  Ödmjuk •  Etc.

Förmågor •  Kunna behärska och tillämpa

etablerade principer och metoder för utformning av IT-lösningar

•  Kunna förstå & värdera verksamhetsmodeller

•  Kunna identifiera de arkitekturdrivande kraven i en komplex kravbild

•  Kunna omsätta systemkraven till en realiserbar arkitektur

•  Kunna behärska och tillämpa viktiga stilar & mönster för en IT-arkitektur

•  Kunna beskriva & kommunicera arkitekturen till aktuella målgrupper