How to be Agile - ABC of team working

How to be Agile
Paolo Sammicheli
paolo@sammiche.li - @xdatap1
ABC of Team Working

● Presentata nel 1970 da Winston W. Royce a una conferenza
ingegneristica: IEEE WestCom.
● Processo sequenziale in cui ogni fase è completata prima che la
successiva sia iniziata.
WATERFALL

● Rigidità: il committente del progetto, anche a
fronte di cambiamenti dello scenario del
mercato, ha difficoltà ad influire su quanto
richiesto, perché la fase di progettazione è
tutta all’inizio
LIMITI DEL WATERFALL
●
Time to Market: il committente del progetto non
riceve nulla se non in fondo al progetto, che
spesso dura mesi se non anni.
●
Costi elevati e non predicibili: quello
che appare come un processo lineare ed
efficiente diventa spesso una serie di cicli
turbolenti che fanno perdere tanto tempo
e tanti soldi.

The CHAOS Report (1994)
Source: http://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf
Type 1:
Progetti completati rispettando tempi e budget prefissati
Type 2:
Progetti completati ma senza rispettare tempi e budget
Type 3:
Progetti abortiti prima del loro completamento.
16,2%
52,7%
31,1%
31,1%
52,7%
16,2%

The CHAOS Report (2001)
Source: http://www.cin.ufpe.br/~gmp/docs/papers/extreme_chaos2001.pdf
Type 1:
Progetti completati rispettando tempi e budget prefissati
Type 2:
Progetti completati ma senza rispettare tempi e budget
Type 3:
Progetti abortiti prima del loro completamento.
28%
49%
23%
23%
49%
28%

"The Roman bridges of antiquity were very inefficient structures. By
modern standards, they used too much stone, and as a result, far too
much labour to build. Over the years we have learned to build
bridges more efficiently, using fewer materials and less labour to
perform the same task." - Tom Clancy (The Sum of All Fears)
Source: http://www.projectsmart.co.uk/docs/chaos-report.pdf

Nel 2001 diciassette professionisti di spicco si radunarono in una
località sciistica dello Utah per discutere assieme del futuro del
mondo software, stanchi di assistere ad una
percentuale sempre crescente di progetti
software che si frantumavano
sulle rocce al termine della
cascata.

Manifesto per lo Sviluppo Agile di Software
Stiamo scoprendo modi migliori di creare software,
sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti
Gli individui e le interazioni più che i processi e gli strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano
Ovvero, fermo restando il valore delle voci a destra,
consideriamo più importanti le voci a sinistra.

PLAN ANALYSIS DESIGN CODE TEST DEPLOY
ANALYSIS
DESIGN
CODE
TEST
PLAN
DEPLOY
ANALYSIS
DESIGN
CODE
TEST
PLAN
DEPLOY
ANALYSIS
DESIGN
CODE
TEST
PLAN
DEPLOY
Modello di sviluppo AGILE
Modello di sviluppo WATERFALL

3 year transition: 2005 – 2008
Results in 2008:
200 scrum teams world wide, total approx. 1500+ employees
Average Team Velocity increase estimated at +35% / year
Development cost reduction of over USD 1 million / year
ROI on transition and trainings about 100% in first year
http://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption

Down to 1 release/yr
Scrum adoption: 3 months
Salesforce.com - 2007
Results:
60+ Critical features delivered in < 9 months
“Idea to Release” avg. rate: 2.2 quarters
70% of “Top 10 Ideas” are on track for delivery in 2007

All bugs are fixed for the
release
All high level bugs are fixed
for the release. Medium and
low level bugs are not fixed
Product quality
index
Client
feedback
Burndown ChartNoneVisibility tools
Progress
tracking
4070
Average
working
hours/week
6040Defects fixed
53New features
Increase in
productivity
Release with ScrumRelease before ScrumMetricCategory
HCL EAI Services Inc.
Enterprise application integration
services: healthcare, retail,
telecommunication, wireless.

2010
Videocitofono Touch
Metodologia Waterfall
· 15 anni uomo di effort
· 3 anni di sviluppo
· Scarso impatto sul
mercato
· Time to market
inaccettabile
–
2014
Videocitofono Serie 300
Metodologia Agile
· 3 anni uomo di effort
· 1 anno di sviluppo
· Prodotto innovativo
· Time to market
competitivo
· Visibilità di processo
Fonte: Agile for Innovation, Milan 3 March 2015

http://www.cio.com/article/368313/100_Most_Agile_Companies_Honored
100 Most Agile Companies Honored (2004)
Aerospace
Automotive Manufacturing
Banking/Investment
Business/Consumer Services
Communications
Computer Manufacturing
Education
Financial services
Government
Health Care/Health Insurance
Insurance
Legal Services
Manufacturing/Process Industries
Pharmaceuticals
Retail/Wholesale
Technology Services
Transportation/Distribution

COME OTTENERE QUESTI RISULTATI?

AGILE
OVERVIEW
© Paolo Sammicheli 2015

PRACTICES
METODOLOGIES
PRINCIPLES
VALUES

PRACTICES
Planning
Game
Test Driven
Development
Behaviour Driven
Development
Continuous
Integration
Continuous
Refactoring
Pair Programming
Small Releases
Collective code
ownership
Management 3.0
#Workout
Coding standard
System metaphor User Stories
Personas Product Canvas Jobs Stories
Popcorn Flow Retrospectives StandUp Meetings
U.S. Mapping
Lean Change
Canvas
…

METODOLOGIES
eXtreme Programming
KanbanSCRUM
DSDM ATERN FDD
SAFe DAD LeSS
Lean Software
Development
AgileUP

PRINCIPLES
Lean Change
AGILELEAN
Lean Startup
Radical Management
Kaizen Cynefin

VALUES
AGILELEAN

MAGIC BALLS
· Le palle all'inizio non hanno energia.
· Per diventare magiche devono essere toccate da tutti i
membri del team.
· Due membri non possono toccare la stessa palla.
contemporaneamente (la palla deve essere scambiata al volo,
“air time”).
· Le palle che cadono a terra o toccano altri oggetti perdono
energia.
· Non si possono passare le palle lateralmente, solo
frontalmente.

MAGIC BALLS
· Pianificazione 2 Minuti
· Stima 1 Minuto
· Esecuzione 3 Minuti
· Retrospettiva 3 Minuti
5 ITERAZIONI

Cosa vi portate a casa
Iterazioni
Rilasci frequenti
Team auto-organizzato
Ispezione ed adattamento

Paolo Sammicheli
paolo@sammiche.li - @xdatap1
Grazie

How to be Agile - ABC of team working

Recommended

More Related Content

Similar to How to be Agile - ABC of team working (20)

More from Commit University (20)

How to be Agile - ABC of team working