agile@scale: be safe!

Agile@Scale: be SAFe!DAD & SAFe

07 Aprile 2014

@felicepescatore Disciplined Agile Delivery Italy Groupwww.felicepescatore.it

Felice Pescatore

http://www.linkedin.com/groups/Disciplined-Agile-Delivery-Italy-4784996?gid=4784996&trk=hb_side_g

Agile@Scale: be SAFe!

Reality is complex… software is complex!

COMPLEX

EmergentPractices

COMPLICATED

Good Practices

CHAOTIC

NovelPractices

SIMPLE

BestPractices

Cynefin Model

2


Too complicated and too complex for traditional approach

If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach (measure and adapt)

is the method of choice. - Ken Schwaber

Empirical (Adaptive) Process

Proc

ess

Controls

Inpu

ts

Out

puts

Plan – measure – adapt – repeat

3


Con il cappello “Agile” non si intende un insieme di processi e tool.

Agile è un set di Valori e Pratiche su cui basare le proprie attività, e, perché no, I processi e i tool utilizzati.

Agile… what?

4


Agile Manifesto

5


What Agile isn’t…

6


DSDM Atern

RUP / Open UP

FDD

Fuller Approaches (still agile)

SCRUM

Crystal

eXtreme Programming

Lightweight Approaches

Disciplined Agile Delivery, DAD Scaled Agile Framework, SAFe@Scale

Agile

Risk

Prob

lem

Agile Umbrella

7


Domain Complexity

Straight-forward

Intricate,emerging

Compliance requirement

Low risk Critical,audited

Team size

Under 10developers

1000’s ofdevelopers

Co-located

Geographical distribution

Global

Enterprise discipline

Projectfocus

Enterprisefocus

Technical complexity

Homogenous Heterogeneous,legacy

Organization distribution(outsourcing, partnerships)

Collaborative Contractual

Disciplined AgileDelivery

Flexible Rigid

Organizational complexity

@Scale… what?

8


A project is more than only development…

@Scale… why?

9


The Idea, the Build, the Environment

Aggredire il mercato con una nuova idea• Generata dall’esigenza, Pensata per creare un’esigenza

• Chi finanzia il progetto? Quali sono i rischi? Di quante persone ho bisogno? Quanti Team? Dove avvengono le attività? Quali sono le tecnologie di supporto?, ...

Program Level & Inception

Program Level & Inception• Creare il Program Backlog (Feature), Creare i Team Backlog (User Story),

Identificare i PSI (Potential Shippable Increment), ….

Team Level & Construction• Prendere in carico il Team Backlog, Definire le iterazioni in relazione ai PSI,

Definire i Task, Scegliere le pratiche da utilizzare, …

Program Level & Transition• Completato lo sviluppo, il sistema deve essere manutenuto in

erogazione e fruibile correttamente da client di tipologia diversa (anche molto!)

10


Leaders (in ALM) have strong capabilities in agile practices, including driving portfolio management support and support for enterprise agile capabilities, such as SAFe and Disciplined Agile Delivery (DAD)*

* Tratto da: Magic Quadrant for Application Development Life Cycle Management (19 November 2013)

SAFe and DAD

11


SAFe, Scaled Agile Framework

• Framework maturo per l’adozione di pratiche Agili all’interno di contesti Enterprise

• In grado di gestire, con successo, un ampio numero di «Agilisti» e di Team

• Costruito sui principi delle metodologie Agile@Core e Lean

• Sincronizzazione tra sviluppo e delivery

Grazie alla «Big Picture» è possibile evidenziare le relazioni ed i ruoli dei vari attori aziendali che

concorrono al processo Agile@Scale, unitamente agli artefatti e le cerimonie di riferimento

12


SAFe «Big Picture»

13


SAFe: Portfolio Level

Ruoli / Team

• Program Portfolio Manager

• Enterprise Architect• Epic Owner

Cerimonie

• Strategic Investment Planning

• Kanban Portfolio Planning: Epic

Artefatti

• Investment Themes• Business and

Architecture Epics• Portfolio Backlog• Portfolio Vision• Metrics

14


SAFe: Program Level

Ruoli / Team

• Product Management• Release Management• System Team• DevOps• Business Owners• System Architect• Release Train Engineer• UX Architect

Cerimonie

• PSI/Release Planning• System Demo• Inspect & Adapt

Workshop

Artefatti

• Product Roadmap• Vision• Program Backlog• Team Backlog• NFRs• Architecture Runway• Business and

Architecture Feautures• PSI Objectives • Metrics

15


SAFe: Team Level

Ruoli / Team

• Agile Teams• Product Owner• Scrum/Agile Master

Cerimonie

• Sprint Planning• Backlog Grooming• Daily Stand-up• Sprint Demo• Sprint Retrospective• HIP Sprints

Artefatti

• Team Backlog (vincolato dai NFRs)

• Team PSI Objective• Sprint Goals• Working Software• Spikes• Metrics

16


DAD, Disciplined Agile Delivery

• Framework per lo sviluppo di soluzioni End-to-End con ampia libertà di personalizzazione

• Costruito sui principi delle metodologie Agile@Core e Lean

• Scalabile, people-first oriented, learning oriented, goal-driven, enterprise aware, risk and value driven

• Linee guida per la governance di team enterprise secondo le best-guide Agili

Grazie alla «Big Picture» è possibile evidenziare le fasi di sviluppo di una soluzione end-to-end in ambito enterprise

secondo i principi Agili.DAD è un framework ibrido, Value & Risk driven, fortemente

orientano alle persone e al loro apprendimento, il tutto con la finalità di produrre in modo ottimale il delivery della soluzione.

I

C

T

Inception

Construction

Transition

17


DAD, Agile Big Picture

Inception Construction 1 Construction 2 Construction 3 Transition 1 Construction 4 Transition 2

Avere una visione

PSI PSI PSI Deploy in Produzione

New PSI (Next Release)

Nuovo Deploy in Produzione

PSI: Potential Shippable Increment

18


DAD, Lean Big Picture

Inception Lean Construction 1 Transition 1 Lean Construction 2 Transition 2

Avere una visione PSI when Done Deploy in Produzione New PSI (Next Release)

Nuovo Deploy in Produzione

PSI: Potential Shippable Increment

19


THE AGILE 3C RHYTHMConcept

Inception

Coordinate

Construction

Collaborate

Transition

Conclude

Release rhythm

Iteration rhythm

Development

Collaborate

Iteration Planning

Coordinate

Stabilize

Conclude

Daily rhythm

Coordination

Meeting

Coordinate

Daily Work

Collaborate

Stabilize

Conclude

La terna (rhythm) Coordinate-Collaborate-Conclude ritorna a vari livelli in un progetto

governato tramite DAD:

20


DAD PHASES: INCEPTION

Sta

keh

old

er

con

sen

sus

Pro

ject

/ P

rod

uct

Ap

pro

ved

to

startCollaborate ConcludeCoordinate

• Individuare i possibili Team Member;

• Pianificare una sessione di “vision” del progetto;

• Precettare gli stakeholder per la sessione di “vision” .

• Rifinire la Vision;

• Effettuare una prima valutazione dei requisiti;

• Effettuare una prima ipotesi Architetturale;

• Valutare la fattibilità del progetto;

• Creare un primo Release Plan;

• Strutturare il (i) Team;

• Settare l’ambiente;

• Garantirsi la sostenibilità economica

• Identificare i rischi.

• Review di quanto definite (mailstone);

• Comunicare la Vision agli stakeholder;

• Impegnarsi sulle Iterazioni ed i rilasci continui.

Fino ad alcune ore(se tutti gli

stakeholder sono disponibili)

Idealmente: 1-2 settimane

Media: 4 settimaneCaso Peggiore: Più

mesi

Qualche ora

21


DAD PHASES: CONSTRUCTION PHASESecond

Sta

keh

old

er c

on

sen

sus

Suffi

cien

t Fun

ction

ality

Collaborate ConcludeCoordinate

Dimostrare che le assunzioni Architetturali sono corretti tramite pezzi funzionati della stessa

• Produrre incrementalmente soluzioni utilizzabili;

• Condividere lo stato del progetto con gli stakeholder;

• Essere in linea con gli obiettivi organizzativi;

• Allinearsi con gli altri Team;

• Migliorare se stessi ed il Team nell’insieme.

• Determinare quando quello che si è sviluppato è sufficiente per il raggiungimento degli obietti;

• Stabilizzare la soluzione.

Tipicamente: 1 iterazioneCaso peggiore: Molte

iterazioni

Tipicamente: diverse iterazioni Idealmente: alcune

ore

22


DAD PHASES: AGILE CONSTRUCTION PHASETypical Construction Iteration for Agile DAD Approach

• Iteration planning

• Iteration modeling

Pratiche standard:

• Focalizzare le attività;

• Meeting di Coordinamento giornaliero;

• Test di regressione;

• Evoluzione dell’Architettura ed eventuali Spike relativi (task di una o più story);

• Continuous Integration;

• Refactoring;

• Ritmo sostenibile;

• Priorizzare i work item;

• Attività di configurazione;

• “Track “done” delle attività (es. Burndown)

• JIT model storming

• Iteration demo;

• Retrospettiva;

• Valutare le funzionalità sufficienti al raggiungimento dell’obiettivo;

• Aggiornamento del Release plan.

2 ore per ogni settimana

dell’iterazione

Tipicamente: due settimane nel caso di progetti standard,Quattro settimane nel caso di progetti complessi con

integrazione tra Team cross-agile Caso peggiore: Sei Settimane

2 ore per ogni settimana

dell’iterazione

Pratiche avanzate:

• Test-driven development (TDD);

• Acceptance TDD;

• Continuous deployment (CD);

• Parallel independent testing;

• Non-solo development;

• Look-ahead modeling;

• Look-ahead planning;

• Continuous documentation.

Itera

tion

star

t

Pote

ntial

ly c

onsu

mab

le s

oluti

on

Coordinate Collaborate Conclude

23


DAD PHASES: AGILE CONSTRUCTION PHASETypical Construction Day


Star

t of D

ay

Wor

king

Bui

ld

• Meeting di coordinamento giornaliero;

• Aggiornamento della Taskboard

• Aggiornamento dell’Iteration Burndown.

• Affrontare i problemi bloccanti;• Creare i test;• Sviluppare codice;• Integrare quanto sviluppato;• Risolvere i problemi ed i bug;• Modellazione;• Validazione del Codice.

• Stabilizzare quanto realizzato.

Fino a 15 minuti Tipicamente: 5 o 6 ore Idealmente: Non necessario

24


DAD PHASES: TRANSITION PHASEThird

Suffi

cien

t fun

ction

ality

Prod

uctio

n re

ady


Pianificazione • Piano di transizione;

• Testing e fixing di fine sviluppo;

• Pilot della soluzione;

• Finalizzare la documentazione;

• Comunicare il deployment;

• Preparazione ambiente di erogazione;

• Training degli stakeholder.

• Review dello stato di ready in produzione;

• Deploy della soluzione.

Idealmente: nessun effort temporale

Tipicamente: 1 ora a settimana per l’intera

fase


Media: 4 settimaneCaso Peggiore: Più

mesi

Idealmente: meno di un ora

Caso Peggiore: Più mesi

25


GOAL DRIVENNot all iterations are created equal!

Construction Goals Transition GoalsInception Goals• Costituire il Team

• Identificare la Vision del progetto

• Portare gli stakeholder a concordare sulla Vision

• Essere allineati al contest aziendale

• Identificare la strategia tecnica iniziale, i requisiti iniziali e definire il piano di release iniziale

• Configurare l’ambiente (fisico e digitale) di lavoro

• Assicurarsi la sostenibilità economica del progetto

• Identificare i rischi

• Produrre sempre una soluzione potenzialmente utilizzabile

• Catturare le richieste di cambiamento proveniente dagli stakeholder

• Avvicinarsi velocemente ad una release per il deploy

• Mantenere e migliorare i livelli qualitative esistenti

• Verificare il prima possibile l’architettura

• Garantire che la soluzione è pronta per la produzione

• Essere sicuri che gli stakeholder sono pronti per usare la soluzione

• Effettuare il deploy della soluzione in produzione

• Compiere la missione del progetto

• Incrementare le competenze (skill) dei Team Member

• Migliorare le infrastrutture esistenti

Ongoing Goals• Migliorare i process e l’ambiente

• Sfruttare le infrastrutture esistenti

• Governare il rischio

26


DAD Governance Strategy

• Esistono modalità diverse di governance per i progetti @Scale, in particolare rispetto al contesto di applicazione

• DAD supporta differenti strategie e modalità di governance

• Le strategie fanno tesoro di quanto già in essere presso l’azienda

• Applicare ogni decisione quanto più localmente possibile

Corporate

Investimenti ITOperationDelivery/Deployment

SecurityInfrastrutture(Servizi, Cloud…)Dati

Information Technology

27


SAFe Governance Deliverable and Alignments

Shared Resources• Operat.l Acceptance Plan• Acceptance Criteria Plan• Reqs Specification Doc• Sys Security Plan• Production Ops Manual• Security Guide• 508 Certification• ATO• Privacy Impact Assess• User Guide• SLA

Program Portfolio Man.• Quad Chart• IPT Charter• BRD• Project Charter• Acquisition Strategy

Program and Release Management• PMP• Transition Plan• Risk Register/Log• Outcome Stmt• Version Description Doc• Deployment Plan• Lessons Learned

• Legislation• Budget• Policy• Directives

• Architectural Standard

• Data Exchange Standards

• Hosting Stregies

• Security Standards

System Architect• System Design Doc

System Team• Test Evaluation• Master Test Plan

Ruoli SAFe con responsabilità inerenti la documentazionedell’SDLD (Software Development Lifecycle Documentation)

28


DAD «on» SAFeInceptionI ConstructionC TransitionT

I C TI C T

29


DAD «on» SAFe

I

30


DAD «on» SAFe
















• Impegnarsi sulle Iterazioni ed in rilasci continui.



Idealmente: 1-2 settimaneMedia: 4 settimane


Qualche ora

I

31


DAD «on» SAFe





















Qualche ora

I

32


DAD «on» SAFe





















Qualche ora

I

33


DAD «on» SAFe





















Qualche ora

I

34


DAD «on» SAFe



Pratiche standard:






• Refactoring;






• Iteration demo;

• Retrospettiva;



Pratiche avanzate:


• Acceptance TDD;







Coordinate Collaborate ConcludeC

35


DAD «on» SAFeInceptionI ConstructionC TransitionT

I C TI C T



Pratiche standard:






• Refactoring;






• Iteration demo;

• Retrospettiva;



Pratiche avanzate:


• Acceptance TDD;








C

36


DAD «on» SAFe



Pratiche standard:






• Refactoring;






• Iteration demo;

• Retrospettiva;



Pratiche avanzate:


• Acceptance TDD;








C

37


DAD «on» SAFe

38



Pratiche standard:






• Refactoring;






• Iteration demo;

• Retrospettiva;



Pratiche avanzate:


• Acceptance TDD;








C


DAD «on» SAFe



Pratiche standard:






• Refactoring;






• Iteration demo;

• Retrospettiva;



Pratiche avanzate:• Test-driven

development (TDD);

• Acceptance TDD;








C

39


DAD «on» SAFe

I C TI C T







• Preparazione ambiente di erogazione






fase


Media: 4 settimaneCaso Peggiore: Più mesi



T

40


DAD «on» SAFe

41













fase





T


DAD «on» SAFeTransitionT







• Preparazione ambiente di erogazione






fase





42

T


DAD «on» SAFeCollaborate ConcludeCoordinate




• Finalizzare la documentazione








fase





T

43


DAD «on» SAFe













fase





T

44


DAD «on» SAFe













fase





T

45


SAFe Key Point

• Framework maturo e robusto, ben documentato e utilizzato in diversi contesti reali;

• Ruolo centrale delle persone in tutte le fasi di delivery, con ruoli chiari, artefatti precisi e eventi espliciti;

• Visione olistica dell’organizzazione aziendale, con una identificazione di 3 livelli di partecipazione e valore;

• Focus sulla qualità del software (Agile & DevOps);

• Costanti review ed aggiornamenti.

• Prescrittivo;

• Pesante/Complesso;

• Incentrato sui processi di Certificazione;

Pro Pro

46


DAD Key Point

• Framework ibrido che si fonda su approcci Agile e Lean affermati;

• La gestione delle milestone permette di adattarlo a contesti enterprise reali;

• Ampia flessibilità rispetto alle pratiche Agili da adottare;

• Forte attenzione sugli aspetti architetturali ed ingegneristici;

• Governance chiara per i program/product manager.

• Adozione poco nota;

• Limitata azione di formazione per la certificazione;

• Mancanza di prescrizioni per un’adozione sistematica delle pratiche Agili.

Pro Pro

47


@felicepescatore

ABOUT MEget in touch

Disciplined Agile Delivery Italy Group

Felice Pescatore, Agile Software

Architect

Email: [email protected]

Cell. 392/7157684

www.felicepescatore.it

48



mailto:[email protected]


THANKS FOR WATCHING

Quest'opera è distribuita con Licenza Creative Commons Attribuzione - Non commerciale 3.0 Italia.

http://creativecommons.org/licenses/by-nc/3.0/it/




agile@scale: be safe!

Engineering

scale agile agile umbrella

agile practices

processo agile

agile manifesto

agile isnt

agile delivery framework

enterprise agile capabilities

dad safe