Cos'è lo shape up, o dare forma alle idee

Shape up è un termine coniato da Basecamp, un azienda che da più di 15 anni lavora nello sviluppo software, partendo da un team di sole 3 figure fino al giorno d'oggi in cui sono un punto di riferimento anche in termini di product strategy. Il concetto di shape up proviene da un libro, consultabile anche online, scritto da Ryan Singer, che racconta come la sua azienda lavora. Può venire da pensare che il libro possa avere valore solo per realtà che si vogliono strutturare con cicli di lavoro simili — la verità è che il libro offre anche spunti trasversali e preziosi per ogni azienda che fa sviluppo e design, i cui problemi sono comunemente quelli di non riuscire a produrre con regolarità, che non riescono mai a fermarsi per pensare strategicamente a cosa e come sviluppare, o che sono troppo presi da piani e stime perdendo di vista il lavoro concreto.

Alcuni metodi e processi di lavoro avvengono naturalmente e spontaneamente in ogni azienda, specialmente tra le figure che hanno già lavorato insieme da un po' di tempo — al momento dell'onboarding di nuove persone però, o semplicemente per raccontare all'esterno "come facciamo le cose, quando le facciamo bene", nasce il bisogno di mettere tutti questi concetti nero su bianco. Per questo motivo è nato Shape up e per lo stesso motivo anche a Cantiere scriviamo e aggiorniamo guidelines interne per tutti.

Lo shape up è un processo che inseriamo all'interno dello sprint-plan, ossia quella fase che precede lo sviluppo vero e proprio e che parte da una certa necessità di business o strategica. In altre parole, è uno di quei momenti in cui recepiamo un certo bisogno dello stakeholder e cerchiamo di capirne di più, su ogni livello — sia tecnico che di produzione e strategico — prima di essere sicuri di poterlo assegnare al team di produzione con il minimo rischio possibile. Se volessimo fornire una descrizione da vocabolario, potremmo dire che lo shape up è tutto quel lavoro preliminare di tracciamento dei confini e riduzione dei rischi che viene svolto prima di assegnare un progetto al team.

Possiamo schematizzare il lavoro di shape up in queste distinte fasi:

• Identificare problemi e obiettivi ad alto livello;
• stabilire un appetite, appetito in italiano, cioè quanto tempo si è disposti ad investire per sviluppare un'idea;
• far coincidere l'idea con l'appetite, cioè circoscrivere il problema e trovare una soluzione che possa rientrare dentro l'appetite previsto;
• presentare il lavoro al team, ad un certo livello di astrazione.

L'output di questo processo sarà dunque una presentazione dell'idea (o un pitch come lo chiama il libro) che deve essenzialmente avere tre proprietà.

il team che fa lo shape up non deve prendere le decisioni più importanti nel momento in cui ci sono le minori informazioni. Il team potrebbe subire un effetto di lock-in sulle decisioni già prese che poi si potrebbero rivelare scadenti.

Non troppo concreta: Non vengono forniti wireframe precisi ma degli sketch molto vaghi che sì, illustrano l'idea, ma che lasciano margini al team per applicare il loro giudizio. Facciamo l'esempio che al team sia consegnato un wireframe che prevede una sidebar a destra — anche se solo un'indicazione, il team sarà comunque influenzato da questo vincolo. 

Non troppo vaga: Nessuno riesce a capire il problema e la soluzione se presentati solo a parole, senza indicazioni su cosa coprire e cosa invece lasciare fuori. Un esempio lampante è il calendario, un nuovo modulo che Basecamp ha aggiunto recentemente e che è un buon use case per far capire perché è necessario dare una forma ad idee astratte. "Fare un calendario" può voler dire tutto e niente: disegnare e sviluppare il calendario definitivo con tutte le feature possibili e immaginabili può comportare mesi o anni di lavoro — il vero obiettivo dello shape up è stabilire qual è quel 10% di feature da sviluppare, le più strategiche tra le centinaia a disposizione, in un tempo ben determinato. Questo tempo, per Basecamp, rappresenta un ciclo di lavoro, che è sempre pari a sei settimane: in altre parole si lavora sulla base di un tempo fisso e obiettivi variabili. Alla fine delle sei settimane di lavoro le stesse persone che hanno scommesso sul calendario devono poter voltarsi indietro e dire "sì, ne è valsa la pena". Basecamp non è un'azienda che fa calendari, dopotutto.

Al team viene presentato il problema e anche la soluzione. Il team che fa lo shape up oltre a farlo in ottica strategica, analizza il problema dal punto di vista tecnico ed è in grado di individuare i maggiori rischi che l'implementazione di una nuova feature, ad esempio, potrebbe portarsi dietro. Ci si chiede esplicitamente cosa possa andare storto, in modo da evitare i cosiddetti rabbit hole, cioè buchi in cui si può scavare all'infinito senza arrivare ad una soluzione. Un buon pitch rende questi rischi evidenti e li mette subito sul tavolo. Un buon metodo per trovare questi buchi è quello di immaginarsi un use case e percorrerlo molto lentamente dall'inizio alla fine. La curva di probabilità di un progetto i cui rischi più grandi sono dichiarati dovrebbe insomma cadere molto vicina alla deadline prevista. Attenzione però a pensare che tutti i rischi possono essere trovati durante lo shape up: su questo argomento ci tornerò sopra più tardi.

La prima informazione da presentare al team sono i limiti entro i quali si debba muovere. L'appetite è il dato che regola questi confini: Basecamp è un'azienda che lavora a cicli fissi di sei settimane di sviluppo dopotutto, come avevamo già ricordato parlando del calendario. Questi limiti settano l'aspettativa e agiscono da guardrail immaginari che aiutano il team a stare in focus sul problema da risolvere. Singer avrebbe potuto continuare a scrivere altri capitoli del libro se non si fosse dato un'appetite di tempo, a detta sua. Ricordiamoci che non esiste il concetto di soluzione migliore in assoluto — un pasto completo di tre portate è in valore assoluto migliore di un panino, ma se si hanno solo 5 minuti di tempo, un panino è la soluzione migliore. L'appetite e una deadline incombente guidano inevitabilmente le decisioni: a una settimana dal rilascio di un libro voi vi preoccupereste di rileggerlo e correggere eventuali errori di battitura o scrivereste un'altra sezione?

Una volta che un'idea è analizzata e passata attraverso uno shape up, non finisce in un backlog di cose da fare. Queste idee si impilerebbero una sull'altra in una sorta di cimitero di task che non potranno mai essere fatte tutte — piuttosto che avere sempre la sensazione di essere indietro e sprecare tempo prezioso a scegliere e organizzare idee vecchie e che magari non hanno più rilevanza, si scommette su un pitch per ogni ciclo di lavoro. A questo tavolo di scommesse si siedono le persone che fanno da "ambasciatori" per un certo progetto: sul tavolo ci sono solo le idee già analizzate che potrebbero essere potenzialmente sviluppate, e tra queste ne uscirà una su cui scommettere e da consegnare al team. Una qualsiasi idea sul tavolo — magari riportata all'attualità dopo un po' di tempo — è portata da una persona, in un determinato contesto, con un obiettivo e dettata da una necessità viva in quel preciso momento.

Singer è molto attento al lessico: non usa mai il termine "pianificare", perché non contiene esplicitamente il fattore di rischio che è invece è un concetto insito nello sviluppo software. Le idee non si pianificano, ma ci si scommette sopra — non si usa il linguaggio della certezza ma quello del rischio. La realtà dei fatti ci dice che non sappiamo esattamente cosa succederà con lo sviluppo di un progetto, specialmente se si introducono concetti nuovi o se ci sono interdipendenze tra i componenti. Un ciclo di lavoro è quanto si è disposti a scommettere per un'idea, e se per qualsiasi motivo, alla fine del ciclo, il progetto non è finito, non c'è mai del tempo bonus per finirlo. Una scommessa persa prevede la perdita del 100% di quello che si è messo sul tavolo, e nient'altro — se ci sono sei settimane sul tavolo, una scommessa non riuscita ne farà perdere tutte e sei, ma non un giorno di più. Una scelta coraggiosa, ma che a detta di Singer lavora in favore del morale dei dipendenti: immaginiamo di dare un lavoro al team che pensiamo lo possa impegnare per due mesi, e immaginiamo che dopo sei mesi ancora non sia finito. Il morale del team sarebbe sicuramente a terra.

Un altro concetto fondamentale e una verità a volte dimenticata nello sviluppo software è la differenza tra il lavoro che ci si immagina e quello reale. Siamo naturalmente poco inclini a dare stime esatte per le cose che ci accingiamo a fare: pensiamo di poter riordinare il garage in una mattinata per poi scoprire che ci potrebbero volere 3 giorni interi. Lo sviluppo e ogni altra disciplina che prevede della creatività sono terreno fertile per queste dinamiche — si inizia il lavoro con i task più evidenti e propedeutici ad altri, solo per scoprire che ce ne sono altrettanti di sommersi e che emergono solo in un secondo momento, magari nella seconda o terza settimana. Per questo motivo, un'altra promessa che si fa al team di sviluppo è quella di non disturbarlo durante il ciclo di lavoro — sarebbe controproducente e fuorviante fare dei check periodici, perché ci potrebbero ancora essere interdipendenze o novità non ancora venute fuori.

Scope creep (in italiano la traduzione più vicina è sindrome del kitchen sink, o lavello della cucina) è una dinamica che avviene nel project management per cui lo scope (o l'ampiezza del progetto) aumenta senza controllo via via che si procede nello sviluppo e si incontrano non solo cose che si dovrebbero fare, ma anche cose che si pensano siano da fare. Il team deve essere particolarmente bravo a riconoscere tutte queste deviazioni dall'obiettivo primario del progetto e saper distinguere quei nice-to-have che distraggono dai must-have. Il team ha una grandissima responsabilità nel fare questi tagli e rimanere fedeli all'obiettivo iniziale, senza farcire il progetto con feature che non erano previste nel brief.

Se questo articolo ti ha incuriosito e sei interessato su come Cantiere Creativo applica i concetti dello shape up al suo lavoro, contattaci per parlarne insieme. 

Molti dei contenuti di questo articolo provengono da Shape Up: Stop Running in Circles
and Ship Work that Matters che puoi trovare a questo link in versione online.