In realtà le aziende convenzionali in passato non se lo sono posto il dilemma e hanno scelto, senza ombra di dubbio, scrum. Ora, però, iniziano a dubitarne. Soprattutto quelle che hanno visto dipartimenti o società consociate adottare scrum e dopo quattro anni di impegno e di duro lavoro si ritrovano con in mano un pugno di mosche.
O meglio, la consociata strilla che sono agili perché fanno scrum, opportunamente arrangiato alla loro realtà, ma di fatto non lo sono (vedi Lesson Learned #01).

L’azienda gemella o consociata vede benissimo che di agile non hanno proprio nulla e che il loro modo di fare scrum è solo la forma esteriore che danno allo stesso solito modo di fare le cose, solo ordinato diversamente. E poiché ambiscono a diventare agili, ora il dilemma se lo pongono, eccome.

Scrum è sinonimo (improprio) di Agile

Perdonatemi. Ho dato per scontato che tutti sappiano che cosa è scrum. Rimedio.

Scrum è la metodologia Agile che ha avuto più successo delle altre per cui è diventata, durante la moda di diffusione Agile (2018-2023 in Italia), non solo la più diffusa ma anche sinonimo di Agile. Ovvero per definirsi Agile bastava aver implementato scrum.

Il termine scrum in business venne utilizzato per la prima volta da Ikujiro Nonake (Hitotsubashi University) e Hirotaka Takeuchi (Harvard University) in un articolo, divenuto famoso, apparso nel 1986 sulla Harvard Business Review dal titolo The New New Product Development Game.
Nonaka e Takeuchi avevano studiato alcune aziende che avevano creato un nuovo modo di sviluppare nuovi prodotti, non basato su gerarchie, procedure, catene di comando e processi decisionali top down. Questo nuovo approccio prevedeva team, composti da persone con competenze molto differenti, che prendevano le decisioni di sviluppo in modo autonomo.
L’associazione che venne loro spontanea fu lo scrum, la mischia del rugby, dove non un leader e neppure uno schema predeterminato guidano le decisioni, ma è il team che prende le decisioni in modo autonomo, sul momento a seconda dei movimenti del team avversario.

Ma torniamo ad Agile e Scrum. Negli anni ’90 gli sviluppatori di software si erano accorti che il tradizionale project management waterfall applicato allo sviluppo del software produceva risultati inquietantemente scadenti. Il che li spinse a sperimentare nuove strade.
Agli inizi degli anni ’90 esistevano già nuovi approcci metodologici come Extreme Programming. Nel 1996 i primi tentativi di elaborare una guida scrum ad opera di Ken Schwaber e Jeff Sutherland e nel 2001 la pubblicazione del Manifesto per lo sviluppo agile del software che dettava principi e linee guida.

Ma come funziona scrum?

Scrum è una metodologia focalizzata a far lavorare un team, composto da elementi con competenze diverse, focalizzato allo sviluppo del software.

Prevede dei ruoli precisi: lo scrum master, detentore della metodologia e facilitatore del team (inizialmente doveva essere esterno al team ma per ragioni di costi è finito per essere un componente del team). Il product owner che è responsabile del backlog [la board che raccoglie tutti i requisiti del software ordinato per priorità, quelle più precise (user story) da realizzare nell’immediato futuro, mentre le descrizioni più vaste (epiche) sono di lungo periodo]. Il product owner rappresenta il contatto con il cliente ed è responsabile di determinare le priorità in base alle richieste del cliente. Poi c’è il team di sviluppo responsabile delle decisioni dello sprint.
Quindi ci sono gli artefatti: il backlog di prodotto, il backlog dello sprint e gli incrementi.
Infine gli eventi, ovvero le diversi tipologie di meeting.

In estrema sintesi, scrum rappresenta il più cospicuo tentativo di dare una struttura ordinata, organizzata e regolata ai concetti alla base di Agile redatti nel Manifesto pubblicato nel 2001 ad opera di 17 sviluppatori.

Perché le aziende amano Scrum

Scrum, purtroppo, è diventato l’approccio metodologico perfetto per le aziende che volevano diventare Agile senza cambiare il sistema.

Dal punto di vista di un’organizzazione convenzionale, basata sul paradigma di predizione e controllo (evoluzione del più ancestrale paradigma di comando e controllo), non vi è nulla di più rassicurante di una metodologia prescrittiva, con ruoli definiti e ben delineati, che prevede cicli precisi in termini di tempo (gli sprint), in cui sono circoscritti la tipologia e la durata dei meeting a seconda della durata degli sprint. Rassicurante perché permette di pensare di avere per le mani il metodo che le trasformerebbe in organizzazioni adattive.
Nulla di più falso! Ma è l’approccio più vicino a ciò a cui sono già abituate: la convinzione che sia sufficiente adottare un metodo ‘one fit all’ e applicare il ‘copia e incolla’. E così fecero, e continuano a fare. Lo fanno adattando scrum alla loro realtà, spesso diluendo la metodologia nel loro modo usuale di lavorare. Quasi sempre abbandonandolo dopo diversi anni (in genere quattro).
Naturalmente i puristi di scrum, profondi conoscitori e applicatori del metodo, dicono che non è stato applicato rigorosamente e quindi non può funzionare. Può darsi. Va detto che scrum fu inizialmente implementato in aziende di sviluppo software e con la crescente moda manageriale di Agile si è diffuso nel resto dell’organizzazione, o meglio, in alcune parti dell’organizzazione, dove i manager vedevano minori rischi.

Ma vediamo cosa accade di solito quando si applica scrum.

Cosa accade quando si applica scrum

I team sono composti su criteri manageriali top down che tengono conto delle competenze dei singoli e quasi sempre sono team all’interno di un dipartimento, il team di sviluppo, il team di marketing e via dicendo. Quello che ho visto è che i rituali scrum si sovrapponevano ai meeting abituali creando un sovraccarico alle persone che vi lavoravano. Lo scrum master conduceva i meeting secondo il cerimoniale stabilito dal metodo, il che risultava vuoto e insignificante per i partecipanti che lo vivevano come uno spreco di tempo e chiedevano a viva voce di ridurre il tempo dei rituali. Quasi mai, poi, veniva condotta la fase iniziale di chartering (detta anche di inception o kickoff), fase in cui si costituisce il team come tale definendo il perimetro (scope), lo scopo di lungo periodo, i criteri di misurazione del successo delle attività, e gli working agreement, almeno quelli iniziali. Infine il product owner finiva per essere il manager o il project manager a cui veniva assegnato un nuovo nome e che, in sostanza, non cambiava certo il suo comportamento.

Quando ho preso in mano, come Agile Coach, team che già applicavano scrum la prima cosa che ho fatto è stato dire “dimenticate scrum” e ho proposto di ricostituire il team su basi diverse, attorno al value stream.

Perché Scrum da solo non basta a trasformare un’organizzazione

Veniamo ora alla principale criticità che ho incontrato nell’utilizzo di scrum. Se da una parte è vero che scrum permette ai team di migliorare le loro performance come team, dall’altra scrum è una metodologia focalizzata al miglioramento delle performance di ogni singolo team e non produce una sufficiente visione sistemica di come lavora l’organizzazione per portare valore al cliente.
Di questo si sono accorti anche i cultori di scrum e intorno al 2011 iniziarono a sorgere nuove metodologie di scale up con lo scopo di creare coordinamento tra i vari team: SAFe, LeSS, DAD, SoS e via dicendo.

Secondo il mio punto di vista, questi approcci rimangono chiusi all’interno delle convinzioni organizzative convenzionali che ne determinano i limiti. Vero è che anche in quegli anni iniziava a sorgere nello sviluppo del software l’approccio DevOps che pescava molti strumenti sviluppati nel Lean Thinking, tanto da spingere alcuni practioner a nominarlo Lean IT o sviluppo del software Lean basato sul processo piuttosto che su un metodo che stabilisce come il team debba interagire.

Di per sé scrum non ha nulla di male come metodologia. Solo che andrebbe applicata in un secondo momento quando i team stanno già lavorando in modalità agile, ovvero mentre costruiscono il nuovo modello operativo.

E comunque il mondo Lean Agile è cosi ricco di metodologie, strumenti e pratiche che è sempre meglio offrirle al team quando servono, quanto serve e quanto basta, e lasciare che siano loro a decidere se per loro funzionano e come applicarle.

🎧 Ascolta il podcast Agile Confidential #LessonsLearned su Spotify.