This presentation, that was presented at the Italian Agile Day 2012 conference by Fabio Armani. It deals with Lean Agile Contracts in terms of related principles, topics, typologies and models.
Stime e preventivi in un contesto di sviluppo agileStefano Valle
Slide del seminario su stime e preventivi in un contesto di sviluppo agile, tenuto presso il Distretto delle Tecnologie Digitali, a Udine, il 14/07/2012
This lighting talk aims to explore, from an holistic point of view as opposed to the reductionist thinking, how the Lean Agile methodologies can be considered as part of the “turning point” in the crisis of Western reductionist way of thinking. Recent scientific discoveries indicate that all life – from the most primitive cells, up to human societies, corporations and nation-states, even the global economy – is organized along the same basic patterns and principles: those of the network. Both (Lean & Agile) offer a thinking tool set that allow us to create new models and different approaches. Hence, in this lighting talk I would like to affirm how tightly humans are connected with the fabric of life and make it clear that it is imperative to organize our world according to a different set of values and beliefs.
Lean Agile Adoption Enterprise Challenges - XP 2012Fabio Armani
The migration process from Mainstream and Waterfall approaches to Agile Methodologies, at a broad and full company level, is a complex challenge that requires courage, dedication and ability to face difficulties and errors.
This short paper is the real story (hence the sub title: “Enterprise Challenges”) of my long experience as a CTO and Senior Manager, which has been committed and involved into spreading agile methodologies in Italy at Enterprise level (in particular by adopting Agile Modeling, eXtreme Programming, Scrum, Kanban and Lean Development methodologies), thus involving all levels of the company, starting from the organization structure and vision to the strategic operational details (eg: open source tools for project management and full life-cycle).
Stime e preventivi in un contesto di sviluppo agileStefano Valle
Slide del seminario su stime e preventivi in un contesto di sviluppo agile, tenuto presso il Distretto delle Tecnologie Digitali, a Udine, il 14/07/2012
This lighting talk aims to explore, from an holistic point of view as opposed to the reductionist thinking, how the Lean Agile methodologies can be considered as part of the “turning point” in the crisis of Western reductionist way of thinking. Recent scientific discoveries indicate that all life – from the most primitive cells, up to human societies, corporations and nation-states, even the global economy – is organized along the same basic patterns and principles: those of the network. Both (Lean & Agile) offer a thinking tool set that allow us to create new models and different approaches. Hence, in this lighting talk I would like to affirm how tightly humans are connected with the fabric of life and make it clear that it is imperative to organize our world according to a different set of values and beliefs.
Lean Agile Adoption Enterprise Challenges - XP 2012Fabio Armani
The migration process from Mainstream and Waterfall approaches to Agile Methodologies, at a broad and full company level, is a complex challenge that requires courage, dedication and ability to face difficulties and errors.
This short paper is the real story (hence the sub title: “Enterprise Challenges”) of my long experience as a CTO and Senior Manager, which has been committed and involved into spreading agile methodologies in Italy at Enterprise level (in particular by adopting Agile Modeling, eXtreme Programming, Scrum, Kanban and Lean Development methodologies), thus involving all levels of the company, starting from the organization structure and vision to the strategic operational details (eg: open source tools for project management and full life-cycle).
Shape Shift is a JIRA plugin devoted to manage large distributed Agile Teams.
These slides were presented by Fabio Armani during the XP 2009 Conference
A collaborative talk on lean agile transitions, challenges and experiences guided by a Lean Change approach. Tao as well as music and arts are possible keys of learning.
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Perché parliamo di Scaling Lean Agile?
Ci sono due aspetti primari inerenti lo scalare delle tecniche agili a livello di Enterprise che è necessario considerare. In primo luogo lo scalare delle tecniche agili a livello di progetto per affrontare le sfide peculiari che i team di progetto devono affrontare. In secondo luogo è lo scalare la vostra strategia agile attraverso l'intero reparto IT, in modo appropriato. E' abbastanza semplice applicare Lean Agile su una manciata di progetti, ma può essere molto difficile far evolvere la cultura e l’intera struttura organizzativa per adottare appieno il modo agile di lavorare.
Lean e Agile (in particolar modo metodologie come Scrum e XP) hanno pienamente dimostrato il loro valore a livello di team. Cosa succede però nel momento in cui tentiamo di utilizzarle in contesti reali più complessi? Nelle reali organizzazioni che caratterizzano un’importante parte del panorama dell'IT in Italia? Muovendosi dal livello dei team verso il livello dell'organizzazione si incontrano una serie di problematiche più complesse e per un certo verso nuove. Ecco quindi l'importanza di conoscere valori e principi che sono alla base del tema del Lean Agile Scaling. Esistono parecchi modelli che negli ultimi anni si confrontano con le realtà delle organizzazioni.
In questo talk tratteremo a livello olistico questo tema e confronteremo alcuni di tali modelli di Scaling Lean Agile, quali: Scrum standard (Ken Schwaber, Mike Cohn, ...) – il modello di Larmann & Vodde - SAFe – Disciplined Agile Delivery di Scott Ambler – Path to Agility (Ken Schwaber). Inoltre verranno affrontate e discusse le esperienze personali effettuate in diverse società in fase di adozione o utilizzo su larga scala di Lean Agile.
The design patterns are recurring solutions to common problems in software design.
The design patterns in computer science were formally described for the first time in the book "Design Patterns: Elements of Reusable Object-Oriented Software", whose authors are often called the Gang of Four, GoF or Go4.
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011Fabio Armani
Scrumban - A methodology Fusion
di Fabio Armani
In this talk I will describe the use, in a real context, of Kanban and Scrum agile methodologies combined with some practices of Extreme Programming. In the scenery of the agile methodologies, Scrum has certainly gained a position of clear dominance in terms of adoption and obtained successes.
This remarkable result is undoubtedly due to its peculiarities to know how to answer to the agile's values and principles in a revolutionary way, and of fostering a very pragmatic approach. Moreover, its characteristic of not being prescriptive with regard to technological aspects, allows a Scrum team to integrate eXtreme Programming practices to agile skills with a great success through their gradual introduction.
As also shown and described in my article "Lean Agile Adoption - an enterprise-war story" Scrum can scale to enterprise-level and can be used to guide the transformation process itself of a company into an agile one. Our real-world experience, based on principles of continuous experimentation and adaptation, soon led us to devise and use a form of merging Scrum with Lean methodologies, and in particular with Kanban.
The purpose of this short paper is therefore to share the direct practical experience of teams led by me, in order to help others in their process of adopting agile methodologies.
Scrum buts » but Scrum - which is worse?Fabio Armani
The term "scrumbut" could mean:
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only some tenents of the Scrum methodology.
4. In general, one who uses the word “but” when answering the question “Do you do Scrum?”
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve the problems and realize the benefits.
But Scrum ...
- Yes, these are bad situations. But let's look at the flipside - let's look at 'But Scrum.'
- 'But Scrum' is when a person/team/organization flips off their 'thinking bit' and just burps up whatever Scrum tells them to do.
Agile soft skills suitecase - iad 2011Fabio Armani
An Agile soft-skill suite case: set of values, principles and practices for agile and lean coaching.
During this presentation will be described and discussed a large set of agile coaching skills.
This set of design patterns are related to Enterprise Patterns. In it you can find, J2EE, Presentation, Business & Integration Patterns (such as: ApplicaCon Controller, Data Transfer Object (DTO), Business Object (BO) & Data Access Object (DAO) among others ...)
Lean UX presented by Fabio Armani at the Bettersoftware 2012 Conference in september 2012.
Cosa è Lean UX?
User Centered Design x Lean Startup (Customer Development + approcci Lean & Agile).
Per la prima volta, i metodi User Centered Design hanno il dovuto slancio nel mondo degli affari.
Quando la comunità imprenditoriale comincia a misurare il valore dell'esperienza dell'utente, è il momento in cui essa investe su questo importante aspetto come un driver di valore, piuttosto che come un costo da minimizzare.
Quando la scienza del Lean Startup include lo "user centered design" come uno dei suoi attrattori principali, noi progettisti abbiamo una nuova opportunità di fare grandi cose.
In questo talk vorrei parlare dell'importanza del movimento Lean UX e di come questo possa condurre alla realizzazione di un team integrato che superi il semplice concetto di Product Owner, andando a definire un più vasto concetto di Product Ownership.
Oltre alla trattazione teorica dei concetti fondamentali, verranno forniti esempi tratti dalle mie molteplici esperienze di Coaching e Consulting in diversi contesti con aziende di medie e grandi dimensioni.
Agile requirements - alla ricerca del filo rosso (iad 2013)Fabio Armani
requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo di capire perché.
Possiamo affermare che Lean Agile sta di fatto divenendo uno delle metodologie più adottate (se non il main-stream stesso) in ambito informatico e conseguentemente anche in ambiti connessi con l’informatica.
Nel mio talk (che spero possa trasformarsi in una tavola rotonda sul tema degli agile requirements e di ciò che ruota attorno ad essi) desidero presentare le varie possibilità di gestire i requisiti in modo agile e di seguire ad esempio il percorso delle “user story” (uno dei più efficaci metodi inventati in ambito agile o meglio nella metodologia eXtreme Programming per gestire i requisiti) in tutte le diverse fasi della loro ‘vita’ : a partire da ‘theme’, ‘epic’ e poi ‘story’ realizzata durante una determinata iterazione, fino al loro testing mediante Acceptance Test Driven Development e convalida business sul campo con gli utenti finali e i diversi stakeholder.
Bene… per poter effettuare questo affascinante itinerario cosa e chi viene coinvolto? Scopriremo assieme (ed argomenteremo le diverse soluzioni) che un’intera organizzazione Enterprise si dovrà plasmare per consentire ad una storia di divenire parte di una nuova funzionalità di successo.
Per avere realmente successo dovremmo scomodare molte metodologie tra le quali Lean , Agile, Lean StartUp, Lean UX e questo ci porterà nuovamente al punto di partenza. Perché vogliamo realizzare proprio questa storia? Quale era il requisito da cui siamo partiti. A quale Vision ci siamo ispirati?
Sono certo che il tema è affascinante e sarà interessante affrontarlo collettivamente, specialmente se trattato in ambito di round table.
In this talk we will discuss various topics related to how Lean Agile methodologies can scale to the Enterprise level, we will compare various scaling models, including, standard Scrum or hybrid Scrum methodologies (such as Scrum plus eXtreme Programming or Scrum + Kanban) have fully demonstrated their value to the team level.
But … What happens when we try to use these models in real more complex environments and contexts? Or, when we try to scale Lean Agile in real organizations that characterize an important amount of the landscape of IT in Italy? Moving from the level of the team to the level of the organization (program and portfolio) we will encounter a number of complex issues to some extent new. Hence the importance of knowing the values and principles that constitute the foundations of the concepts of Lean Agile Scaling. There are several models, born in recent years, who are confronted with the reality of the Enterprise. We will discuss this issue at an holistic level and we will compare some of these scaling models, such as: - the standard Scrum ( Ken Schwaber , Mike Cohn , ... ) - Larmann & Vodde - SAFe - DAD - Management 3.0 - CDE – plus other models and approaches taken from my consulting and managerial coaching Enterprise experiences.
User Stories Writing - Codemotion 2013Fabio Armani
Stefano Leli (Freelance) - Fabio Armani (OpenWare)
Scrivere user stories dovrebbe essere facile...almeno in teoria. In realtà nella pratica ci troviamo troppo spesso a combattere con storie vaghe o troppo tecniche, storie che non possono essere testate o addirittura che non portano alcun valore. In questo workshop cercheremo assieme di comprendere la differenza tra requisiti funzionali e User Story, tra User Story e Use Case, mediante dei case study.
Liftoff - how to launch Agile teams and projectsFabio Armani
Liftoff - come lanciare team e progetti Agili
di Fabio Armani
Come per mettere in orbita un razzo è importante effettuare molteplici operazioni preliminare che sono fondamentali per il successo della missione, così per lanciare un progetto o creare un team Agile è fondamentale una fase di 'Liftoff'.
Questo talk, che parte dall'interessantissimo lavoro di Diana Larsen e Ainsley Nies intende combinare le pratiche della fase di Agile Inception portate avanti dall'autore sin dal 2001 con i più moderni principi derivanti da Lean StartUp.
User Experience in alien contexts, issues, challenges, opportunities with user scenarios, interviews, bias... Some SciFi masterpieces descriptions, philosophy and metaphors and dialogues by Fabio armani and Virginia Capoluongo ad FuffaDay 2022 (www.fuffaday.org)
Shape Shift is a JIRA plugin devoted to manage large distributed Agile Teams.
These slides were presented by Fabio Armani during the XP 2009 Conference
A collaborative talk on lean agile transitions, challenges and experiences guided by a Lean Change approach. Tao as well as music and arts are possible keys of learning.
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Perché parliamo di Scaling Lean Agile?
Ci sono due aspetti primari inerenti lo scalare delle tecniche agili a livello di Enterprise che è necessario considerare. In primo luogo lo scalare delle tecniche agili a livello di progetto per affrontare le sfide peculiari che i team di progetto devono affrontare. In secondo luogo è lo scalare la vostra strategia agile attraverso l'intero reparto IT, in modo appropriato. E' abbastanza semplice applicare Lean Agile su una manciata di progetti, ma può essere molto difficile far evolvere la cultura e l’intera struttura organizzativa per adottare appieno il modo agile di lavorare.
Lean e Agile (in particolar modo metodologie come Scrum e XP) hanno pienamente dimostrato il loro valore a livello di team. Cosa succede però nel momento in cui tentiamo di utilizzarle in contesti reali più complessi? Nelle reali organizzazioni che caratterizzano un’importante parte del panorama dell'IT in Italia? Muovendosi dal livello dei team verso il livello dell'organizzazione si incontrano una serie di problematiche più complesse e per un certo verso nuove. Ecco quindi l'importanza di conoscere valori e principi che sono alla base del tema del Lean Agile Scaling. Esistono parecchi modelli che negli ultimi anni si confrontano con le realtà delle organizzazioni.
In questo talk tratteremo a livello olistico questo tema e confronteremo alcuni di tali modelli di Scaling Lean Agile, quali: Scrum standard (Ken Schwaber, Mike Cohn, ...) – il modello di Larmann & Vodde - SAFe – Disciplined Agile Delivery di Scott Ambler – Path to Agility (Ken Schwaber). Inoltre verranno affrontate e discusse le esperienze personali effettuate in diverse società in fase di adozione o utilizzo su larga scala di Lean Agile.
The design patterns are recurring solutions to common problems in software design.
The design patterns in computer science were formally described for the first time in the book "Design Patterns: Elements of Reusable Object-Oriented Software", whose authors are often called the Gang of Four, GoF or Go4.
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011Fabio Armani
Scrumban - A methodology Fusion
di Fabio Armani
In this talk I will describe the use, in a real context, of Kanban and Scrum agile methodologies combined with some practices of Extreme Programming. In the scenery of the agile methodologies, Scrum has certainly gained a position of clear dominance in terms of adoption and obtained successes.
This remarkable result is undoubtedly due to its peculiarities to know how to answer to the agile's values and principles in a revolutionary way, and of fostering a very pragmatic approach. Moreover, its characteristic of not being prescriptive with regard to technological aspects, allows a Scrum team to integrate eXtreme Programming practices to agile skills with a great success through their gradual introduction.
As also shown and described in my article "Lean Agile Adoption - an enterprise-war story" Scrum can scale to enterprise-level and can be used to guide the transformation process itself of a company into an agile one. Our real-world experience, based on principles of continuous experimentation and adaptation, soon led us to devise and use a form of merging Scrum with Lean methodologies, and in particular with Kanban.
The purpose of this short paper is therefore to share the direct practical experience of teams led by me, in order to help others in their process of adopting agile methodologies.
Scrum buts » but Scrum - which is worse?Fabio Armani
The term "scrumbut" could mean:
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only some tenents of the Scrum methodology.
4. In general, one who uses the word “but” when answering the question “Do you do Scrum?”
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve the problems and realize the benefits.
But Scrum ...
- Yes, these are bad situations. But let's look at the flipside - let's look at 'But Scrum.'
- 'But Scrum' is when a person/team/organization flips off their 'thinking bit' and just burps up whatever Scrum tells them to do.
Agile soft skills suitecase - iad 2011Fabio Armani
An Agile soft-skill suite case: set of values, principles and practices for agile and lean coaching.
During this presentation will be described and discussed a large set of agile coaching skills.
This set of design patterns are related to Enterprise Patterns. In it you can find, J2EE, Presentation, Business & Integration Patterns (such as: ApplicaCon Controller, Data Transfer Object (DTO), Business Object (BO) & Data Access Object (DAO) among others ...)
Lean UX presented by Fabio Armani at the Bettersoftware 2012 Conference in september 2012.
Cosa è Lean UX?
User Centered Design x Lean Startup (Customer Development + approcci Lean & Agile).
Per la prima volta, i metodi User Centered Design hanno il dovuto slancio nel mondo degli affari.
Quando la comunità imprenditoriale comincia a misurare il valore dell'esperienza dell'utente, è il momento in cui essa investe su questo importante aspetto come un driver di valore, piuttosto che come un costo da minimizzare.
Quando la scienza del Lean Startup include lo "user centered design" come uno dei suoi attrattori principali, noi progettisti abbiamo una nuova opportunità di fare grandi cose.
In questo talk vorrei parlare dell'importanza del movimento Lean UX e di come questo possa condurre alla realizzazione di un team integrato che superi il semplice concetto di Product Owner, andando a definire un più vasto concetto di Product Ownership.
Oltre alla trattazione teorica dei concetti fondamentali, verranno forniti esempi tratti dalle mie molteplici esperienze di Coaching e Consulting in diversi contesti con aziende di medie e grandi dimensioni.
Agile requirements - alla ricerca del filo rosso (iad 2013)Fabio Armani
requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo di capire perché.
Possiamo affermare che Lean Agile sta di fatto divenendo uno delle metodologie più adottate (se non il main-stream stesso) in ambito informatico e conseguentemente anche in ambiti connessi con l’informatica.
Nel mio talk (che spero possa trasformarsi in una tavola rotonda sul tema degli agile requirements e di ciò che ruota attorno ad essi) desidero presentare le varie possibilità di gestire i requisiti in modo agile e di seguire ad esempio il percorso delle “user story” (uno dei più efficaci metodi inventati in ambito agile o meglio nella metodologia eXtreme Programming per gestire i requisiti) in tutte le diverse fasi della loro ‘vita’ : a partire da ‘theme’, ‘epic’ e poi ‘story’ realizzata durante una determinata iterazione, fino al loro testing mediante Acceptance Test Driven Development e convalida business sul campo con gli utenti finali e i diversi stakeholder.
Bene… per poter effettuare questo affascinante itinerario cosa e chi viene coinvolto? Scopriremo assieme (ed argomenteremo le diverse soluzioni) che un’intera organizzazione Enterprise si dovrà plasmare per consentire ad una storia di divenire parte di una nuova funzionalità di successo.
Per avere realmente successo dovremmo scomodare molte metodologie tra le quali Lean , Agile, Lean StartUp, Lean UX e questo ci porterà nuovamente al punto di partenza. Perché vogliamo realizzare proprio questa storia? Quale era il requisito da cui siamo partiti. A quale Vision ci siamo ispirati?
Sono certo che il tema è affascinante e sarà interessante affrontarlo collettivamente, specialmente se trattato in ambito di round table.
In this talk we will discuss various topics related to how Lean Agile methodologies can scale to the Enterprise level, we will compare various scaling models, including, standard Scrum or hybrid Scrum methodologies (such as Scrum plus eXtreme Programming or Scrum + Kanban) have fully demonstrated their value to the team level.
But … What happens when we try to use these models in real more complex environments and contexts? Or, when we try to scale Lean Agile in real organizations that characterize an important amount of the landscape of IT in Italy? Moving from the level of the team to the level of the organization (program and portfolio) we will encounter a number of complex issues to some extent new. Hence the importance of knowing the values and principles that constitute the foundations of the concepts of Lean Agile Scaling. There are several models, born in recent years, who are confronted with the reality of the Enterprise. We will discuss this issue at an holistic level and we will compare some of these scaling models, such as: - the standard Scrum ( Ken Schwaber , Mike Cohn , ... ) - Larmann & Vodde - SAFe - DAD - Management 3.0 - CDE – plus other models and approaches taken from my consulting and managerial coaching Enterprise experiences.
User Stories Writing - Codemotion 2013Fabio Armani
Stefano Leli (Freelance) - Fabio Armani (OpenWare)
Scrivere user stories dovrebbe essere facile...almeno in teoria. In realtà nella pratica ci troviamo troppo spesso a combattere con storie vaghe o troppo tecniche, storie che non possono essere testate o addirittura che non portano alcun valore. In questo workshop cercheremo assieme di comprendere la differenza tra requisiti funzionali e User Story, tra User Story e Use Case, mediante dei case study.
Liftoff - how to launch Agile teams and projectsFabio Armani
Liftoff - come lanciare team e progetti Agili
di Fabio Armani
Come per mettere in orbita un razzo è importante effettuare molteplici operazioni preliminare che sono fondamentali per il successo della missione, così per lanciare un progetto o creare un team Agile è fondamentale una fase di 'Liftoff'.
Questo talk, che parte dall'interessantissimo lavoro di Diana Larsen e Ainsley Nies intende combinare le pratiche della fase di Agile Inception portate avanti dall'autore sin dal 2001 con i più moderni principi derivanti da Lean StartUp.
User Experience in alien contexts, issues, challenges, opportunities with user scenarios, interviews, bias... Some SciFi masterpieces descriptions, philosophy and metaphors and dialogues by Fabio armani and Virginia Capoluongo ad FuffaDay 2022 (www.fuffaday.org)
Slides of the 'deep' talk presented @ Agile O'Day 2017 #agileoday on the topic of "Business Agility" - Business agility is the "ability of a business system to rapidly respond to change by adapting its initial stable configuration”
User Story Mapping - mini iad 2014 (Armani, Rodriguez)Fabio Armani
Riteniamo, che non vi sia dubbio sul fatto le User Story (introdotte da eXtreme Programming) e il Product Backlog (definito in Scrum) rappresentino due portentosi strumenti per la gestione agile dei requisiti e delle specifiche sia funzionali che non funzionali. Ma … hanno alcuni limiti.
Ad esempio, nonostante le notevoli caratteristiche del Product Backlog, la sua unidimensionalità non consente di creare un modello dei requisiti adatto a scalare e che consenta di gestire le dipendenze che possono essere presenti tra i vari elementi che lo costituiscono.
In questo workshop presenteremo e utilizzeremo un altro potente strumento che spesso utilizziamo durante gli User Story Workshop sia in fase d’Inception, sia all’inizio di ogni nuova release di un prodotto. Si chiama “User Story Mapping”.
Ci divertiremo con voi ad utilizzarlo in una simulazione che partendo dalla Vision di un prodotto ci consentirà di mappare i bisogni di un numero selezionato di utenti su un insieme di funzionalità organizzate in una mappa.
Inoltre vedremo come sia possibile utilizzare questo strumento per gestire le diverse release di un prodotto a partire dal così detto “Walking Skeleton” fino alle successive MMF (Mininum Markatable Feature)
Sapete cos’è il modello di Kano, FURPS+, o come il nome della capitale della Russia possa essere utilizzato per assegnare priorità alle diverse storie? Se vi abbiamo incuriosito, o se pensate che avere un nuovo strumento mentale da aggiungere alla vostra cassetta degli attrezzi potrebbe esservi utile, partecipate. Sarete certamente i benvenuti.
10. “Nella lunga storia del genere umano
(e delle specie animali, anche) coloro
che hanno imparato a collaborare e
improvvisare più efficacemente hanno
prevalso.“
Charles
Darwin
20. Saggezza convenzionale
• Le aziende inevitabilmente sono attente ai
propri interessi
• I contratti sono necessari per limitare
comportamenti opportunistici
22. Approccio agile
• Si suppone che l’altra parte agirà in buona
fede
• Lasciare che sia la relazione a limitare
l'opportunismo
• Utilizzare il contratto per introdurre incentivi
30. Contratti agili
• I metodi agili forniscono una grande
flessibilità e consentono requisiti e priorità
variabili
• Questa adattabilità e flessibilità dello scope
possono creare problemi quando si
definiscono i criteri di accettazione per
contratti e lavori in outsourcing
31. Contratti agili
• Questi problemi esistono sin dalla nascita
delle metodologie agili
• Su questo importante tema sono stati spesi
sforzi notevoli
• Nel 1994, la prima edizione del Manuale di
DSDM presentava il modello del triangolo
invertito
39. Ciclo di rilascio
• Al termine di ogni iterazione time-boxed,
viene consegnato incrementalmente un
sistema deployabile con funzionalità
utilizzabili
40. Ciclo di rilascio
• Aspetti nuovi per i legali
– Doneness and deployability : il rilascio ad ogni
iterazione è done, sviluppato, testato … ovvero
in teoria consegnabile
– Durata : minore, generalmente due settimane
– Time-boxing : tempo fisso ed ambito variabile
44. Ambito del progetto
• Nei contratti agili lo scope non viene definito
in maniera esatta e non modificabile
• Nei diversi contratti esistono possibili
variazioni nel grado di specifica dell’ambito e
della sua variabilità
• Queste variazioni sono in genere collegate ai
differenti schemi di pagamento
45. Ambito del progetto
• Contratti Target-cost
– Scope e dettagli vengono identificati quanto
meglio possibile all’inizio del progetto, allo
scopo di calcolare il target cost iniziale
– Consentono meccanismi di modifica dello scope
• Contratti Progessivi
– In cui lo scope non viene definito oltre l’orizzonte
di una singola iterazione
47. Vision di progetto
• Definire una chiara Vision di prodotto
• Utilizzare la tecnica dell’Elevator Pitch in
modo collaborativo (partecipano anche i
legali)
Moore, “Crosing the Chasm”
• Inserire il modello di contratto
48. Elevator
Pitch
It’s a technique for distilling the product value proposition
#iad12|
@fabioarmani
49. Modello di contratto
• Esempio:
– questo è un contratto di tipo “target-cost”
– La base è un prezzo di delivery dell’ordine di €
XXXX
– Il fornitore rilascerà e verrà pagato su base
incrementale al termine di ogni iterazione di due
settimane
53. Gestione del cambiamento
• Gestione delle priorità nel Backlog
• Pianificazione adattativa ed iterativa
• Non viene utilizzato un pesante (tradizionale)
processo di change management o di
change request
• E’ fondamentale che i legali comprendano
questo punto
– Non vengano inseriti termini contrattualistici che
violerebbero l’essenza dell’agilità
56. Fine progetto
• Legata al meccanismo di controllo dei
cambiamenti
• In ambito agile il cambiamento può essere
così radicale da portare all’interruzione del
contratto
“fermando ogni attività al termine di una
determinata iterazione”
57.
58. Fine progetto
• Un’interruzione precoce dovrebbe essere
vista come un evento positivo e desiderabile
– Non comporta necessariamente un fallimento
– Vuol dire che i risultati sono stati ottenuti prima
• Consente al cliente di interrompere il
contratto, senza penali, al termine di
qualsiasi iterazione
• Variazioni nelle clausole di terminazione
proteggono il fornitore
59. Fine progetto
• Queste clausole possono essere
particolarmente difficili in ogni contratto
• Fattori di mitigazione in agile:
– Al termine di ogni iterazione il cliente ha un
sistema funzionante
– Entrambe le parti hanno sempre una chiara e
trasparente vista dello stato dei deliverable
• E’ fondamentale che i legali comprendano
questi concetti
60. Value
capture
vs
delivery
CumulaFve
Value
Captured
Features
delivered
61. Value
capture
vs
delivery
CumulaFve
Value
Captured
50%
Usual
AssumpFon
Features
delivered
50%
62. Value
capture
vs
delivery
Actual
DistribuFon
90%
CumulaFve
Value
Captured
50%
Usual
AssumpFon
Features
delivered
50%
65. Approvazione
• Non ci devono esser ambiguità circa:
– Doneness
– Acceptance
– Correction
• Particolare cura nella negoziazione di questi
aspetti favorendo la collaborazione
66. Approvazione
• Approvazione semplificata grazie al delivery
iterativo allo sviluppo incrementale del
prodotto
• Automazione degli acceptance test riduce
l’effort manuale nella validazione
• L’accettazione finale è la composizione di
una serie di fasi precedenti
69. Limiti di responsabilità
• Queste clausole rappresentano
probabilmente l’aspetto di negoziazione più
difficile
• Vanno in ogni caso inserite nel contratto
• In agile il processo iterativo ed incrementale
limita i pericoli di una scoperta di gravi
anomalie del sistema “big bang”
• Le conseguenze negative vengono scoperte
prima
72. Garanzia
• Similmente alle responsabilità, anche questi
aspetti vengono mitigati da un approccio
agile
• Ogni accettazione graduale ne ha mitigato il
rischio
• Utilizzando Accetance test automatici si ha
un ulteriore diminuzione del rischio
73. Garanzia
• Esplicitare l’aspetto incrementale nel
contratto
• Le garanzia devono essere legate ai rilasci
incrementali ed iterativi
• Può ovviamente esistere una garanzia
generale sul prodotto finale
76. Documentazione
• Evitare quanto più possibile uno “statement
of work” o “quality plan”
– ovvero una lista dettagliata e fissa di
“deliverable” e di come avvenga l’accettazione
di tali artefatti
77. Documentazione
• Perché?
– Genera attività inutili e sprechi piuttosto che la
focalizzazione sulla produzione di “working
software”
– Vi è una falsa presunzione di sapere quali siano
gli artifact realmente utili
– Troppe energie spese in negoziazione e
conformità al “quality plan” piuttosto che
cooperazione nella creazione di software utile
– Falsa linearizzazione di un processo non lineare
80. Tempistiche di pagamento
• Il pagamento avviene al termine di ogni
iterazione
• Dipende in parte dal modello di contratto
• Nei casi più semplici viene pagato il 100%
del prezzo d’iterazione pattuito
• In casi più complessi possono essere utilizzati
altri meccanismi …
85. 10
Pagamento e fatturazione,
compresi eventuali clausole di
bonus e penali
86.
87. Pagamento
• Time & materials
• Fixed price per iteration (per unit of time)
• Fixed price per unit of work (UoW)
• Hybrid shared pain/gain
• Fixed price per project and target-cost
pricing
88. Time & Materials
• Estremamente valido per progetti agili:
semplice e diretto
• Raccomandato
• Può applicarsi sia a:
– Fixed scope
– Variable scope
89. Time & Materials
• Variazioni limitano l’esposizione ai pericoli
per il cliente e bilanciano pene/guadagni
• Esempi di variazioni:
– Capped (“non eccedere la soglia”) T&M per iterazione
– Capped T&M per progetto e/o rilascio
– Capped T&M per iterazione con aggiustamenti e possibili
incentivi per il fornitore
90. Fixed Price per iteration
• Virtù data da semplicità e predicibilità
• Viene utilizzato in agile outsourcing
• Vi sono due tipologie:
1. Requisiti definiti e concordati all’inizio
dell’iterazione
2. Altamente flessibile o senza requisiti predefiniti
91. Fixed Price per UoW
• In agile una UoW è rappresentata dal settimo
principio:
“il software funzionante è la reale misura del
progresso”
• Quindi una UoW è legata a “running, tested
software feature”
92. Fixed Price per UoW
• Possono essere utilizzati vari sistemi di stima
delle UoW:
– Price per story point
– Price per function point
– Price per feature point
• Questo modello è congruente con i temi
agile e lean del
– Delivery-oriented
– Value-oriented
93. Shared pain/gain
• Esistono numerosi schemi di pagamento
ibrido
• Uno degli schemi è quello proposto da
Robert Martin
– Discounted fixed price per unit of work, plus
discounted T&M
94. Shared pain/gain : esempio
project estimate average velocity original person-day payment if €500 per
(140 people, 2 weeks iteration) estimate person per day
100.000 points 4000 points 35.000 €17.500.000
95. Shared pain/gain : esempio
• Viene offerto un costo giornaliero ridotto,
più un complementare costo per UoW
• Esempio:
– Supponendo un costo di €500 al giorno
– Il fornitore richiede un prezzo scontato a persona di €150
+ un price per point di €125,50
96. Shared pain/gain : esempio
actual person-days actual customer Change in Change in effective person-
payment estimate-to-actual estimate-to-actual day rate
effort payment
35.000 €17.500.000 0 0 €500
97. Shared pain/gain : esempio
actual person-days actual customer Change in Change in effective person-
payment estimate-to-actual estimate-to-actual day rate
effort payment
30.000 €16.750.000 -14% -4% €558
35.000 €17.500.000 0 0 €500
98. Shared pain/gain : esempio
actual person-days actual customer Change in Change in effective person-
payment estimate-to-actual estimate-to-actual day rate
effort payment
30.000 €16.750.000 -14% -4% €558
35.000 €17.500.000 0 0 €500
40.000 €18.250.000 14% +4% €456
99. Shared pain/gain
• Se l’effort reale è uguale a quello stimato, il
cliente pagherà con un semplice schema di
tipo T&M
• Nel caso il cui tale effort vari, il pagamento
da parte del cliente varierà meno
• Come nel meccanismo del target-cost sia
fornitore sia cliente condividono i rischi
100.
101.
102.
103. Sydney Opera House
• Iniziato come progetto a prezzo fisso e data
fissa
• Sfortunatamente non era assolutamente un
progetto standard
• Come risultato …
104. Sydney Opera House
• Ci sono voluti 13 anni e 102 milioni di dollari
australiani per costruirla al posto dei 3 anni e
7 milioni di dollari stimati
– 330 % del tempo
– 1350 % dei costi
105. Sviluppo
soMware
• Lo sviluppo del software consiste quasi
sempre (in larga misura) nella creazione di
qualcosa di nuovo, che nessuno ha realizzato
in precedenza
• Pertanto i contratti a prezzo-fisso e data-fissa
per lo sviluppo del software sono noti per
essere imprecisi ed erronei
106.
107. Soluzioni
agili
• Una soluzione agile per situazioni basate sul
prezzo fisso sarebbe quella di svincolare
l'angolo di pianificazione del triangolo
tempo-costo-qualità
108. Soluzioni
agili
• Ciò in genere implica che si istituisca sia una
forma di contratto ‘time & materials’ sia un
finanziamento a fasi (gated)
• Nel caso di contratti a tempo e materiali il
cliente paga ogni mese per il mese di
sviluppo, oppure iterazione dopo iterazione
109. Soluzioni
agili
• Di solito il cliente ha il diritto di sospendere
la collaborazione dopo ogni iterazione,
possibilmente con un dato premio
114. T&M : variazioni di scope
• Lo scope non è fissato a priori
• Prima o poi, il cliente non vorrà continuare a
pagare, dunque il progetto volgerà al
termine
115. T&M : rischi
• 100% a carico del cliente
• Il fornitore ha pochi incentivi a contenere i
costi
• Lo sforzo necessario per garantire che solo il
lavoro e le spese legittimi vengano fatturati
può essere notevole
• Questo sforzo di tracciamento rappresenta
uno spreco!
122. Fixed Price / Fixed Scope
$$$
revenue
Revenue
is
constants
regardless
effort
applied
or
delivery
date
Effort
123. FP/FS : struttura
• Concordare gli elementi da fornire
• Consegnarli
• Inviare fattura
• I clienti amano i progetti a prezzo fisso,
perché dà loro sicurezza (almeno così
credono)(o almeno la pensano così).
124. FP/FS : struttura
• Concordare gli elementi da fornire
• Consegnarli
• Inviare fattura
• I clienti amano i progetti a prezzo fisso,
perché dà loro sicurezza (almeno così
credono)(o almeno la pensano così).
125. FP/FS : variazioni di scope
• Nulla: è evidente già nel nome del tipo di
contratto : fixed scope
• Il processo di change request ha lo scopo di
limitare le modifiche dell’ambito (scope)
• Questo processo è costoso, e le modifiche di
solito non sono prevenibili
126. FP/FS : variazioni di scope
• Dal momento che il cliente per definizione
richiede aumenti dello scope, terminare un
progetto può essere piuttosto difficile
• D’altra parte il fornitore vuole che il cliente
sia soddisfatto, quindi in genere cede
• I requisiti di un contratto di questo tipo
devono essere definiti in modo molto
stringente e rigoroso
127. FP/FS : rischi
• Il rischio è molto sbilanciato a sfavore del
fornitore
• Se le stime sono sbagliate, il progetto
perderà soldi
• Porta ad un lose-lose situation
• Introduzione di alto debito tecnico
• Il cliente paga più del dovuto e spesso non
ottiene ciò di cui ha realmente bisogno
128. FP/FS : rischi
• Se vengono anche introdotte clausole di
“fixed time” il rischio di progetto aumenta
• Il cliente viene penalizzato anche a lungo
termine a causa dell’introduzione di debito
tecnico
– Aumento dei costi di manutenzione
– Aumento dei costi per le evoluzioni
129.
130. FP/FS : contromisure
• Definire i requisiti mediante user story e
MMF
• Gestire le priorità degli elementi del backlog
– Scambiare requisiti esistenti con altri di uguale effort
– Cambiare l’ordine di esecuzione dei requisiti fissi
– Migliorare la “definition of done” ad ogni iterazione
• Aumentare i margini del prezzo di contratto
per riflettere i rischi inerenti allo sviluppo
FPFS
131. FP/FS : contromisure
• Proposte di Ken Schwaber:
– Il cliente può richiedere altre release in ogni
momento, pagate a T&M
– Il cliente può terminare prima se soddisfatto,
pagando al fornitore il 20% del valore rimanente
non fatturato
132. FP/FS : waterfall o agile?
“La cosa peggiore che possiate fare con un
progetto FPFS è rendere le cose ancora
peggiori adottando un approccio tradizionale
di tipo sequenziale”
Craig Larman & Bas Vodde
133. FP/FS : perché no
• Scope definito troppo presto (per
proteggere il fornitore)
• Scope troppo esteso (per proteggere il
cliente)
140. Progressive : struttura
• Implicano uno scope totalmente flessibile
che viene definito in modo adattativo ad
ogni iterazione successiva
• Ottimi candidati per lo sviluppo agile
• Rappresentano un framework per gli accordi
contrattuali che definiscono le relazioni tra le
parti e gli schemi di pagamento ma non lo
scope
141. Progressive : struttura
• Rappresentano un modello comune per
relazioni a lungo termini tra clienti e fornitori
agile
• Un pattern frequente:
1. Utilizzo di primi contratti che sono variazioni di
FPFS
2. Successivamente si ha uno spostamento verso
contratti progressivi con T&M e/o capped T&M
per iterazione
142. Progressive : variazioni
• Capped-price, variable scope
• Capped-price, partial-fixed scope : viene
definito solo un piccolo set di requisiti,
lasciando spazio ad apprendimento ed
adattabilità
• Fixed-price, variable scope : è possibile
fissare le date finale (optional scope contract)
143. Progressive : rischio
• Mitigare i rischi con modelli flessibili di
contratto
• Modello multi-fase : un grande progetto
viene suddiviso in una serie di progetti più
piccoli
– Le forme contrattuali possono variare da una fase
all’altra
144.
145. Phased Development
$$$
Project
delivers
funcFonality
≈quarterly
Budget
&
PrioriFes
adjusted
quarterly
as
well
profit
Effort
146. Phased Dev : struttura
• Vengono finanziati dei rilasci trimestrali e
approvati fondi supplementari dopo ogni
release di successo
147. Phased Dev : variazioni di scope
• Non esplicitamente definito dal modello
• Le release sono effettivamente ‘time boxed’
• La consapevolezza che ci potrà essere
un’altra versione il trimestre prossimo rende
più facile accettare il rinvio di una funzione
per ottenere il time-box
148. Phased Dev : rischi
• Per il cliente il rischio è limitato al massimo
ad un trimestre dei costi di sviluppo
152. Phased Dev : relazione
• Cooperativa
• Sia il cliente sia il fornitore hanno un
incentivo affinché ogni release abbia
successo, in modo che verranno approvati
ulteriori finanziamenti
155. Fixed Profit
$$$
AMer
target
compleFon
date,
Supplier
works
at
cost
profit
Effort
156. Target Cost : struttura
• Basati su obiettivi di business ad alto livello
• Il costo target include tutti i cambiamenti
• Il target è una responsabilità congiunta delle
due parti
• Obbiettivi e costo target vengono
chiaramente comunicati a tutti le persone
coinvolte che collaborano allo scopo di
raggiungere il goal finale
157. Target Cost : struttura
• I contratti target cost allineano le motivazioni
di entrambe le parti
• Vengono utilizzati da Toyota con i loro
fornitori, riflettendo il pilastro del rispetto per
le persone del Lean Thinking per stabilire
relazioni di lunga durata con i fornitori,
basate su fiducia e mutua collaborazione/
supporto
158. Fixed Profit : struttura
• Qualsiasi bilancio del progetto è costituito
da costi effettivi e profitto
• Le parti concordano su un determinato
profitto in anticipo (ad esempio 150.000 €)
• Indipendentemente da quando il progetto
viene completato, il contraente riceve i costi
sostenuti più il profitto concordato
159. Fixed Profit : variazioni di scope
• Lo scope è fisso e viene calcolato durante la
fase uno
1. Calcolo del del target cost (no-wishful thinking)
mediante scrupolosa due diligence
2. Esplicitazione dei costi da parte del fornitore in
modo che il cliente possa trasparentemente
vedere tutti i dettagli che hanno portato al
calcolo del target cost
160. Fixed Profit : attuazione
• La fase due prevede l’utilizzo di metodologie
agili (es: Scrum)
• Tracciamento accurato dei costi
• Condivisione dei costi
• La chiave di successo è legata alle formule di
condivisione di pain/gain per effettuare
aggiustamenti relativi alla differenza tra costi
reali e target
161. Fixed Profit : esempio
target cost target profit target actual adjustement actual actual
customer supplier cost customer supplier
payment payment profit
€1.000.000 €150.000 €1.150.000 €1.100.000 + €60.000 €1.210.000 €110.000
€1.000.000 €150.000 €1.150.000 €900.000 - €60.000 €1.090.000 €190.000
162. Fixed Profit : rischi
• Il rischio è condiviso
• Se il progetto finisce prima, il cliente paga
meno, ma il fornitore ha ancora il suo
profitto
• Se il progetto supera il budget, il cliente
paga di più, ma il fornitore non guadagna
il profitto aggiuntivo
163. Fixed Profit : rischi
• Dopo la data di consegna stabilita, il
fornitore non potrà più fatturare altro
profitto, si limiterà a coprire i propri costi
• Il rischio è condiviso mediante le formule
di aggiustamento
• Inoltre le parti possono (non è garantito)
promuovere modi per ridurre gli sprechi
durante il progetto
164. Fixed Profit : relazione
• Cooperativa
• Entrambi hanno un chiaro incentivo a finire
presto
• Se il lavoro termina prima, sia il cliente, sia lo
sviluppatore ne traggono beneficio
• Il cliente per risparmiare denaro e il fornitore
per ottenere un margine di profitto più
elevato
167. Money for nothing
$$$
Business
value
achieved,
so
works
stops
EsFmate
to
do
“everything”
“Missing
profit”
profit
Effort
168. MfN / CfF : variazioni di scope
• Lo scope può essere modificato
• Feature (o storie) progettate, ma non
realizzate, possono essere sostituite con altre
storie della stessa dimensione
• Invece la realizzazione di feature aggiuntive
ha un costo extra
169. MfN / CfF : rischi
• Il rischio è condiviso
• Entrambe le parti hanno interesse a
completare il progetto quanto prima
• Il cliente avrà costi inferiori, il fornitore avrà
un margine più elevato
179. Business
Value
Money for Nothing
ROI cut-off
Stop here
Time
180. Business
Value
Money for Nothing
Don’t do these
three
ROI cut-off
Stop here
Time
181. Business
Value
Money for Nothing
Supplier
gets 20% Customer
gets 80%
ROI cut-off
Users avoid code bloat
Project are always
and unnecessary
done early! Time
features
184. I contratti che promuovono o
obbligano un ciclo di sviluppo
sequenziale aumentano i rischi di
progetto!
185. Suggerimenti
• Money for Nothing & Change for Free
• Progessive
• Multi-phase variable model
• Adattamento e condivisione di pain/gain e
rischi
– Target cost
– Profit sharing
186. La forma del contratto pone importanti
basi per un progetto di successo
187. Ricordiamo cosa dice il Manifesto
Agile: la cooperazione con il cliente è
più importante del contratto
188. Quindi, qualunque cosa si faccia, è
fondamentale tenere una relazione
positiva con il cliente!