Agile "a modo nostro"
...e come previsto siamo arrivati a parlare di ciò di cui non avremmo dovuto parlare.
Ancora oggi se andate in giro per le aziende e chiedete se applicano Agile vi sentite dire cose del tipo: "Si usiamo sia SCRUM che Kanban, ma a modo nostro, un po' all'acqua di rosa."
Poi approfondisci e ti senti dire: "Abbiamo rinunciato allo Scrum Master perchè non serve a nulla: tanto abbiamo capito che cosa ci serve realmente. Usiamo dei team leader per fare lo stesso lavoro e ci va bene così".
Ora, è vero che ogni metodologia non va adottata a scatola chiusa e deve essere modificata in base al contesto in cui si lavora (cultura aziendale, pratiche e processi preesistenti, maturità del team...), però non è possibile pensare di sostituire una ruota tonda con una quadrata e pensare che sarà la stessa cosa.
Quello che voglio sottolineare è che un approccio "casareccio" rischia di far perdere buona parte del reale valore insito nelle varie metodologie Agili.
Ad esempio per SCRUM:
- chi verifica che valori centrali come il rispetto, la sostenibilità, il miglioramento continuo, la partecipazione, il coraggio, l'efficenza dell'organizzazione siano tenuti in giusta considerazione?
- chi garantisce la crescita del team?
- la servant leadership che cosa vuol dire?
- il team che si auto organizza che fine fa se decide il team leader?
- la responsabilità condivisa?
- chi garantisce che le partiche siano rispettate in base alla loro reale funzione?
E si potrebbe andare avanti per ore ad evidenziare i limiti di questo modo di lavorare.
Poi applicato a Kanban fa ancora più preoccupare...
La verità è che probabilmente qualcuno ritiene che "essere agili" sia una qualità acquisita una volta per tutte e non un modo di lavorare che deve rispondere efficacemente ai cambiamenti continui di un progetto.
Siamo ritornati esattamente da dove siamo partiti: i processi "consolidati" contano più delle persone e del cambiamento. Tanto vale tornare al waterfall... perchè alla fine sarà solo questsione di tempo e così si finirà. Non a caso in queste aziende cercano team leader che facciano da "project manager".
Alla fine è proprio questo il ruolo primario dello Scrum Master: riaffermare i principi fondamentali dell'Agile Manifesto e verificare che le pratiche adottate siano coerenti ad essi.
Io non voglio giudicare nessuno, ma questo Agile "a modo nostro" sa tanto di aziende che non hanno capito molto di Agile e quindi, sarebbero quelle che più delle altre avrebbero bisogno di un po' di coaching vero!
Software Architect presso Par-tec Spa
5 anniSempre più spesso agile fai da te = anarchia
Agile Coach | Visual facilitator | LEGO® SERIOUS PLAY® Certified facilitator | CSP-SM® | CSPO® | KMP I | KMP II | Contrabbandiere di Agilità
5 annicreare un proprio metodo va benissimo, basta che i principi e i fondamenti dell'Agile rimangano inalterati; in fondo ogni azienda è unica con le sue particolarità. quello però che mi fa rabbrividire è il percorso "fai da te", in generale qualsiasi strada si voglia percorrere è necessario il supporto di un Agile coach professionista.
ICT Solution/Software Architect - Agile Facilitator presso SNJ
5 anniAlla fine è una questione di scelta tra le necessità piuttosto che la necessità di una scelta. Voglio dire, è vero che Agile si presta a 'diluirsi' negli altri cicli di vita, nasce per questo alla fine, ma questo non vuol dire che se si dissolve è tutto normale. Forse un po' dfi bianco / nero andrebbe portato avanti., Tipo come Scrum Master / Coach chiedere: ti sta bene come si sta lavorando? Ti piacciono i risultati che stai avendo? No? Allora stammi a sentire. ....E' che poi dall'altra parte arriva sempre una risposta del tipo: "mma certo... io Agile.. io Scrum..Kanban...però...ora facciamo prima questo".
Informatico, Transizione digitale per la PA, Gestione Documentale e Formazione
5 anniOttime quanto condivisibili affermazioni
IT Program, Delivery & Service Manager | Helping organizations in delivering digital solutions
5 anniOmmamah!!! Leggere "waterfall" è sintomo di confusione, come l'articolo ben mostra...