agile@scale - agile day 2013

Agile Day 2013 – Agile@Scale: Hello World 1

Felice Pescatore

L’adozione di Agile in contesti enterprise

strutturalmente legati al pattern

command-and-control

PROGRAM AGILE_AT_SCALE DO 10, I=1,10 PRINT *,'Agile @Scale: Hello World!' 10 CONTINUE STOP END


In questo talk andremo a vedere come sia possibile adottare in un contesto particolarmente burocratizzato e fortemente legato al pattern command-and-control, un approccio Agile per l’Application Life Management (ALM), ovvero per la gestione dell’intero ciclo di vita di un progetto software di tipo enterprise.

Agile@Scale:Hello World

Abstract@scale…. What?


Il Sistema Software: dalla sua idea alla sua dismissione>Agile Framewok: Disciplined Agile Delivery>Applicazione pratica: il contesto della PA>

We talk about…. and more


A new project…

Salve capo, ho parlato con il cliente… ho capito tutto!!!! Allora domattina partiamo, tanto siamo Agili e possiamo correggere il tiro durante le iterazioni

Hmmm… fammi capire una cosa: hai fatto una previsione di costo (e di tempi) sul progetto? Siamo in grado di realizzare quanto richiesto con il know-how interno? A che rischi ci esponiamo?

Scusa, ma non siamo Agili? Mi stai dicendo di dover fare un’analisi up-front per rispondere alle mie domande in stile waterfall?

Dovrei fare un’analisi funzionale e concordare con il cliente quanto necessario.

@!#!!@@... beh forse basterebbero 6 mesi per lo sviluppo e 5/6 sviluppatori.

E il resto del Team di Delivery, oltre alle tecnologie, all’architettura ai tempi di messa in produzione e ai costi di manutenzione?

????? ma io…. io in realtà sono un Product Owner… queste cose sono più aspetti tecnologici e tecnici. Dovremmo discuterne con il Team….

Ma non abbiamo il Team e non possiamo costituirne uno senza avere un’idea di massima dei vari elementi del progetto che ci consentano di decidere se impegnarci o meno in esso.

@!#!!@@...

Forse questo Agile non è proprio un granché.


Quando dobbiamo ultimarlo ?

Che linguaggio usiamo?

Chi fa cosa?

Perché non utilizziamo

l’ultimo framework per

questo?

Ancora un’altra attività? Ho

troppe cose da fare!

Il PM (Team Lead) non mi convince.

Quali funzionalità

inseriremo nella prima versione?

Qual è l’architettura del sistema?

Devo aggiornare le mie competenze

Qual è il Data Model del sistema?

Software ProjectVisto dallo SVILUPPATORE


Quando tempo impiegheremo?

Quanto ci costa?

Chi allochiamo come capo progetto?

Chi è il principale sponsor

finanziario? (chi ci paga?)

Quante risorse per il

Team di Dev?

Possiamo riutilizzare qualcosa già fatto?

Quali funzionalità inseriremo nella prima versione?

Siamo sicuri di farcela con i tempi e con i costi stimati?

Come facciamo a monitorare e controllare le attività?

Riusciremo a sviluppare un

sistema di qualità?

Software ProjectVisto dal BUSINESS


Internal Stakeholder

Project Manager

DevOps

Soluzioni rispondenti alle atteseMinore Time-to-marketROI più cortoRiduzione waste-time….

>>>>

Customer( & stakeholders)

BUSINESS Deployment Team

Company Sponsor

Team Lead

Software Architect

Business Value

• Reduce Time-to-Market• Augment Value-To-

Market• Increase Quality-To-

Market• Increase Flexibility• Increase Visibility• Reduce Cost• Increase Product

Lifetime

Business Smell

• Quality Delivered to Customer Is Unacceptable

• Delivering New Features to Customer Takes Too Long

• Features Are Not Used by Customer

• Software Is Not Useful to Customer

• Software Is Too Expensive to Build

• Us Versus Them• Customer Asks for Everything

Including the Kitchen Sink

Creare VALORECommon objective


Scrum

Agile M

odeling

TDD

FDD XP

Agile d

ata M

ethod

Lean Dev

elopmen

t

MS solution Fr

amew

ork

Adaptive

Software

Dev.

Crystal

Six Si

gma

Dynam

ic Syst

em Dev

0.00%

2.00%

4.00%

6.00%

8.00%

10.00%

12.00%

14.00%

2010 2009

ISO 9000

CMMI

Waterfall

Spirale

RUP

Iterative

Nessuna

Agile

0.00% 10.00% 20.00% 30.00% 40.00% 50.00%

2009 2010

Agile

Ado

ption

(38,

6 %

)

(2010) Base: 1,023 application development professionals(2009) Base: 1,298 application development professionals

Source: Forrester/Dr. Dobb’s Global Developer Technographics® Survey, Q3 2010†Source: Forrester/Dr. Dobb’s Global Developer Technographics Survey, Q3 2009

Agile

Met

hodo

logi

es

IT Project ManagementWorld most used Methodology


Agile

PU

RE A

dopti

on (2

6 %

)

Source: Forrester/Dr. Dobb’s Global Developer Technographics® Survey, Q3 2009

47%

15%

26%

3%9%

Our methodology is a help-ful guide, but we diverge from it in order to deliver on timeWe follow our methodology closely and seldom diverge from itOur methodology is key to the success of our projectWe pay lip service to our methodology, but it’s really shelfwareOur methodology neither helps, nor impedes our progress

termine derivato da una ricerca di Forrester intitolata “Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today”.

Si rischia di complicare la governance del progetto prendendo a caso pezzi del mondo Agile e pezzi del mondo Waterfall:• profonda modellazione e pianificazione;• approccio simil-Scrum per il development della

soluzione;• processo di delivery complesso e lungo.

Pure Agile?sorry, Water-SCRUM-Fall


Business + Deploy Team + Customer & External Stakeholders

Inception

Construction & Transition

Disciplined Agile Delivery (DAD) è un process framework Agile utile a gestire in modo integrato l’ALM in contesti enterprise, prediligendo un approccio:

• People-first

• Learning-oriented

• Risk and Value driven

• Goal-driven

• Hybrid

• Enterprise aware

• Scalable

Unified Process (UP)

Extreme Programming (XP)

Scrum

HarmonyProcess

Disciplined Agile

Delivery (DAD)

Lean

Agile

Modeling

«Hybrid process framework» che adotta il meglio delle pratiche e delle filosofie delle varie metodologie “CORE” Agile

Disciplined Agile DeliveryOur choice


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

The Road Ahead for agility@scale


• Lavorare prima sugli elementi a maggior Valore per gli stakeholder;

• Continua verifica del Valore prodotto;• Determinare quando è stato state implementate

funzionalità sufficienti a soddisfare il Valore richiesto;

• Produrre sempre soluzioni potenzialmente utilizzabili durante il ciclo di vita;

• Valutare continuamente nuovi elementi di lavoro aggregate alla crescente comprensione di ciò che realmente si vuole ottenere. Value

Driven

Value & Risk DrivenGoal based

Risk

D

riven

• Validare l’Architettura il prima possibile;• Ottenere il consenso degli Stakeholder con

dimostrazioni pratiche;• Essere compliance con la direzione aziendale

(enterprise aware);• Lavorare prima su ciò che porta un reale

incremento di know-how al Team;• Abbattere il debito tecnico;• Utilizzare degli Spike per verificare specifiche

assunzioni.


GOAL… must be S.M.A.R.T

GOAL: a measurable value…. not only… GOAL must be SMART!

• Specific, ovvero chiaro e identificabile (es: abbattere il Time-to-Market);• Measurable, implica la possibilità di tracciare i progressi e capire quando si è raggiunto

l'obiettivo (es: il nuovo Time-to-Market deve essere di 3mesi);• Achievable, ovvero alla portata del Team che lo prende in carico (es: il nuovo Time-to-

Market deve essere di 1gg non è ragionevole);• Relevant, deve essere sentito come qualcosa di importante (es: in generale, interessa a

ben pochi che avete impiegato 2gg per migliorare - un algoritmo di ricerca di 1ms);• Timely, sviluppato quando richiesto.


DAD contempla al suo interno un modello di qualità che prende il nome

di 3C Rhythm, ovvero un Ritmo (o se vogliamo Cadenza) scandito su tre

Accenti.

Collaborate ConcludeCoordinate

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

P - Plan. Pianificazione;

D - Do. Esecuzione del programma, dapprima in contesti circoscritti;

C - Check. Test e controllo, studio e raccolta dei risultati e dei riscontri;

A - Act. Azione per rendere definitivo e/o migliorare il processo

Ciclo di Deming (Deming Cycle) che prevede un miglioramento costante grazie ad una interazione tra ricerca, progettazione, test, produzione e vendita

Coordinate::Plan

Collaborate::Do e parte di Check

Conclude::parte di Check ed Act

3C Rythm…not only music!


Le Persone ed il modo in cui collaborano sono l’elemento primario per il successo

Self Disciplined: impegnati solo sul lavoro che si è in grado di fare

bene

Self Organizing: stima e pianificazione del proprio

lavoro

Self Aware: capire come migliorarsi

Cross functional teams

Specialisti trasversali

Nessuna gerarchia nel Team

DAD

TEA

M M

embe

rs a

re e

ncou

rage

d to

People FirstPrinciples and Values


Domain learning

Primo approccio ai requisitiRilascio incrementali di soluzioni

potenzialmente utilizzabiliPartecipazione attiva degli stakeholder durante tutto il ciclo di vita del sistema

Technical learning

Spike ArchitetturaliConfutare le scelte Architetturali

tramite soluzioni funzionanti (working code)

Process improvement

Retrospettiva alla fine delle IterazioniMonitoraggio dei miglioramentiCondivisione degli skill tramite la

pratica del “non-solo development”

General strategies

TrainingEducation

Mentoring/coachingI Membri del Team sono “general specialist” e non solo “specialist”

People FirstLearning Oriented


People FirstPotential roles on disciplined agile teams

Primary roles• Stakeholder• Team Lead• Product Owner• Agile Team Member• Architecture Owner

Busi

ness

An

alys

t

• Domain Expert• Technical Expert• Independent Tester• Integrator• Specialist

Secondary roles

Project M

anager


Pratiche:

• Partecipazione attiva degli stakeholder;

• Soluzioni potenzialmente utilizzabili ad ogni iterazione;

• Risk-value lifecycle;

• Review esplicite di milestone light-weight

• Meeting giornaliero di coordinamento;

• Demo al completamento di ogni iterazione;

• Demo «all-hands», ovvero con il supporto di tutto il Team e tenuta a rotazione;

• Seguire le convenzioni aziendali;

• Lavorare a stretto contatto con gli Architect aziendali;

• Metriche automatizzate per la valutazione dei risultati in ottica auto-

migliorativa.

• Un aggiornamento continuo dello stato di

avanzamento del progetto (fotografia) agli

stakeholder;

• Importanti momenti di condivisione per consentire

agli stakeholder di indirizzare lo scope del

progetto;

• Richiede un impegno superiore per gli stakeholder

che devono essere fattivamente presenti.

Un Team Agile, per propria natura, fornisce:

Enterprise AwareGoverning Agile Team


• Seguire le convenzioni aziendali:

• Standard e best practice Architetturali;

• Best practice di Codifica;

• Best practice di gestione dei Dati;

• Linee guida nella definizione della User

Interface (UI);

• Riutilizzare e sfruttare al massimo le

infrastrutture aziendali;

• Migliorare e sviluppare le infrastrutture

aziendali;

• Lavorare a stretto contatto con l’Enterprise

Architecture (EA) Team.

• Contribuire alla crescita personale e del

Team;

• Contribuire alla crescita dell’azienda nel

complesso;

• Arricchire e rafforzare il know-how

relativo all’Agile.

• Enterprise Architecture Team;

• Data Management Team;

• Governance Aziendale;

• Quality Assurance;

• Project management Office (PMO).

Segu

ire le

con

venz

ioni

az

iend

ali

Mig

liora

re l’

ecos

iste

ma

azie

ndal

eCondivisione della

conoscenzaInterazione

Enterprise AwareKnow your company


BASICAgile Based

DisciplinePersonal Agility

«DAD promotes following a full delivery lifecycle – be it a Scrum-based one, an agile one, a continuous delivery one, or something else – that is as light as your situation allows.»

Process ModelBase, Agile Based


ADVANCEDLean Based

DisciplinePersonal Agility

MORE

Process ModelAdvanced, Lean Based


Proj

ect /

Pro

duct

App

rove

d to

star

t

Stak

ehol

der c

onse

nsus


• 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 settimaneMedia: 4 settimane

Caso Peggiore: Più mesi

Qualche ora

Inception PhaseFirst Phase


Stak

ehol

der c

onse

nsus

Suffi

cien

t Fun

ction

ality


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

Construction PhaseSecond Phase


Itera

tion

star

t

Pote

ntial

ly c

onsu

mab

le s

oluti

on


• 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.

Construction PhaseTypical Construction Iteration


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

Construction PhaseTypical Construction Day


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;

• Training degli stakeholder.

• Review dello stato di ready in produzione;

• Deploy della soluzione.

Idealmente: nessun effort temporaleTipicamente: 1 ora a settimana per l’intera

fase

Idealmente: nessun effort temporaleMedia: 4 settimane


Idealmente: meno di un ora


Transition PhaseThird Phase


Inception Goal Construction Goal Transition Goal

• 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

• Migliorare i process e l’ambiente

• Sfruttare le infrastrutture esistenti

• Governare il rischio

Ongoing Goal

Phases GoalsNot all iterations are created equal!


Ancitel: azienda operante nel campo dei servizi per la PA

Tutto bello, ma funziona?

Case StudyAncitel SpA

Si, con disciplina e impegno!


Services and Meta Services for SMART e-Government

• SMART è un progetto sperimentale di ricerca industriale che vuole rispondere in modo innovativo ai bisogni nel mercato dei servizi di e-Government.

• In collaborazione con l’Università di Milano Bicocca e altri partner industriali, SMART affronta il tema dei servizi di e-Government a disposizione del cittadino applicando in modo industriale l’approccio innovativo della service science, in cui produttore e consumatore collaborano insieme per realizzare un sistema a valore aggiunto.

• Nella progettazione dei servizi si considerano i punti di vista di tutti gli attori interessati (cittadini, imprese, Pubbliche Amministrazioni) combinando, integrando e realizzando servizi a valore aggiunto

• Per realizzare il progetto SMART, è stato aperto un laboratorio di ricerca ed innovazione nella sede di Napoli.

Case StudyAncitel SpA – Laboratorio Smart


Ancitel: azienda operante nel campo dei servizi per la PA

• Team junior e neo-formato• Nessuna adozione Agile pre-esistente• Complessità dello scenario di riferimento• Contesto di fruizione non preparato ad

una costante collaborazione ed interazione

• Iniziale diffidenza del resto della struttura IT


• Laboratorio «SMART» di innovazione per la PA

• Nuovo progetto• Membri del Team assolutamente

entusiasti• Apertura e disponibilità dei dirigenti

aziendali• Possibilità di adozione di tool maturi ed

innovativi• Completa fiducia dai diretti responsabili


Inception


PROPOSALINTENTIONAL

ARCHITECTUREPLAN & COST

ESTIMATION


Construction



Transition



DEMO

Agile@Scale and…… at Work!


THANK YOU @felicepescatore

Disciplined Agile Delivery Italy Group

www.felicepescatore.it

Agile Software Architect & Metodology HeadAncitel Spa

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