L'apertura al cambiamento è un prerequisito per la

Come diventare agili - Una guida agenzia

Creazione di condizioni ideali per progetti client agili

Questo articolo è disponibile anche in tedesco.

Negli ultimi anni, "agile" è diventato una parola d'ordine sempre più popolare nella scena dell'agenzia. C'è a malapena una singola azienda che non professa di lavorare agilmente. Ma cosa significa in realtà? Come si può capire quanto sia realmente agile un'azienda? Se si lavora negli sprint, significa che si è già agili? (Risposta: no.)

In Aperto Move, abbiamo costantemente analizzato e perfezionato i nostri metodi di lavoro negli ultimi due anni e mezzo, portando avanti la nostra visione di agilità sul posto di lavoro. Una delle realizzazioni più inconfutabili è stata che la transizione verso l'agile richiede tempo ed esperienza. Non si può semplicemente cambiare agile. Sebbene non siamo ancora dove vorremmo essere, i miglioramenti sono chiaramente evidenti.

L'applicazione di metodi agili in un'agenzia è del tutto più difficile che, ad esempio, nello sviluppo del prodotto; poiché si creano prodotti per clienti diversi, dove le condizioni possono variare drasticamente tra i progetti. Pertanto è difficile credere che ogni agenzia improvvisamente sembri agile. Fortunatamente ci sono fattori che possono aiutare a determinare facilmente fino a che punto un'azienda si è avviata per diventare agile.

I consigli presentati in questo articolo si basano su scenari comuni per la maggior parte delle agenzie, che sono sorti nel nostro lavoro quotidiano e sono stati risolti, una volta identificati come problemi. Non sono soluzioni per tutti, ma piuttosto una raccolta di apprendimenti che funzionano meglio per noi.

1. Chiarire la terminologia

Quando si introduce agile, è fondamentale che tutti nell'azienda abbiano la stessa comprensione del termine, altrimenti si corre il rischio di pericolose comunicazioni errate. Ho incontrato persone che confondono l'approccio agile nel rinunciare a tutte le fasi concettuali, alla pianificazione e agli incontri regolari a favore dell'immersione diretta in un progetto e vedere cosa succede. Non è difficile immaginare che un tale progetto fosse tutt'altro che semplice.

Altri hanno semplicemente sentito parlare di "Scrum" e nutrono una certa riluttanza nei suoi confronti, respingendolo come "qualcosa per gli sviluppatori" che soffoca il processo creativo. Per la maggior parte, queste affermazioni provengono da persone che non hanno esplorato Scrum o metodi agili. Inoltre, coloro che non ne hanno familiarità, spesso non possono dire la differenza tra Agile e Scrum e classificarli come uno e lo stesso.

Scrum e agile non sono gli stessi

Scrum è un framework che definisce regole, ruoli e processi di lavoro specifici per lo sviluppo del software. Un esempio è la definizione di intervalli di tempo in cui viene consegnato un prodotto funzionante (i cosiddetti sprint). L'implementazione di Scrum contribuisce allo sviluppo agile del software, motivo per cui i termini sono spesso visti come sinonimi, ma non lo sono.

"Agile", d'altra parte, è un modo di pensare o di cultura, che incapsula molto più che semplicemente ciò che Scrum fa. I principi che definiscono la cultura agile sono enunciati nel Manifesto Agile e sono illustrati nel seguente video:

Scrum è solo un possibile approccio per seguire i principi agili. Si può anche essere agili senza usare Scrum. D'altra parte, solo perché si rispettano le regole di Scrum, non significa che si stia effettivamente lavorando agile.

2. Addio al ruolo di project manager (saluta ruoli agili)

In Scrum sono definiti i seguenti ruoli:

  • Proprietario del prodotto
  • Maestro di mischia
  • Team di sviluppo
  • Altre parti interessate, come l'utente finale o quelli coinvolti dalla parte del cliente

Non ci sono altri ruoli, né sono necessari. Il classico project manager non è più necessario in questa configurazione. Avrebbe solo ostacolato il processo, poiché tutti i compiti precedentemente condotti dal project manager sono ora coperti dalle posizioni sopra elencate. La responsabilità del successo del progetto non dipende più da una persona, ma piuttosto da tutto il team.

Ogni ruolo aggiuntivo che esiste nel progetto - e si colloca tra il team Scrum e il cliente - è un ostacolo alla comunicazione diretta ed efficace tra il team e il cliente.

Prendi sul serio ruoli e responsabilità

Se uno non ha bisogno di un project manager, non avrebbe senso assumere precedenti project manager in un ruolo combinato di Scrum Master e Product Owner?

No. Da un lato, entrambi i ruoli Scrum Master e Product Owner implicano abbastanza compiti che per eseguirli entrambi si tradurrebbe nella trascuratezza di uno dei ruoli. Alla fine, i due ruoli hanno interessi contraddittori. Il Product Owner rimane in costante contatto con tutte le parti interessate e garantisce che il prodotto giusto sia consegnato nella migliore qualità. Tra le altre cose, lo Scrum Master deve assicurarsi che il team non sia sovraccarico di lavoro o interrotto. Quindi, Scrum Master non ha nulla a che fare con il prodotto stesso.

Un'idea ancora peggiore sarebbe quella di omettere del tutto lo Scrum Master. Senza uno Scrum Master in recitazione, non vi è alcun ruolo per garantire che il team lavori in modo produttivo, rispetti le scadenze o apprenda attraverso retrospettive e diventi più efficiente. In breve, sono quelli che garantiscono che il progetto sia condotto in modo agile. Nella nostra esperienza, è un ruolo particolarmente importante in un ambiente di agenzia con clienti, parti interessate e condizioni in evoluzione, poiché Scrum Master assume anche un ruolo di coaching per il cliente.

Questo articolo spiega le diverse funzioni di Scrum Master e del classico project manager in termini di un'analogia del traffico di facile comprensione:

3. Niente più pianificazione delle risorse (stabilire invece il principio pull)

Nelle agenzie, spesso vengono elaborati contemporaneamente più progetti per vari clienti, rendendo una distribuzione efficace del lavoro tra tutti i dipendenti una sfida.

L'approccio classico dell'agenzia è la pianificazione delle risorse: un project manager crea piani per diversi giorni o settimane e assegna i dipendenti rispettivamente a progetti o attività. Ciò richiede molto tempo per la pianificazione e il coordinamento e si traduce in inflessibilità, poiché funziona presupponendo che tutte le proiezioni e i piani per il tempo assegnato siano rispettati.

L'esperienza ci insegna che, in realtà, tali piani non si realizzano mai: un'importante consegna viene ritardata, i dipendenti si ammalano o si verificano altre circostanze impreviste, che portano a compiti individuali che richiedono più tempo del previsto. Le conseguenze sono una distribuzione irregolare del lavoro tra i colleghi, più stress e straordinari.

Questo cosiddetto "principio push" (poiché i dipendenti hanno singoli compiti "spinti" su di loro) non è quindi ottimale. Quindi, come viene distribuito il lavoro senza un project manager nella costellazione agile? Questo problema richiede un approccio diverso:

Il principio pull

Il lavoro agile si basa su una mentalità "pull". Ciò significa che i dipendenti decidono in modo proattivo quali compiti desiderano svolgere. Affinché ciò funzioni, le attività imminenti e i loro progressi devono essere comunicati in modo trasparente.

In una situazione ideale, ciò non si verifica solo a livello di progetto ma per tutte le attività imminenti all'interno dell'azienda. Ciò include la valutazione dell'ambito, la creazione di presentazioni, la preparazione di seminari, la partecipazione a interviste o persino la stesura di questo articolo. Ciò può essere realizzato con una scheda Kanban, ad esempio:

Il principio pull aiuta a garantire una distribuzione uniforme del lavoro tra i dipendenti in cui ognuno ha la libertà di decidere autonomamente, quando ha la capacità di lavorare sui propri compiti. Questo aiuta ad eliminare la possibilità di sovraccaricare determinati dipendenti.

Affinché il principio pull funzioni, devono essere soddisfatte le seguenti condizioni:

  • La comunicazione costante è cruciale. In Aperto Move, lo stato del progetto viene discusso tre volte alla settimana alla lavagna
  • Richiede persone con la capacità di prendere l'iniziativa piuttosto che aspettare che gli altri diano loro cosa fare
  • Favorisce le gerarchie piatte e richiede la volontà di implementarle
  • Il management dell'azienda deve avere fiducia nei propri dipendenti per consentire loro di assumersi maggiori responsabilità
  • Occorre distinguere chiaramente tra singoli compiti e progetti. I progetti non sono realizzati da una sola persona, ma da un team. Questo sarà esplorato ulteriormente nella sezione seguente.

4. Stabilire squadre stabili

È tipico nelle agenzie lavorare simultaneamente per vari clienti e compiti urgenti (come valutazioni dell'ambito, passi o correzioni di errori) spesso sorgono con breve preavviso. Pertanto, i team di progetto vengono spesso creati in base alla disponibilità attuale. Questo tipo di pianificazione delle risorse impedisce efficacemente progetti agili.

I team agili dovrebbero essere stabili e idealmente trovarsi. Solo i team più stretti possono svilupparsi in modo ottimale e sostenere o addirittura accelerare il ritmo imparando gli uni dagli altri, coordinando i loro processi e la comunicazione e identificando e risolvendo i problemi attraverso l'analisi retrospettiva.

I team possono identificare e risolvere i problemi attraverso retrospettive regolari (Immagine di Andreas Plath)

Al fine di evitare l'interruzione di efficaci team di colleghi che lavorano bene insieme e quindi eliminando tutti gli effetti di apprendimento e di routine, i progetti imminenti non dovrebbero essere pianificati tenendo conto delle persone, ma piuttosto con team stabili.

Tuttavia, non è realistico pensare che la trasformazione di un'intera agenzia con tutte le discipline in squadre stabili ed equilibrate possa avvenire dall'oggi al domani. È ipotizzabile che non tutti vogliano lavorare permanentemente nella stessa squadra. Pertanto, è fondamentale trovare un equilibrio che funzioni bene per tutti.

5. Creare proposte agili

Una fase di proposta classica e semplificata tra i clienti e un'agenzia di solito assume la seguente forma: Un cliente ha un'idea specifica per un prodotto e una sequenza temporale su quando deve essere finito.

Il cliente quindi informa l'agenzia sui requisiti (magari con un tono) e chiede una proposta specificando un prezzo fisso per lo sviluppo di questo prodotto. Al fine di tutelarsi, entrambe le parti dedicano una notevole mole di lavoro all'elaborazione della proposta per evitare potenziali comunicazioni errate.

Dal punto di vista del cliente, questa di solito sembra una soluzione praticabile: sanno cosa stanno ottenendo quando ea quale prezzo.

I requisiti cambiano

Ciò che la maggior parte dei clienti non sa a questo punto è che spesso vogliono qualcosa di molto diverso alla fine del progetto, come hanno fatto all'inizio.

Poiché tutto è concretamente definito nella proposta, è quindi quasi impossibile cambiare qualcosa all'interno del progetto in un secondo momento senza rinegoziazioni, come:

  • altre caratteristiche sono diventate più importanti nel frattempo
  • il progetto desiderato non è più tecnicamente fattibile
  • i test degli utenti hanno rivelato che il prodotto è frainteso o che non ha senso
  • un concorrente ha creato un prodotto simile che richiede un perno strategico

In questo caso, una nuova priorità non è facile se nella proposta viene specificato il vecchio ambito rivisto.

Altri importanti aspetti dell'essere agili sono minati da questo tipo di proposta. Un miglioramento continuo e collaborativo del prodotto è molto più difficile, poiché il prodotto deve essere chiaramente definito all'inizio per finalizzare la proposta. Questo porta a un tipico flusso di lavoro a cascata. La pianificazione dello sprint, inclusa la pianificazione del poker, diventa altrettanto inutile perché sono già state definite una scadenza finale e un risultato finale.

Se la portata, la scadenza e il prezzo sono già stati fissati all'inizio, non ha più senso cercare di attuare un quadro agile come Scrum.

In questo caso, non è più possibile utilizzare i principali vantaggi della consegna agile, ma si ha ancora una spesa extra delle riunioni Scrum che non forniscono alcun valore reale. Questo processo è anche chiamato "pseudo Scrum".

È necessario un altro tipo di proposta

Ha più senso addebitare l'importo del lavoro svolto (i cosiddetti contratti a tempo e materiali) piuttosto che definire i risultati esatti nella proposta. Solo così è possibile eseguire un progetto in modo agile.

Quanto e ciò che il cliente ottiene per i suoi soldi è determinato da solo nel corso del progetto, mantenendo aggiornato l'elenco delle esigenze e assegnando le priorità insieme al team.

Elaborare proposte agili richiede pratica (Fonte: https://unsplash.com/?photo=OQMZwNd3ThU)

Affinché il cliente possa avere un'idea di ciò che può aspettarsi, si può dare una stima approssimativa di quanto è possibile ottenere in un determinato intervallo di tempo o quanto tempo ci vorrà prima che un determinato requisito venga implementato. Più a lungo una squadra ha lavorato insieme, più precisa diventa questa stima, poiché è più facile misurare il ritmo generale o la "velocità" della squadra. Questo è un altro motivo per cui è preferibile lavorare con team stabili.

Detto questo, l'elaborazione di una proposta è ancora uno degli elementi più difficili della transizione agile. Difficilmente un singolo cliente che non ha già acquisito esperienza in un ambiente agile, desidera firmare un contratto a tempo indeterminato. Per convincerli del suo merito, è di vitale importanza dimostrare abilità e creare prima la fiducia con il cliente.

Nella nostra esperienza, questa sfida è facilmente superabile non appena si è completato un progetto agile insieme. È allora che il processo del progetto parla da solo; ottenendo risultati rapidi e tangibili attraverso un lavoro iterativo, una stretta collaborazione e cicli di feedback più brevi, che sono molto più vicini a ciò che il cliente immaginava di quanto non sarebbero nei tipici progetti a cascata.

C'è molta letteratura utile disponibile sull'argomento di proposte agili come questo libro:

6. Coinvolgere il team di progetto nella fase di acquisizione il prima possibile

Nelle agenzie, la fase di acquisizione e proposta è spesso isolata dall'attuazione del progetto. Un nuovo team aziendale è responsabile di nuovi progetti e il team del progetto non si confronta con i dettagli fino alla fase di implementazione, aumentando la probabilità di conflitti.

La fase della proposta può già essere cruciale per stabilire se un progetto avrà successo o meno. È quindi essenziale che il team agile sia incluso nella comunicazione il prima possibile.

Di conseguenza, si può valutare relativamente presto se un'implementazione agile è fattibile e quanto tempo ci si può aspettare. Il tempo impiegato, ad es. il numero di sprint richiesti in un progetto di mischia può essere valutato solo dal team stesso, se ne conosce il più possibile il progetto.

Occasionalmente ci saranno più richieste di progetti di quante non ci sia la capacità di lavorare su di esse. Per implementare il principio pull e selezionare il progetto più adatto, il team deve conoscere il più possibile tutti i progetti in sospeso. Solo così potranno prendere una decisione informata e incorporare in modo significativo nuovi progetti negli sprint di quelli attuali.

All'inizio del nuovo progetto, il team dovrebbe conoscere quanto prima tutti gli stakeholder e le loro esigenze al fine di fornire il prodotto giusto con la migliore qualità possibile. Una misura efficace per raggiungere questo obiettivo è di tenere un seminario con il team e le parti interessate sul lato client.

Inoltre, è importante comunicare i valori agili al cliente, identificare la persona di contatto principale e spiegare in dettaglio la procedura di collaborazione.

7. Dimentica il ruolo del fornitore di servizi (e lavora in team con il tuo cliente)

Una relazione cliente / fornitore di servizi è controproducente in quanto si basa sempre sul presupposto che il cliente ha aggiudicato un contratto e si aspetta un risultato specifico. Un risultato di successo del progetto, che soddisfa tutte le parti interessate, richiede in genere un lavoro da tutte le parti, in particolare una comunicazione regolare tra loro.

Un prerequisito essenziale per un progetto agile di successo è la comunicazione allo stesso livello. Ciò significa che il cliente e l'agenzia si considerano l'un l'altro come un unico team, lavorando insieme su un progetto e identificando e apprezzando i punti di forza dell'altro. L'agenzia è generalmente esperta in strategia, esperienza utente, design e implementazione tecnica; il cliente, d'altra parte, ha familiarità con i propri processi e requisiti interni, nonché con il loro pubblico di destinazione. Solo quando queste informazioni sono condivise, si può creare un prodotto veramente orientato all'utente che soddisfi tutti gli stakeholder.

Ciò richiede che vi sia un referente designato sul lato client, che è disponibile a rispondere a domande riguardanti il ​​progetto o può fornire all'agenzia tutto il materiale mancante. Non tutti i clienti possono o vogliono investire così tanto tempo in un singolo progetto perché i loro processi di lavoro interni non lo consentono.

Nella nostra esperienza, i clienti di solito notano in una fase iniziale quanto più velocemente ottengono risultati di alta qualità attraverso una cooperazione agile. Ciò corrisponde alle loro aspettative e sono disposti a investire il tempo.

8. Fornire spazio per il lavoro di squadra

Essere agili significa lavorare in modo interdisciplinare e con una comunicazione continua. Funziona meglio se il team agile si riunisce, il che aiuta a coordinare facilmente il loro lavoro. Idealmente ogni squadra dovrebbe avere il proprio spazio in cui può lavorare indisturbata minimizzando i disturbi per gli altri, ad es. quando si discutono progetti o caratteristiche.

I team agili dovrebbero essere in grado di lavorare senza essere interrotti (Fonte: https://unsplash.com/photos/5T6lSk2uI1A)

Le agenzie spesso dipingono un quadro diverso: il raggruppamento dei dipendenti secondo le rispettive discipline. Ciò significa che tutti i designer siedono in un angolo dell'ufficio, gli sviluppatori in un altro angolo e i tester e gli account manager spesso in stanze completamente diverse. Sebbene ciò possa avere senso in termini di scambio relativo alla disciplina, complica la comunicazione all'interno di un team di progetto. Scrivere l'un l'altro è una possibilità, ma ci vuole molto più tempo che parlare direttamente l'uno con l'altro.

Diventa ancora più difficile quando tutti i membri del team non si trovano nella stessa posizione. Tutti sanno quanto siano cattive le conferenze telefoniche o video e, se non hai dovuto subirle prima, si consiglia questo video:

9. Considerare ogni disciplina e l'intero processo del progetto

Poiché Scrum è nato dallo sviluppo del software, può sembrare conveniente eseguire solo l'aspetto tecnico del progetto in modo agile, lasciando intatta la fase creativa. Ciò tuttavia ottiene relativamente poco, poiché la struttura a cascata viene risolta solo alla fine di un progetto.

Un processo a cascata classico si basa sull'approvazione di risultati specifici

Supponiamo che il team agile sia composto esclusivamente da sviluppatori; il concetto e il design del sito Web del cliente sono già completi, ma nel mezzo dello sviluppo diventa evidente che stati importanti non sono stati definiti o progettati e il team creativo è già impegnato nel loro prossimo progetto. E adesso? Si dovrebbe togliere la gente da altri progetti? Continuare a sviluppare un prodotto incompleto? Non esiste una risposta semplice se non quella di coinvolgere tutte le discipline pertinenti nel flusso di lavoro agile sin dall'inizio.

Lo scambio regolare all'interno del team di progetto migliora la qualità del prodotto (Fonte: https://unsplash.com/photos/gN_nIUnjYJI)

Feedback, Feedback, Feedback

Un enorme punto di forza e un motivo importante per cui la qualità del software sviluppato agile è migliore di quella dei progetti a cascata nell'ambito della gestione di progetti classici, è la collaborazione interdisciplinare e il miglioramento iterativo dei prodotti basati su feedback precoci e regolari tra tutte le parti interessate.

In parole povere, questo significa: tutti riesaminano tutto in ogni fase del progetto.

  • Il cliente e l'intero team forniscono il feedback del Product Owner (PO) alle storie degli utenti
  • I progettisti dell'interfaccia utente forniscono feedback su wireframe ed esecuzione tecnica
  • I progettisti di UX forniscono feedback sulla progettazione dell'interfaccia utente e sull'esecuzione tecnica
  • Gli sviluppatori front-end forniscono feedback a wireframe, progetti di interfacce utente, interfacce back-end e, ove applicabile, implementazione back-end
  • Gli sviluppatori di back-end forniscono feedback su wireframe, design dell'interfaccia utente e implementazione front-end
  • Il controllo qualità (QA) fornisce feedback a wireframe, design dell'interfaccia utente ed esecuzione tecnica
  • Gli utenti forniscono feedback tramite test di usabilità durante tutte le fasi del progetto (wireframe, prototipi di progettazione, click manichini, implementazione front-end)
  • Il cliente fornisce feedback sugli incrementi del prodotto durante le riunioni di revisione dello sprint
In una configurazione agile, il team lavora insieme anziché consecutivamente

Il feedback regolare è la risorsa più importante nello sviluppo agile e garantisce che il prodotto sia sviluppato a un livello che soddisfi tutti gli stakeholder. Naturalmente, questo funziona solo quando tutti sono coinvolti in ogni fase del progetto.

10. Non aspettarti che tutto funzioni immediatamente (fai errori e impara da loro)

Speriamo che le sezioni precedenti abbiano indicato che, su più livelli, è necessario adottare approcci diversi rispetto a quelli che probabilmente sono stati sviluppati e stabiliti nel corso degli anni. Ciò rende ancora più importante capire che il passaggio a diventare agili è un processo, e non necessariamente un processo facile, né uno con un fine definito.

L'implementazione delle misure sopra discusse non garantisce automaticamente il passaggio all'essere agili. Allo stesso modo, non è sufficiente implementare solo aspetti "tecnici", come l'adozione di Scrum. È molto più essenziale cambiare la cultura aziendale e stabilire un sistema di valori agile e comune a tutti i livelli gerarchici.

Sarebbe ingenuo aspettarsi che tali cambiamenti fondamentali possano essere realizzati all'istante e senza intoppi. I cambiamenti nei processi aziendali possono anche essere trattati come un progetto agile e implementati in modo iterativo.

In definitiva, ciò significa che non si dovrebbe cercare di cambiare tutto in una volta, ma piuttosto implementare una misura alla volta. In questo modo, si impara cosa funziona, cosa no e cosa può essere migliorato. Sarebbe sbagliato attenersi a una misura che non sembra corretta, solo perché un libro o un blog lo ha raccomandato.

Il coaching esterno può essere altrettanto utile nell'avviare i giusti processi di pensiero, tuttavia non si può sperare di trovare un rimedio rapido, il che rende improvvisamente agile.

È altrettanto importante stabilire uno scambio interno di conoscenze ed esperienze e concordare un approccio comune. Per raggiungere questo obiettivo, è utile dare un'occhiata periodica ai dodici principi alla base del Manifesto Agile e rivedere in che misura una società li abbia già adottati:

Nel nostro team, la stretta aderenza alle linee guida del framework Scrum ha dimostrato la soluzione migliore. Ogni volta che questi processi sono stati deviati, ha portato a complicazioni e maggiori sforzi. Questo, tuttavia, non deve essere il caso di tutti. Ogni azienda deve scoprire da sé ciò che funziona meglio.

Conclusione

Anche prima dell'inizio di un progetto cliente, alcune condizioni standard dell'agenzia possono compromettere o addirittura rendere impossibile il successo di progetti agili. È qui che è richiesto un nuovo modo di pensare a tutti i livelli e in tutte le discipline, che implica cambiamenti che non possono essere implementati dall'oggi al domani.

I punti sollevati in questo articolo possono servire da guida per riconoscere e discutere situazioni e problemi nella pianificazione di progetti agili, prima che inizino.

Quali sono le tue esperienze su questo argomento? Conosci altre circostanze che rendono difficili i processi agili? Facci sapere nella sezione commenti di questo articolo.

Ulteriori letture

Aperto Move - Una società IBM è un'agenzia di Berlino per servizi digitali e mobili con circa 30 dipendenti. E tu?

Seguiteci: apertomove.com / Facebook / Twitter