Come ti cambio l'organizzazione con un Capo Progetto e un Team SCRUM
•Download as PPTX, PDF•
2 likes•595 views
Quali possono essere gli impatti su una organizzazione complessa quando un Team Agile ha la duplice missione di generare valore, realizzando un prodotto di qualità e quella di contribuire a modificare i processi operativi e il modo in cui si fa assicurazione qualità? Le grandi organizzazioni del settore bancario e dell' ingegneria dei sistemi, dato il numero di funzioni (non lean/agile) e il numero di persone coinvolte, non possono prescindere dal seguire processi operativi definiti che garantiscano il rispetto delle normative di settore. In questo caso, può essere selezionato un team agile la cui mission sia non solo generare valore realizzando un prodotto di qualità ma anche diffondere per contagio il cambiamento nell'organizzazione contribuendo a modificare i processi operativi e il modo in cui si fa assicurazione qualità. In questo modo la cultura si diffonde nell'organizzazione creando terreno fertile alle successive iniziative agili.Quando la creazione di valore per il business dell’organizzazione implica l’esplorazione di nuove funzionalità, nuove tecnologie e la conformità a stringenti requisiti di normativa, le funzioni Assicurazione Qualità e Sviluppo vanno a braccetto nel prevenire i rischi e a diffondere l’agilità.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Come ti cambio l'organizzazione con un Capo Progetto e un Team SCRUM
Similar to Come ti cambio l'organizzazione con un Capo Progetto e un Team SCRUM (20)
Come ti cambio l'organizzazione con un Capo Progetto e un Team SCRUM
- 1. Come ti cambio l’organizzazione con un Team Scrum e un Project Manager Stefania Di Cristofalo
- 2. Digital Transformation Agile Adoption Process Improvement & Compliance Training & Coaching www.inspearit.com
- 3. Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: That is, while there is value in the items on the right, we value the items on the left more. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
- 4. Le organizzazioni complesse hanno bisogno di Processi… Linear is Known Complicated is Knowable Complex is perceived …Agili
- 5. Cosa pensano i Quality Manager dei Team Scrum?
- 6. Cosa pensano gli agilisti dei processi dell’organizzazione? «Processi Agili» Ossimoro?
- 8. IL cambiamento non è doloroso, solo la resistenza al cambiamento lo è. Buddha
- 9. L’esperimento condotto da Stephenson nel 1967 ha coinvolto 10 scimmie, una gabbia, una banana, una scala e uno spruzzatore di acqua gelata. Perché facciamo quello che facciamo?
- 10. La sindrome di impotenza appresa L’inutilità dei propri sforzi di modificare una situazione stressante conduce all’apprendimento della propria impotenza Seligman Organizzazione disfunzionale Processi faraginosi Team demotivati
- 11. Perché ci troviamo in questa situazione? Parte la ricerca delle cause …Stevenson e Seligman contribuiscono Si avviano programmi di miglioramento processi che però…
- 12. BIAS DELLA DISTORSIONE RETROSPETTIVA Si enfatizzano come evidenti gli elementi che secondo noi hanno provocato l’evento. Ci fa credere di essere più bravi a prevedere il futuro di quanto lo siamo in realtà.
- 13. Non si può risolvere un problema usando la stessa mentalità che lo ha creato.
- 14. Competente Mente Aperta Curioso Determinato Sperimenta Sa Comunicare Sa assumersi rischi Deve sviluppare un prodotto complesso e innovativo Il prodotto ha una forte rilevanza di business
- 15. AIM, ADJUST, FIRE, AIM, ADJUST, AIM, FIRE… I processi dell’organizzazione devono evolvere continuamente.
- 16. Empirical ApproachI processi dell’organizzazione devono evolvere sulla base di un processo empirico ADATTAMENTOISPEZIONE TRASPARENZA
- 17. La perfezione non si ottiene quando non c’è più nulla da aggiungere ma quando non c’è più nulla da togliere Antoine De Saint-Exupery I processi devono stabilire ciò che è essenziale
- 19. 19 Scrum è un processo senza sovrastrutture, l’essenziale affinchè un team possa governare lo sviluppo di Product Shippable Increment in modo agile Ruoli: Product Owner, Scrum Master, Dev Team che hanno la responsabilità di produrre qualcosa: Product Backlog Sprint Backlog Product Shippable Increment Attraverso una sequenza di attività: Sprint Planning Sprint Execution Sprint Review Sprint Retrospective Refinement Meeting Nel rispetto di alcune regole: Definition of Ready Definition of Done COSA, QUANDO, CHI e un po’ di «COME»
- 20. Il processo SCRUM è sufficiente a garantire la conformità a specifici requisiti di normativa relativi ai processi di Ingegneria?
- 21. Architecture & Design Software Development Testing Configuration Management Security & Safety Process Owner Process Owner Process Owner Process Owner Process Owner • I requisiti di normativa che hanno impatto sulle pratiche di ingegneria e sul loro flusso • Le pratiche concordate con i Process Owner che consentono di assicurare la qualità di prodotto in modo sostenibile SI… inoculando un po’ di «COSA e COME» senza modificare il «CHI» e «QUANDO»
- 22. Il processo SCRUM è sufficiente per rispondere alle esigenze interne dell’organizzazione e alle domande che si pone il Management?
- 23. Portfolio Management Project Management Performance Management Continuous Improvement Quality Assurance Process Owner Process Owner Process Owner Process Owner Process Owner Le pratiche che consentono di dare al management le risposte necessarie a integrare lo sviluppo agile nella value stream di appartenenza. SI… inoculando un po’ di «COSA e COME» senza modificare il «CHI» e «QUANDO»
- 24. Process Onwers e Team SCRUM concordano i Working Agreement che conciliano processi e agilità - Project Lift-off - Release Planning - Team Lift-off - Sprint Execution - DOR e DOD
- 25. Come avviene la definizione dei «Processi Agili» ?
- 26. Il Team conosce ciò che è essenziale fare per realizzare un Product Increment Gli esperti di Engineering, Safety, Security, Work Environment,…, dell’organizzazione sanno cosa è essenziale fare per realizzare uno Shippable Product Increment Lo Scrum Master, il Product Owner, Project Manager sanno cosa è essenziale fare per contribuire alla gestione della Value Stream di riferimento. E’ il Team Scrum con i Process Owner che rende i processi Agili Le pratiche sperimentate danno forma ai processi
- 27. Il ciclo di vita agile scandisce il tempo della funzione qualità Quality Assurance Quality Engineer (Process Owner) Dalla rilevazione delle non conformità Alla identificazione dei rischi durante gli incontri di lift-off, release planning, iterazioni
- 28. I Team Scrum sanno cosa è essenziale per realizzare un Product Increment Il Team Agile contribuisce a definire i processi IT dell’organizzazione I Team SCRUM creano valore realizzando prodotti/sistemi e cambiando i processi IT dell’organizzazione
- 29. Transformation Team Process Owners Team Community of Practices PSI Obiettivi Processi Agili Working Agreements Trasformazione
- 30. L’organizzazione agile C’è identità funzionale tra corpo e mente. Alexander Lowen
- 31. © inspearit - Author - Place Saturday, February 3, 201831 Grazie stefania.dicristofalo@inspearit.com www.stefaniadicristofalo.com
Editor's Notes
- Oggi correi condividere con voi alcune riflessioni che sono legate al primo punto del Manifesto Agile. Cosa significa esattamente questo valore? Cosa serve ad un Team Scrum per realizzare un Product Shippable Increment? Che ruolo giocano i processi e gli strumenti? E Qualora i processi dell’organizzazione siano considerati di ostacolo all’agilità come indurre il cambiamento? Le grandi organizzazioni del settore bancario e dell' ingegneria dei sistemi, dato il numero di funzioni (non lean/agile) e il numero di persone coinvolte, non possono prescindere dal seguire processi operativi definiti che garantiscano il rispetto delle normative di settore. In questo caso, può essere selezionato un team agile la cui mission sia non solo generare valore realizzando un prodotto di qualità ma anche diffondere per contagio il cambiamento nell'organizzazione contribuendo a modificare i processi operativi e il modo in cui si fa assicurazione qualità. In questo modo la cultura si diffonde nell'organizzazione creando terreno fertile alle successive iniziative agili.Quando la creazione di valore per il business dell’organizzazione implica l’esplorazione di nuove funzionalità, nuove tecnologie e la conformità a stringenti requisiti di normativa, le funzioni Assicurazione Qualità e Sviluppo vanno a braccetto nel prevenire i rischi e a diffondere l’agilità. Quali possono essere gli impatti su una organizzazione complessa quando un Team Agile ha la duplice missione di generare valore, realizzando un prodotto di qualità e quella di contribuire a modificare i processi operativi e il modo in cui si fa assicurazione qualità?
- Ma insomma questi processi a cosa servono. Pretendono di normare il lavoro. Viviamo in un mondo complesso, nel quale prevedere il futuro è impossibile, posso tentare di individuare dei trend negli scenari di business e nei movimenti interni dell’organizzazione. Ma come può ciò che è fortemente definito, fissato, andare d’accordo con un paradigma che fa della capacità di adattarsi al cambiamento, un pò come fanno le formiche quando incontrano le tracce lasciate dalle loro colleghe per indicare dove si trova il cibo o il pericolo, l’unico modo per essere time to market? Processi di Management L’obiettivo di questi processi è assicurare un contenuto informativo di qualità basato su un vocabolario condiviso e variabili definite, sulla base del quale prendere decisioni a livello organizzativo: per definire obiettivi strategici e operativi guidare la definizione del budget Guidare il miglioramento continuo Processi di Engineering L’obiettivo di questi processi è garantire la qualità del prodotto/sistema software mediante l’attuazione di alcune specifiche pratiche di ingegneria che consentono di: Effettuare Hazard Analysis (safety) Assicurare la security Assicurare l’Integrità delle baseline di prodotto Producendo le evidenze richieste dagli enti di certificazione e controllo Si cerca di cambiare. I team Scrum, La funzione qualità, il management, le funzioni che si occupano di processi di ingegneria, tutti sono d’accordo che bisogna cambiare i processi dell’organizzazione, ma il cambiamento è molto lento incontra molte resistenze e soprattutto è difficile vedere la strada giusta. Quando si va a mettere mano ai processi ci si trova di fronte a qualcosa che assomiglia molto a quei sistemi informativi nati 20 anni fa e che si sono stratificati nel tempo, dove è difficile mettere mano senza far crollare tutto. Quelli in cui servono i programmatori cobol per capire a cosa servono le cose. E le persone nell’organizzazione si trovano nella situazione in cui si trovarono le scimmie dell’esperimento di stevenson nel 1967. Processi dell’Organizzazione Risorse Umane Performance Management Qualità Gestione Contratti …..
- I primi che si preoccupano dei processi nelle organizzazioni sono coloro che lavorano per la funzione qualità. Avendo il compito di assicurare che i prodotti e i sistemi siano conformi ai requisiti delle normative vigenti. A rilevare per primi il fatto che rispettare i processi rallenta lo sviluppo è il team SCRUM e la funzione qualità concorda sul fatto che i processi tradizionali non sono applicabili al ciclo di vita agile. Ne consegue che la funzione qualità pensi che i team scrum siano indisciplinati, che non rispettano le regole dell’organizzazione, in quanto il paradigma agile non è contemplato nei processi dell’organizzazione. Il risultato è che negli audit di qualità spesso siano rilevate molte non conformità alle normative, ed essendo l’audit eseguito rispetto a processi che non contemplano il ciclo di vita agile, questi audit sono un po’ come il «matrimonio riparatore». Tutta forma e poca sostanza.
- IL dubbio che i processi non vadano d’accordo con l’agilità c’è. Sono convinti che i processi non siano sostenibili e che il più delle volte rallentino lo sviluppo. C’è anche una certa resistenza a seguire delle linee guida specificate da qualcun altro su come scrivere il codice. Insomma il Dev Team è il proprietario del processo di ingegneria è l’esperto perché qualcun altro dovrebbe specificare cosa fare e come farlo. Inoltre questi processi sono dei mattoni, tante pagine da leggere. Sono intricati, non si sa da quale parte iniziare. Vige il detto «chi fa da se fa per tre». Ma poi qualcuno questi processi dell’organizzazione sicuramente qualcuno li ha scritti, ma siamo sicuri che qualcuno li abbia letti, a parte la funzione qualità?
- Esperimento, prima parte. 5 scimmie sono state chiuse dentro una gabbia, una banana è stata appesa al soffitto ed è stata posizionata una scala in modo che potesse essere utilizzata per raggiungere la banana. Quando la prima scimmia ha cominciato a salire la scala per prendere il frutto, il ricecatore l’ha spruzzata con l’acqua gelata. Oltre a spruzzare la scimmia che ha tentato di raggiungere la banana ha spruzzato anche le altre 4 nella gabbia. Poi, una seconda scimmia ha provato a raggiungere la banana, anche lei è stata spruzzata con acqua gelata. A turno, casualmente, tutte e 5 le scimmie hanno subito la punizione. La procedura è stata ripetuta fino a quando nessuna delle 5 scimmie ha più tentato di afferrare il frutto. (Fino a qui l’esperimento ricorda quelli sull’impotenza appresa condotti da Seligman) Esperimento, seconda parte. Quando più nessuna scimmia agiva per conquistare la banana, è stata introdotta una nuova scimmia nella gabbia e tolta una delle 5 iniziali. La nuova scimmia ha subito tentato di raggiungere la banana ma le altre 4, conoscendo l’esito di quel tentativo, l’hanno assalita, costretta a scendere dalla scala e rinunciare al frutto. Ogni volta che la nuova scimmia ha provato a raggiungere la banana è stata bloccata dalle altre. Alla fine anche lei, come le altre 4 scimmie, ha rinunciato a mangiare la banana senza mai essere stata spruzzata con l’acqua gelata, quindi senza sapere perché non potesse farlo. A questo punto un’altra scimmia scelta tra le 4 originiarie rimaste, è stata sostituita con una nuova. Il nuovo gruppo era composto da 3 delle scimmie iniziali (sapevano perché non tentare di prendere la banana), 1 scimmia che aveva imparato a rinunciare alla banana a causa della reazione violenta delle altre e 1 scimmia nuova. La scimmia nuova, come previsto, ha tentato di raggiungere la banana. Come era avvenuto con la scimmia precedente, sono state le altre scimmie a impedirle di raggiungere il frutto senza che il ricercatore dovesse spruzzare dell’acqua. Anche la prima scimmia sostituita, quella che non era mai stata spruzzata ma era stata dissuasa dalle altre, si è attivata per impedire che l’ultima arrivata afferrasse la banana. Esperimento, terza parte. Ripetendo la procedura di sostituzione delle scimmie inziali con quelle nuove, si è arrivati al caso in cui tutte e 5 le scimmie non erano mai state spruzzate con l’acqua. L’ultima entrata nella gabbia ha tentato di prendere la banana ma le altre 4 l’hanno ostacolata e punita. Stephenson descrive l’atteggiamento inquisitore dell’ultima scimmia arrivata, come se cercasse di capire il perché del divieto di mangiare quella banana così invitante. Nel suo racconto le altre scimmie si sono guardate tra loro, quasi a cercare questa risposta. Il problema è che nessuna delle scimmie presenti la conosceva, perché nessuna era stata punita dallo sperimentatore per averci provato, era stato il gruppo a opporsi. Una nuova regola era stata tramandata alla generazione successiva, ma le sue motivazioni erano sconparse con la scomparsa del gruppo che l’aveva appresa. Bibliografia Stephenson, G. R. (1967). Cultural acquisition of a specific learned response among rhesus monkeys. In: Starek, D., Schneider, R., and Kuhn, H. J. (eds.), Progress in Primatology, Stuttgart: Fischer, pp. 279-288.
- Il Matematico Michael Berry, docente di fisica matematica presso l’università di Bristol. Prende in esame il movimento delle palle da biliardo dopo un tiro di stecca. Secondo Berry, se si conosce una serie di parametri riguardanti una palla da ferma su un tavolo da biliardo, calcolando la resistenza del tavolo, e valutando la froza dell’impatto, è abbastanza semplice prevedere che cosa succederà al primo urto con un’altra palla. Il secondo urto è già più complicato, tuttavia è possibile prevedere cosa accadrà con un certo grado di certezza. Quando dopo una serie di urti si arriva a valutare il nono impatto, risulta ddirittura necessario prendere in considerazione la forza gravitazionale e una possibile persona in piedi vicino al tavolo da biliardo. Se poi volessimo calcolare il cinquantesimo impatto, sarebbe necessario calcolare ogni particella elementare esistente finanche l’elettrone posizionato ai limiti dell’universo perché comunque esercita una influenza sul sistema palla-stecca-biliardo-uomo. L’errore che si commette a fare una previsione ha un effetto espllcivo in relazione al tempo. Quindi quello che andiamo ora a modificare nei processi non produrrà comunque l’efficienza desiderata.
- La nostra società affoga l’essenziale in un oceano di rumore. La realtà appare distorta e confusa, tutto sembra necessario. Il team Agile sa cosa è essenziale per creare un prodotto. Sa anche cosa è essenziale per far si che quel prodotto generi il massimo di valore per l’azioenda. L’essenziale è percepito e spesso nascosto da una montagna di regole, procedure, a itudini che creano rumore intorno al team, il pià delle volte solo che conosce il DNA dell’azienda sa spiegare il perche alcune cose avvenmgono o sono richieste.