Come Creare Agilità Nei Progetti (con Dimitar Karaivanov di Kanbanize)

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Ci scusiamo per eventuali errori di battitura, dato che il bot non è corretto al 100% delle volte.

Ben Aston:

Lean, Scrum, Scrumban, XP, SAFe, DaD, LeSS, DSDM, Kaizen, Kanban. Suonano familiari? Bene, questi sono solo alcuni dei framework disponibili per implementare l'agilità. Ma qual è il migliore e perché? Continua ad ascoltare questo podcast per capire come puoi creare agilità nei tuoi progetti e i vantaggi di un approccio kanban e del suo kit di strumenti.

Grazie per essere con noi. Sono Ben Aston, fondatore di Digital Project Manager. Benvenuto al podcast DPM. Siamo in missione per aiutare i project manager a raggiungere il successo, per aiutare chi gestisce progetti a ottenere risultati migliori. Siamo qui per aiutarti a portare il tuo modo di gestire i progetti al livello successivo. Visita thedigitalprojectmanager.com per conoscere la nostra formazione e le risorse che offriamo tramite l'abbonamento. Questo podcast è offerto da Clarizen, il leader nel software di gestione dei progetti e portfolio a livello enterprise. Visita clarizen.com per saperne di più.

Oggi sono qui con Dimitar Karaivanov. Dimitar è un ingegnere diventato CEO ed è il co-fondatore di Kanbanize. È un pensatore lean. È un esperto praticante di Kanban. Ha un background nello sviluppo software e nel miglioramento dei processi. Ha scritto un paio di libri: Lean Software Development With Kanban e How Can Portfolio Kanban Benefit Your Business? Penso che tu abbia capito: è appassionato di Kanban. Allora, ciao Dimitar, grazie per essere qui con noi oggi.

Dimitar Karaivanov:

Grazie a te per avermi invitato. È un piacere parlare con te e con il tuo pubblico. Non vedo l’ora di questa chiacchierata.

Ben Aston:

Ci fa davvero piacere averti qui. E ovviamente sei molto appassionato di Kanban e hai costruito un intero prodotto attorno a Kanbanize. Ma nel tuo ruolo di CEO, sono curioso di capire cosa significa davvero questo titolo. Com'è una tua giornata tipo da CEO e co-fondatore di Kanbanize?

Dimitar Karaivanov:

Sì, come CEO dell’azienda, specialmente di una che è in una fase avanzata di startup, si indossano molti cappelli diversi. Quindi tipicamente parlo con molti clienti dato che spesso ricopro anche il ruolo di responsabile prodotto.

Ben Aston:

Chiaro.

Dimitar Karaivanov:

Poi parlo con l’ingegneria per trasmettere i feedback che abbiamo raccolto dai clienti. Mi occupo di vendite aziendali. E naturalmente mi concentro sulla strategia quando il tempo lo consente, perché è un elemento importante del lavoro di un CEO. E tra l’altro, la strategia può essere applicata anche con Kanban. Forse dovremmo trovare qualche minuto per parlarne.

Ben Aston:

Sì, certamente. Ma prima di approfondire, mi piacerebbe sapere di più sulla tua storia. Come mai sei finito a creare software per la gestione dei progetti?

Dimitar Karaivanov:

Succede spesso per necessità. Ero l’agente del cambiamento per una grande azienda tedesca. Stavamo passando da processi a cascata a processi agili e abbiamo spostato circa 500 persone da questo vecchio modo di lavorare ai metodi scrum. In quel periodo, scrum era la norma per qualsiasi nuova implementazione agile. Abbiamo formato tutti su scrum. Avevamo vari team agili, 25 o più, ma scoprimmo che mentre i team riuscivano a consegnare in modo continuo, a livello manageriale, dove c’erano le grandi attività (feature, epic, ecc), era un gran caos. Ci rendemmo conto che ci mancavano gli strumenti per gestire sia il livello dei team che il livello di coordinamento e management. Ed è così che è nata Kanbanize: per scalare agile in tutta l’organizzazione.

Ben Aston:

Interessante. Iniziare a creare uno strumento PM per la prima volta... Avrai preso ispirazione sia da strumenti che ti piacevano che da altri che non ti piacevano, al punto da voler farne uno tuo. Da dove è arrivata quella scintilla iniziale di ispirazione?

Dimitar Karaivanov:

Usavamo JIRA in quell’azienda. Il colosso da 300 kg che trovi ovunque. Ha delle cose interessanti, ma quella parte centrale – soprattutto 8 o 9 anni fa – mancava completamente o era molto limitata. Quindi, pur avendo molti buoni concetti, la vera ispirazione su come scalare Kanban e agile in azienda venne più da una bacheca fisica Kanban. Quello che abbiamo fatto con Kanbanize è stato cercare di imitare la visualizzazione del lavoro su una lavagna fisica, con il grande vantaggio di essere digitale, di poterla collegare a molti altri team e di aggregare i dati per consentire ai manager di prendere decisioni informate. Quindi la risposta è: entrambi – JIRA e tabelloni Kanban fisici.

Ben Aston:

Già. E ovviamente sviluppate il vostro tool di project management, ma vorrei sapere con quali altri strumenti Kanbanize si integra o che utilizzate parallelamente per gestire la vostra azienda o che avete trovato interessanti o utili.

Dimitar Karaivanov:

Non posso non menzionare Microsoft Teams perché penso che sia l’applicazione che cresce più velocemente nella storia di Internet. La usiamo insieme a Kanbanize. Passo molto tempo su Teams, specialmente ora che lavoriamo tutti da remoto. E poi passo mezza giornata su uno strumento chiamato Flow-e. È flow-e.com e sorprendentemente è uno strumento della nostra azienda. È Kanbanize ma per la tua mail: uno strato visuale sopra la tua posta di Outlook che trasforma la posta in arrivo in una Kanban board dove visualizzare le mail e gestire le conversazioni. Questo mi salva la vita. Letteralmente non potrei lavorare senza questo strumento, lo raccomando. È gratuito quindi chiunque può provarlo.

Ben Aston:

Proverò! Anche io vedo adesso la mia inbox: 1189 email non lette. Capirai se non ho ancora risposto... finiranno nella mia colonna "da leggere".

Dimitar Karaivanov:

Eh sì, è proprio per quello che abbiamo inventato Flow-e! Era troppo difficile gestire tutti i flussi di informazioni. Lo consiglio vivamente.

Ben Aston:

Bene, allora parliamo di Kanbanize. Sei il CEO, è stata una tua idea nata insieme al team. Ma ci hai dato già un’infarinatura su che azienda siete. Kanbanize è quindi una kanban board digitale che, essendo digitale, offre migliore prevedibilità, ci dà analytics, dati e regole che si possono applicare. Ma secondo te, qual è il cliente tipo a cui Kanbanize si adatta meglio? Chi usate il vostro strumento?

Dimitar Karaivanov:

Siamo specificamente pensati per aziende di ingegneria: può essere ingegneria software, IT/dev operations ma anche ingegneria non IT come manifattura, costruzioni, ecc. Abbiamo molti clienti di successo nell’ambito ingegneristico, ma anche team marketing, operation (come banche/assicurazioni) lo utilizzano con ottimi risultati. I due casi principali sono quindi project management (nel settore ingegneristico) e service management (per banche, assicurazioni). Questi sono i clienti ideali. Se vuoi, posso approfondire l’aspetto project management e il contributo specifico di Kanbanize.

Ben Aston:

Certo, vai pure.

Dimitar Karaivanov:

La vera sfida, dalla mia esperienza, è che i responsabili di progetto tendono a pianificare e stimare i progetti, e poi questo piano viene convertito in task o work item che vivono in un altro sistema. Abbiamo quindi un piano perfetto su PowerPoint o su Microsoft Project, poi l’operatività vera e propria è su JIRA o altrove.

Ben Aston:

Esattamente.

Dimitar Karaivanov:

E come si ottengono informazioni sullo stato reale? Non c’è altra soluzione che chiedere personalmente gli aggiornamenti.

Ben Aston:

Già.

Dimitar Karaivanov:

E continuare a chiedere alle persone: quanto manca per completare questo task? Qual è la percentuale di avanzamento? Così abbiamo detto: "risolviamolo con Kanban e in particolare con Kanbanize collegando la pianificazione all’esecuzione". In Kanbanize abbiamo uno strato dove si pianifica il lavoro e uno dove lo si esegue, ma i due sono collegati e si scambiano feedback. Quando un team inizia a lavorare su qualcosa, le informazioni si propagano automaticamente al livello manageriale dove c’è il piano. Se si scopre che il piano sta per fallire, Kanbanize notifica il project manager che così potrà agire subito invece di aspettare una settimana e poi scoprire che si è in ritardo. È molto comodo.

Ben Aston:

Ricevi la notifica: il tuo progetto sta per fallire. Un messaggio gentile che tutti temono. Sta arrivando il disastro... Sì, interessante. Ma il punto chiave sono le persone nel team: la sfida con qualsiasi strumento è che è buono solo se chi lavora aggiorna continuamente le schede e tiene traccia del tempo. Ma – per esperienza – spesso si dimentica di aggiornare task e stati. Come avete pensato in Kanbanize di stimolare l’aggiornamento in tempo reale?

Dimitar Karaivanov:

Hai ragione. Il modo per risolvere è proprio affidarsi al metodo kanban, che è ben più di una bacheca: esiste il Kanban Maturity Model che codifica più di 150 pratiche comuni. Se interessa, cercate il KMM, Kanban Maturity Model, per capire cosa significa una implementazione kanban matura. Detto ciò, un elemento fondamentale del metodo sono i feedback loop: riunioni regolari (giornaliere, settimanali, mensili). Una di queste è la daily stand-up, in cui il team si riunisce davanti alla board.

Se è digitale, si può avere un grande schermo con la board visualizzata. Si passa rapidamente sulle card in corso e si discutono i progressi. Non si parla della persona ma del lavoro: questa card è aggiornata, è nella posizione giusta? Così almeno una volta al giorno tutto si aggiorna correttamente.

Ben Aston:

Molto interessante anche il focus sul lavoro piuttosto che sulla persona. Capita spesso che negli standup le persone dicano sempre la stessa cosa (realizzata ieri, ancora quella oggi), senza fornire reali informazioni. Quindi concentrarsi sul lavoro aiuta tantissimo. Parlando invece delle differenze tra Kanbanize e altri strumenti come Trello o JIRA?

Dimitar Karaivanov:

Ritorno al KMM. Il Kanban Maturity Model descrive sei livelli di maturità, e ogni livello richiede pratiche differenti – dalle più semplici alle più complesse. Strumenti come Trello arrivano fino al livello 1 o 2, perché mancano le funzioni necessarie per una vera implementazione kanban. Ad esempio, in Trello mancano completamente i limiti di lavoro in corso (work in progress limit), mentre in Kanbanize puoi impostare limiti per colonne, swimlane, board e persone.

Anche per quanto riguarda le metriche, in Trello non si ottengono di default le metriche di flusso indispensabili (come curva dei tempi di ciclo, simulazioni Monte Carlo per forecast basato sul throughput storico, ecc). Spesso occorrono costosi plugin che raramente funzionano bene. In sintesi, Kanbanize è nato per gestire scenari kanban avanzati, anche in ottica di scalabilità aziendale. Trello è ottimo per un singolo team, ma oltre quello diventa complicato, mentre JIRA – anche se consente la scalabilità – si basa molto di più su scrum e non sulla vera raccolta dati kanban. Con JIRA si prevede in funzione della velocità storica, in Kanban si prevede in funzione del throughput reale. È una piccola ma fondamentale differenza. Se vuoi scalare a 20, 30 o 40 team te ne accorgi subito: ogni team interpreta i punti diversamente e la normalizzazione è un incubo. In kanban si prevede su ciò che è avvenuto realmente. Questo è un punto cruciale.

Ben Aston:

Prendendo una visione d’insieme, quindi, l’idea di fondo del Kanban è aumentare il throughput minimizzando le cose in corso. Limitare il lavoro in corso (work in progress) aiuta le persone a concentrarsi e a finire davvero le cose." Piuttosto che lavorare su sei attività diverse, meglio completarene una e passarvi.

Dimitar Karaivanov:

Giusto! C’è solo una cosa da aggiungere: se limitiamo troppo il lavoro in corso, si può compromettere il throughput. Si tratta di trovare il giusto equilibrio fra velocità ed efficienza. La domanda classica è: qual è il limite di lavoro in corso ottimale? La risposta è sempre: non lo sappiamo, dipende dal contesto. Bisogna sperimentare, raccolgiere i dati, controllarli settimanalmente e vedere se il throughput è soddisfacente.

Ben Aston:

Molto utile. E guardando avanti, come evolverà Kanbanize? Qual è la vostra roadmap, dove vedi Kanbanize tra cinque o dieci anni?

Dimitar Karaivanov:

Cinque o dieci anni sono un tempo lunghissimo, ma—

Ben Aston:

Anche solo 6 settimane?

Dimitar Karaivanov:

Sei settimane? Ok! Stiamo andando sempre più nella direzione di alleggerire il project manager dalle decisioni operative, per permettergli di concentrarsi sul vero valore e non sul monitoraggio continuo. L’idea è che la piattaforma si occupi autonomamente di monitoraggio e notifiche, introducendo algoritmi statistici – magari intelligenza artificiale. Anche se diffido del termine "AI": negli scenari di kanban, spesso algoritmi statistici (come le simulazioni Monte Carlo) sono più precisi dei modelli attuali di AI. Ma senza dubbio il futuro va in questa direzione: scaricare tutto il monitoraggio sull'automazione e lasciare ai PM la parte di valore, non i report.

Ben Aston:

Parlando del ruolo dei project manager, come vedi cambiare la loro funzione man mano che strumenti come Kanbanize automatizzano forecast e monitoraggio? Come immagini l’evoluzione della figura del PM?

Dimitar Karaivanov:

Penso che il project manager dovrebbe sempre più essere l’interfaccia non solo di dati e comunicazione, ma aggiungere valore verificando se ciò che si sta costruendo è corretto – porsi domande critiche. Molti PM oggi si limitano a trascrivere i requisiti e passarli agli sviluppatori. Va bene, ma manca la parte più importante, cioè ascoltare davvero i bisogni del cliente, interrogarsi costantemente su quello che si produce, non solo su ritardi, timesheet o budget. Quando la parte amministrativa e di reportistica è automatizzata, resta più tempo alle domande “core” del valore.

Ben Aston:

Sono d’accordo. E come vedi cambiare invece il panorama degli strumenti di PM in generale? Tantissima concorrenza, c’è JIRA che ha assorbito Trello, tool all-in-one come ClickUp… voi come vi differenziate in questo scenario in evoluzione?

Dimitar Karaivanov:

Ci sono tantissimi strumenti, specialmente per la gestione di piccoli team – una concorrenza spietata. Kanbanize però vuole essere non solo una soluzione per il team, ma per la gestione agile di portfolio. Parte della funzionalità già c’è; chiudere il cerchio è un lavoro enorme e ci vorranno anni. In quell’area (gestione portfolio agile) esistono “Godzilla” che si basano su scrum. Ma il futuro – forse sono di parte – è costruire infrastrutture informative che collegano i team al top management, per prendere decisioni su cosa accade davvero, non su ipotesi. In breve, il mercato si consolida attorno ai concetti di scalabilità. I piccoli tool di team continueranno ad emergere e sparire. Ma chi risolverà davvero l’agilità su vasta scala avrà la meglio.

Ben Aston:

A proposito hai scritto un articolo – Kanban Powered Business Agility – che offre tanti spunti sull’implementazione kanban. Ma partiamo dal concetto: cosa significa “business agility” per te?

Dimitar Karaivanov:

Per me business agility è la capacità di soddisfare il mercato tramite rapidi cicli di apprendimento, sperimentazione e applicazione. Non è un framework o una sigla da vantare, è la capacità di imparare rapidamente e usare le nuove conoscenze per creare valore ai clienti.

Ben Aston:

Ovviamente sei promotore di Kanbanize e Kanban. Poco fa confrontavi Kanban e Scrum: perché hai puntato su Kanban per la business agility? Quali sono i suoi pregi e gli eventuali limiti?

Dimitar Karaivanov:

Bella domanda! Tutto ruota attorno a uno dei principi del kanban: partire da dove sei e poi evolvere sperimentalmente. Non conosco altri metodi che propongano "inizia da ciò che già fai e poi migliora", solitamente bisogna fare grossi salti evolutivi. Kanban invece dice: visualizza ciò che già accade, poi chiediti come migliorare. È un approccio umano all’agilità perché non crea stress all’organizzazione inizialmente: si rema con la corrente, si implementano cambiamenti evolutivi che vengono accettati. E quando fatto bene, riduce lo stress e il sovraccarico, aiuta le persone a focalizzarsi su poche cose per volta senza affogare negli imprevisti. Il limite principale è che spesso si pensa che sia solo una bacheca visuale, ma in realtà kanban è una vasta conoscenza: ci sono molti libri, vale la pena studiarlo. È molto di più!

Ben Aston:

Ma in qualche modo il fatto che molti conoscano il kanban (almeno a livello superficiale) è positivo: è molto più facile presentare kanban rispetto a scrum, che invece prevede cerimonie, backlog e molto altro. Kanban permette un ingresso molto più leggero nel mondo agile rispetto ad altri framework che richiedono rivoluzioni organizzative.

Dimitar Karaivanov:

Sì, è un approccio più ragionevole: se entri in un’azienda e proponi subito di cambiare tutto senza capirne il contesto, può essere arrogante. Se hanno già successo avranno una base di conoscenza consolidata; cancellarla con un nuovo framework sarebbe un errore. Meglio osservare e migliorare.

Ben Aston:

Nel tuo articolo parli anche di "raffinamento del flusso di lavoro". È facile a dirsi, ma come avviene concretamente?

Dimitar Karaivanov:

Anche qui si parte visualizzando il lavoro su una board. Se sei diligente vedrai – nel tempo – accumularsi le card in qualche punto. Quel punto è un probabile collo di bottiglia. Se le card si infittiscono in una colonna, il problema è lì: o la fase è troppo lenta, o la precedente troppo veloce. Analizza il motivo, eventualmente aggiungi nuove colonne (“pronto per review”, per esempio) per isolare i colli di bottiglia. Puoi anche impostare limiti di lavoro in corso su queste colonne: se si satura, la colonna prima smette di produrre e va ad aiutare il collo di bottiglia. Questo ragionamento si itera, costantemente.

Ben Aston:

L’obiettivo è ridurre i colli di bottiglia. Solo quando il lavoro è completato si genera vero valore.

Dimitar Karaivanov:

Corretto. Si monitora il "cycle time" – il tempo che le card impiegano per chiudersi – e se si allunga probabilmente significa che si sta accumulando troppo lavoro. Bisogna quindi raffinare il workflow e limitare i colli di bottiglia.

Ben Aston:

Un altro dei tuoi consigli riguarda il passaggio da “Highest Paid Person’s Opinion” a “Highest Probability Option”: cioè basarsi sui dati nelle decisioni, non sull’opinione di chi è più "importante". Da CEO, come comunichi questa cultura?

Dimitar Karaivanov:

Non è facile. Ho fatto molti errori prima di impararlo. Quando qualcuno prende decisioni solo di pancia senza dati, lo sfido subito a riflettere su come è arrivato a quella conclusione. È umano voler avere ragione, sono molto opinioniato io stesso e spesso nei confronti vingo io (soprattutto se sono il CEO). Ma quando arrivano i dati, l’argomentazione cambia radicalmente. Quindi continuo a ripetere al mio team che le decisioni devono essere data-driven, non “opinion-driven”. Serve molta persistenza nel richiedere dati e, nel tempo, questa attitudine si diffonde in azienda.

Ben Aston:

Per concludere, il tuo articolo parla di business agility e dei benefici del kanban per raggiungerla. Se qualcuno volesse iniziare con kanban e diventare più agile, quali sono i primi passi?

Dimitar Karaivanov:

Direi che ci sono due o tre cose fondamentali. La prima è visualizzare il lavoro: chiunque può farlo, anche semplicemente con dei post-it e una lavagna. Non ci sono scuse. Ovviamente, solo se c’è una po’ di insoddisfazione e si vuole migliorare. Il secondo passo: limitare il lavoro in corso. Anche solo partendo dalla situazione attuale, ponendo il limite al numero attuale di progetti. Poi si cerca via via di abbassare il limite per migliorare i risultati. Il terzo consiglio, che potrebbe anche essere il primo: seguire una formazione kanban di qualità, magari presso Kanban University (che certifica formatori a livello mondiale). Potrebbe essere costoso per tutti, ma almeno alcune figure chiave meritano questa formazione formale.

Ben Aston:

Concordo: mappare il flusso reale con il team è un ottimo esercizio e aiuta a far emergere punti di vista diversi sul processo e sui potenziali colli di bottiglia. Solo dopo si può pensare a limitare il wip per incrementare il throughput. Grazie Dimitar, sei stato preziosissimo. Se volete approfondire Kanbanize, visitate kanbanize.com – metteremo il link nelle note. Grazie mille per essere stato con noi.

Dimitar Karaivanov:

Grazie a te, Ben, è stato un piacere. Mi sono molto divertito, continuiamo così.

Ben Aston:

Se vuoi approfondire e lavorare meglio, unisciti al nostro gruppo con l’abbonamento DPM: thedigitalprojectmanager.com/membership per accedere a template, workshop, sessioni AMA, office hour, ebook e tanto altro. E se ti è piaciuta la puntata, iscriviti e resta aggiornato su thedigitalprojectmanager.com. Alla prossima, grazie mille.