Maggio, 2024 | Il Project Management & l'arte della Maratona

Migliora il tuo Project Management con Kanban: il Kanban Project, Programme e Portfolio Management

Il metodo Kanban ha avuto, fin dalle sue origini, i progetti nel proprio perimetro di applicazione. Nato per gestire i flussi di lavoro dei team IT, il metodo Kanban è stato da subito applicato anche per gestire il lavoro degli stessi team IT quando questi sono impegnati in un progetto.

A partire dagli informatici, la comunità dei project manager si è quindi sempre più interessata al metodo Kanban. Ho già citato in un precedente articolo l’intervento di David J Anderson, creatore del metodo Kanban, al PMI Poland Chapter Congress 2013. Successivamente il metodo Kanban è stato via via menzionato in varie pubblicazioni di project management. Il manuale PRINCE2 Agile del 2015 fa riferimento esplicitamente al metodo Kanban tra le tecniche di product delivery (dedicandogli un capitolo ben fatto) la guida al PMBoK 6th Ed. del 2017 lo cita brevemente (un paragrafo) tra le tecniche di schedulazione, la guida al PMBoK 7th Ed. del 2021 lo cita più diffusamente rispetto alla precedente seppure in modo poco organico.

Teodora Bozheva, co-autrice insieme a David J Anderson del Kanban Maturity Model (KMM) ha ribaltato questa visione residuale e pubblicato nel 2023 una guida specifica dal titolo KPPM – Kanban Project, Programme e Portfolio Management – A map to business agility: il metodo Kanban non più visto all’interno di un progetto come semplice modalità di gestione operativa del delivery, ma più propriamente come leva strategica per supportare una migliore gestione non solo dei progetti aziendali, ma anche dei programmi e del portfolio aziendale di programmi e progetti.

Riassumo qui di seguito i concetti principali che stanno alla base del Kanban Project, Programme e Portfolio Management, tratti dal libro.

Il pensiero fondativo del Kanban Project, Programme e Portfolio Management (KPPM)

Il KPPM adotta un approccio scientifico e orientato al problem-solving per la gestione del lavoro di progetto e affronta le sfide reali delle organizzazioni di progetto.
Il KPPM si basa su tre elementi fondamentali:

Systems thinking (pensiero sistemico)
Flow thinking (pensiero sulla gestione dei flussi)
Sviluppo di una cultura collaborativa e purpose-driven

Le conoscenze alla base di questi concetti esistono da decenni anche se sono poco conosciuti e applicati nelle aziende di servizi. Il pensiero sistemico in Kanban si basa sulle opere di W. Edwards Deming, Russell Ackoff, Peter M. Senge, Donella Meadows e altri.
Il pensiero sulla gestione dei flussi fa riferimento alla Teoria dei Vincoli (TOC) di Eliyahu Goldratt, a Principles of Product Development Flow di Donald Reinertsen, al Toyota Procution System e al Lean Thinking. L’applicazione di questi concetti all’interno del metodo Kanban hanno portato allo sviluppo del Kanban Maturity Model (KMM) che definisce un insieme di valori culturali e pratiche che aiutano a migliorare i risultati di un’organizzazione in modo evolutivo.

Il KPPM amplia e adatta alle organizzazioni di progetto il Kanban Maturity Model (KMM).
Il KPPM non è un nuovo metodo di gestione dei progetti. Descrive pratiche che affrontano le sfide croniche della gestione dei progetti, programmi e portfolio e che integrano le conoscenze e i metodi esistenti in materia di project management. Il modello può essere applicato anche in combinazione con metodi Agili, quale ad esempio Scrum.

Systems thinking (pensiero sistemico)

Il Systems Thinking è un modo di vedere un’organizzazione come un sistema di parti interconnesse e di comprendere i suoi comportamenti e risultati come prodotto delle interazioni tra le parti.

I risultati che un’azienda ottiene dipendono dalle azioni congiunte delle sue unità aziendali. Risposte adeguate a circostanze sfidanti possono generare un vantaggio aziendale. Decisioni inadeguate su una buona opportunità potrebbero sprecarla.

Il miglioramento dei risultati di un’organizzazione richiede la focalizzazione su obiettivi comuni, comunicazione e sincronizzazione puntuale, rapidità decisionale e capacità di adattamento. Senza la comprensione dello scopo, le azioni di miglioramento diventano prive di significato e comportano uno spreco di tempo, energia e investimenti. Allo stesso modo, senza la comprensione di come le interazioni tra le unità dell’organizzazione influiscono sui risultati, non è possibile identificare la causa principale dei problemi attuali e proporre un trattamento adeguato che la risolva.

Il Systems Thinking aiuta a prendere decisioni informate che risolvono i problemi dell’organizzazione a partire dalle cause principali e migliorano i risultati complessivi. I manager iniziano a prendere decisioni informate basate sulla comprensione dell’azienda come sistema e sui dati.

Flow thinking (pensiero sulla gestione dei flussi)

La gestione del lavoro con i sistemi kanban consiste nel creare un flusso di lavoro stabile e controllato attraverso un sistema a capacità finita.

Deve esserci una giusta corrispondenza tra i flussi di lavoro, i materiali (o le forniture), le operation, la comunicazione con i clienti e i fornitori per sviluppare e consegnare con successo i risultati dei progetti. Una kanban board deve visualizzare chiaramente lo stato del lavoro in corso (WIP – Work in Progress) e di quello in attesa di essere iniziato. Sia i sistemi sovraccarichi che quelli sottoutilizzati producono risultati non ottimali. In condizioni di forte pressione e stress, gli individui perdono tempo nel multitasking e commettono errori. La loro capacità di consegna e la qualità del prodotto e del servizio peggiorano. I progetti cominciano a ritardare, aumentano i costi e peggiorano la soddisfazione dei clienti e degli stakeholder.

Per migliorare i risultati complessivi dei progetti, le organizzazioni devono utilizzare la loro capacità in modo opportuno. Dare priorità e selezionare un numero sufficiente di progetti da far passare attraverso il sistema garantisce una gestione ben focalizzata e un alto morale dello staff. Per lo stesso motivo, i problemi che bloccano il flusso di lavoro del progetto a causa di informazioni mancanti, attese o rilavorazioni, devono essere risolti il prima possibile.

Creare e sostenere un flusso di lavoro stabile coinvolge tutte le persone dell’organizzazione e richiede la cooperazione con clienti e fornitori. Allo stesso tempo, la creazione di un flusso è vantaggiosa per tutti i livelli dell’organizzazione. A livello operativo, le persone godono di un lavoro focalizzato e di un carico adeguato. I project manager sfruttano i dati di flusso per migliorare la prevedibilità e rispettare con sicurezza le scadenze importanti. I responsabili aziendali apprezzano l’aumento della produttività e dei risultati ottenuti, nonché la maggiore capacità dell’organizzazione di stabilire le priorità e di adattarsi ai cambiamenti del contesto aziendale.

La soluzione è quindi migliorare il flusso dei progetti attraverso una gestione accurata della capacità disponibile piuttosto che espandendo il sistema. Migliorare attraverso processi efficienti è molto più conveniente che cercare nuove persone e investire in strutture e attrezzature.

Sviluppo di una cultura collaborativa e purpose-driven

La cultura è una questione di valori condivisi e di modi di pensare, decidere e comportarsi. I valori e gli obiettivi comuni consentono l’introduzione di pratiche e norme appropriate. La giusta combinazione di principi e pratiche pertinenti porta al raggiungimento di risultati migliori.

Le pratiche semplici che migliorano l’adattabilità delle persone rafforzano le loro abitudini e la motivazione a continuare a migliorare. La padronanza di nuovi modi di lavorare incoraggia nuovi comportamenti. Le pratiche KPPM impegnano le persone a promuovere una cultura di collaborazione, focalizzazione su un obiettivo comune, apprendimento continuo e adattamento.

Panoramica del Kanban Project, Programme e Portfolio Management (KPPM)

Il KPPM comprende un insieme di Principi, Pratiche e Valori culturali che aiutano le organizzazioni a e a prosperare in un ambiente di business mutevole e incerto.

Principi del KPPM

I principi del KPPM definiscono le basi del pensiero, del comportamento e dell’azione in una organizzazione adattiva.

Visibilità Pensare in maniera olistica e visualizzare il lavoro, le informazioni sullo stato del lavoro e altri dati necessari per prendere le decisioni a tutti i livelli dell’organizzazione.
Focus Focalizzare le azioni sulle richieste del cliente e sul purpose del business.
Flusso del valore continuo e bilanciato Creare un flusso continuo e bilanciato di risultati per gestire efficacemente anche il bilanciamento tra richieste del cliente, priorità, rischi e la capacità del sistema di produrre valore.
Feedback rapidi Implementare cicli di feedback rapidi sia all’interno dell’organizzazione, che con clienti, fornitori e mercato, per mantenere sincronizzato il sistema aziendale di creazione del valore.
Cultura collaborativa e purpose-driven Coltivare una cultura della trasparenza, della collaborazione, del pensiero orientato ai risultati e dell’adattamento continuo.

Struttura del KPPM

Il KPPM estende il Kanban Maturity Model (KMM) con ulteriori idee che sono state adattate dalla Teoria dei Vincoli (TOC) e da Lean, e adatta le pratiche del KMM per rispondere alle esigenze delle organizzazioni di progetto.

Livelli evolutivi

Il KPPM è suddiviso su quattro livelli evolutivi:

EL1 Team-Focused I team sono autonomi ma non sincronizzati.
EL2 Customer-Driven I team sono sincronizzati in un flusso end-to-end di progetto.
EL3 Oucome-Driven Tutti gli obiettivi del delivery system vengono continuamente raggiunti attraverso un flusso bilanciato e sostenibile
EL4 High Performing Risultati aziendali di rilievo grazie alla cultura dell’eccellenza e del miglioramento continuo

Pratiche

Le organizzazioni di progetto devono pianificare il lavoro, monitorare l’esecuzione di progetti, programmi e portfolio (incluso quello strategico), apprendere e adattarsi ai cambiamenti e misurare i propri risultati.

A supporto di queste attività il KPPM definisce quattro gruppi di pratiche:

Plan 9 pratiche basate sulle pratiche generali Kanban Visualizza e Gestisci il Flusso
Communicate and align 45 pratiche basate sulle pratiche generali Kanban Visualizza, Implementa Cicli di Feedback ed Esplicita le Policy
Monitor and adjust 24 pratiche basate sulle pratiche generali Kanban Visualizza, Gestisci il Flusso ed Esplicita le Policy
Learn and adapt 9 pratiche basate sulla pratica generale Kanban Migliora Collaborando, Evolvi Sperimentando

Valori culturali

I valori culturali promossi dal KPPM, suddivisi per livello evolutivo, sono:

EL1 Team-Focused
- Transparenza
- Collaborazione
- Prendere iniziativa
EL2 Customer-Driven
- Coordinamento tra team di specialisti e fornitori
- Atti di leadership
- Rispetto
- Fiducia
- Cambiamento evolutivo
EL3 Oucome-Driven
- Fitness for Purpose
- Leadership a tutti i livelli
- Accordo e comprensione comune
- Unità e allineamento
- Bilanciamento
- Servizio al cliente
- Risultati e conquiste di breve termine
- Apprendimento sperimentale
EL4 High Performing
- Capacità di anticipare piuttosto che di reagire
- Capacità di migliorare continuamente
- Equità
- Sviluppo della leadeship

Conclusione

Lo sviluppo dell’agilità organizzativa, anche nella gestione di progetti, programmi e portfolio, è un percorso da far progredire nel tempo. Gradualmente coinvolge tutto il personale dell’azienda nella revisione e adattamento dei processi organizzativi e delle policy, in modo tale che l’azienda possa adattarsi e avere successo nell’attuale ambiente di business mutevole. Il metodo Kanban e il KPPM possono supportare efficacemente questo percorso.

Prossimamente pubblicherò su questo blog alcuni brevi casi pratici esemplificativi di applicazione del KPPM a progetti aziendali ai quali ho patecipato.

Bibliografia:
Teodora Bozheva | KPPM – Kanban Project, Programme e Portfolio Management – A map to business agility
David J Anderson – Teodora Bozheva | Kanban Maturity Model (2nd Edition) | Kanban University Press

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

Migliora il tuo Project Management con Kanban: il project manager come risk manager invece che come pompiere

Riporto in questo articolo uno stralcio del testo (la traduzione è mia) di quanto detto da David J Anderson, creatore del metodo Kanban, in una breve intervista al termine del PMI Poland Chapter Congress 2013 (trovate il link al video originale più sotto). Il video è di dieci anni fa ma il messaggio è sempre attuale e davvero importante per chi svolge il ruolo di project manager: il project manager è un risk manager e non un pompiere.

Il project manager come risk manager

“David, potresti dirmi che cosa i partecipanti dovrebbero ricordare dopo il tuo intervento?”

“Credo che il principale messaggio del mio intervento sia stato che i project manager passano troppo tempo su attività prettamente amministrative, attività di segreteria per organizzare riunioni, programmare il lavoro di persone, coordinare, raccogliere informazioni, diffondere le informazioni, comunicare, mentre quando non fanno questo la loro attività è spengere gli incendi e hanno l’immagine di sé del tipo: “Sono un eroe, sono il pompiere e non funzionerebbe nulla senza la mia presenza”.
Mi piacerebbe invece che si reinventassero come Risk Manager per le loro aziende e quello che abbiamo fatto con i sistemi Kanban è stato rendere il service delivery e le organizzazioni di knowledge worker (c.d. ‘lavoratori della conoscenza’, ovvero attivi in professioni intellettuali, quale ad esempio l’informatica – n.d.t.) molto più prevedibili, affidabili, attendibili e degne di fiducia.

Quindi, se il project manager può fidarsi si tutto quello che succede e (il progetto – n.d.t.) ha trasparenza e visibilità, molto del lavoro di segreteria si riduce e i fuochi non bruciano più. E però spesso i project manager si fermano a questo punto: “e adesso cosa faccio?! Tutto il mio lavoro è reso inutile da questa cosa del Kanban!”
E invece io vorrei che passasse il messaggio che ci sono molte, ma molte più opportunità di portare davvero valore aggiunto alle loro organizzazioni se gestiscono meglio i rischi”.

Link al video originale su YouTube: https://youtu.be/vMOg7IFfXtE?si=cJciHWYk8oulll3L

Migliora il tuo Project Management con Kanban: A Kanban-like system successfully implemented at Doxee in 2010-2012 (case study in inglese)

Questa è la storia di un’azienda tecnologica italiana che per la gestione dei propri progetti ha applicato PRINCE2 a partire da un approccio waterfall e successivamente, per migliorarne l’efficacia, ha sviluppato un’applicazione originale dei principi e del modo di lavorare lean. Perché lean e Kanban possono migliorare l’applicazione di PRINCE2.

Vista in retrospettiva dal punto di vista del Kanban Maturity Model (KMM – Modello di Maturità Kanban), questa è la storia di un percorso evolutivo verso l’agilità organizzativa che si è sviluppato nell’arco di un decennio da Team-Focused (livello di maturità 1) a Risk-Hedged (livello di maturità 4) e oltre, con la maggior parte dei principi e delle pratiche del Metodo Kanban che oggi si possono rintracciare in tutta l’organizzazione.

Questa è la storia di una prova provata che il metodo Kanban funziona!

Il sistema di Rolling Forecast applicato inizialmente per gestire la schedulazione

Il Case Study analizza come si è giunti ai seguenti miglioramenti del delivery e del project management di Doxee, a fronte di un carico di lavoro che nel 2023 è dieci volte superiore a quello del 2012:

ogni attività di lavoro è sotto controllo
la prevedibilità complessiva del delivery ha raggiunto un grado di confidenza e un livello di servizio superiore al 90%
gli extra costi di progetto imputabili ai team si sono azzerati
tutte le richieste di cambiamento al progetto provenienti dai clienti sono identificate e gestite tempestivamente

Leggi il case study sul sito Kanban+ della Kanban University

Pillole di Kanban applicato: domande e risposte con la spiegazione della terminologia che utilizziamo

Nei precedenti articoli ho illustrato alcuni esempi di applicazione del metodo Kanban, facendo riferimento ad alcuni concetti tipici del metodo. Penso che possa essere utile per chi si approccia per la prima volta a Kanban e non ne conosce i tecnicismi, una spiegazione della terminologia che utilizziamo. Nel seguito ho quindi provato a spiegare brevemente alcuni concetti basilari per l’applicazione del metodo Kanban:

lead time
distribuzione di probabilità
aspettative del cliente rispetto alla data di consegna desiderata
costo del ritardo
classe di servizio

Che cos’è il lead time?

Definiamo il lead time come un tempo che inizia dal commitment point concordato (momento in cui ci impegniamo a fare un lavoro) e continua fino a quando l’elemento di lavoro è pronto per la consegna. In altre parole, iniziamo a contare il lead time dal momento in cui il cliente può legittimamente aspettarsi che noi lavoriamo sul prodotto, fino a quando noi possiamo legittimamente aspettarci di consegnarlo al cliente. Qualsiasi ulteriore attesa al momento della consegna non viene conteggiata. Questa definizione non è ambigua e funziona in modo coerente per qualsiasi flusso di lavoro e servizio.

In base agli studi sul Modello di Maturità di Kanban, dovremmo tuttavia riconoscere che questa definizione funziona in modo affidabile a livello di maturità 3 e oltre, mentre a livelli di maturità inferiori è problematica. A livelli di maturità inferiori, il punto di commitment è spesso ambiguo e, nel migliore dei casi, asincrono, cioè il cliente fa una richiesta prima che ci sia l’effettivo commitment a svolgere il lavoro. In questo caso di commitment asincrono misuriamo il lead time a partire dal secondo punto di commitment, dal momento in cui il lavoro da fare viene inserito nel flusso di lavoro ed entra a fare parte del WIP (Work In Progress – lavoro in corso). Spesso nei flussi di lavoro di livello di maturità 2 non esiste un concetto forte di commitment e quindi si tende a misurare il lead time dal momento in cui un elemento di lavoro viene richiesto.

Il termine “lead time” significa quindi: “Se si sa quando si deve consegnare il prodotto, il lead time è la quantità di tempo di cui si ha bisogno in anticipo per effettuare un ordine e aspettarsi la consegna il giorno o prima di quando si ha bisogno dell’elemento di lavoro richiesto”, o semplicemente, il periodo di tempo in cui il commitment deve precedere la consegna.

Che cos’è la distribuzione di probabilità?

La funzione di densità di probabilità del lead time (probability density function – PDF) è una curva che mostra la distribuzione dei dati effettivi del lead time di un sistema Kanban. Viene rappresentata su un grafico in cui l’asse orizzontale delle ascisse mostra il numero di giorni di lead time, mentre l’asse verticale delle ordinate mostra il numero di occorrenze di tale tempo all’interno dell’insieme di dati campione (il numero di elementi di lavoro passati attraverso il sistema Kanban). La funzione di densità di probabilità del lead time tipicamente assume due forme di distribuzione:

Distribuzione a coda grassa (Fat-tailed)

Scarsa prevedibilità, impatto potenzialmente elevato da ritardi prolungati.

Distribuzione a coda sottile (Thin-tailed)

Buona prevedibilità, basso impatto, ritardi più brevi

L’esempio in alto proviene da un gruppo di IT Operations e quello in basso da un team di sviluppo di prodotti software. Quello in alto si dice che sia “a coda grassa”: c’è una lunga coda visibile che si estende a destra lungo l’asse delle ascisse. In generale, la “coda grassa” è indesiderabile, rischiosa e rende difficile la pianificazione. Quello a destra è detto “a coda sottile”: non c’è una lunga coda visibile che si estende a destra lungo l’asse delle ascisse. Questa convenzione di denominazione può sembrare controintuitiva per i non matematici. La verità è che, dal punto di vista matematico, queste code corrono all’infinito. Quindi, se la coda è visibile, deve essere grassa. Una coda sottile è di fatto invisibile lungo l’asse delle ascisse.

I concetti di distribuzione del lead time con coda grassa e con coda sottile sono molto importanti e sapere quale dei due è presente nel vostro sistema Kanban, fa una differenza fondamentale per la pianificazione, la gestione del rischio e la probabilità di ottenere la soddisfazione del cliente e di essere considerati un fornitore di servizi affidabile.
In assenza di dati sulla distribuzione di probabilità dell’elemento di lavoro, si consiglia di assumere una distribuzione a coda grassa. È importante ricordare questo semplice mantra: “il rischio è sempre nella coda”. Le distribuzioni a coda grassa richiedono un approccio diverso alla gestione del rischio.

Quali possono essere le aspettative del vostro cliente rispetto alla data di consegna desiderata?

“Non importa“. I vostri clienti sono indifferenti alla data di consegna e non si preoccupano? La data è puramente consultiva o non esiste una data specifica, ma è stata semplicemente indicata perché richiesto ? Potremmo dire che non importa quando il prodotto viene consegnato, purché alla fine venga consegnato? Se è così, l’aspettativa del cliente è “Non importa”.

Entro lo SLA. Esiste uno SLA/SLE con il cliente e quindi, se iniziamo una lavorazione, c’è l’aspettativa che la consegniamo entro quel tempo? Se sì, l’aspettativa del cliente è “Entro lo SLA”.

Scadenza. La data di consegna desiderata è accompagnata dall’indicazione di una scadenza? La scadenza può essere reale, come una data fissa per un evento esterno o qualcosa di stagionale. Oppure può essere semplicemente un espediente in un ambiente con poca fiducia: la scadenza viene usata per pressarci, come fattore di stress per spingerci all’azione, o in qualche modo per responsabilizzarci, in una cultura altrimenti poco fiduciosa nei risultati. Indipendentemente dal motivo, se il cliente indica una scadenza, dobbiamo tenerne conto.

“Tolleranza zero“. Quando il costo di un ritardo oltre la data di consegna desiderata è veramente elevato, il cliente può avere “tolleranza zero”. Si tratta di una forma più estrema di scadenza: quando c’è tolleranza zero per i ritardi, tutti capiranno le conseguenze e l’impatto sulla nostra attività di un mancato rispetto della scadenza. È probabile che si sacrifichino molte altre richieste di lavorazione per rispettare la data.

Il prima possibile. Infine, l’aspettativa del cliente può essere “il prima possibile” (ASAP); in questo caso, se decidiamo di svolgere il lavoro, dobbiamo accelerare la richiesta.

Cosa si intende per costo del ritardo?

Un ritardo significa che si ottiene meno valore da un’opportunità. Il costo del ritardo cerca di approssimare il valore perso a causa del ritardo nello svolgere un lavoro. Il costo del ritardo può essere modellato come una curva che si accumula nel tempo. Se la forma della curva presenta un picco iniziale, il rischio di ritardo è significativo.

Quali possono essere le classi di servizio in funzione del costo del ritardo?

Accelerato (Expedite). Il costo del ritardo aumenta molto rapidamente.

Data fissa (Fixed date). In una data relativamente vicina, entro due volte l’intervallo della distribuzione del lead time, ci aspettiamo un costo del ritardo distribuito secondo una funzione a gradino (o una funzione a curva S inclinata ma molto vicina a una funzione a gradino) in un giorno noto e molto specifico, tipico della domanda stagionale o di eventi specifici (come tornei sportivi o festività pubbliche).

Standard. Il costo del ritardo aumenta inizialmente con un andamento convesso e infine concavo. La forma è una curva a S inclinata che cresce su un periodo di tempo medio-lungo.

Intangibile (Intangible). Il nome deriva dal fatto che il costo del ritardo è intangibile o insignificante per un periodo superiore a 1 o 2 cicli dell’intervallo di lead time. Sebbene la classe di servizio Intangibile sia stata modellata come se avesse una forma di funzione convessa, in realtà si tratta pure di una curva a S inclinata che cresce su un periodo di tempo molto lungo. Il lavoro appartenente alla classe di servizio Intangibile tipicamente è quello relativo ad aggiornamenti di piattaforma, introduzione di nuovi componenti o tecnologie in un progetto esistente, o riprogettazione, rielaborazione o, in generale, manutenzione di un sistema di prodotto o servizio.

Classe di servizio – come viene trattata rispetto ad altre richieste?

Tipicamente nel pondo dei servizi e dei progetti si parla di “mettere in priorità” le lavorazioni. Ma a bene vedere il termine è ambiguo. Priorità può significare che qualcosa è selezionato (o scelto) e quindi “prioritario”. Può anche implicare la sequenza, l’ordine o la regola di accodamento in cui un insieme di elementi devono essere lavorati. Oppure la priorità può implicare il momento in cui qualcosa dovrebbe essere programmato: ora, più tardi e, se sì, quando; o non del tutto. Oppure può implicare il modo in cui qualcosa viene trattato una volta inserito nel sistema: la sua classe di servizio.
Le tabelle di triage presenti nel metodo Kanban sono state progettate per facilitare la decisione rispetto agli ultimi due dei quattro significati della priorità. Vi aiuteranno a programmare il lavoro e a determinare la classe di servizio da applicare a un elemento di lavoro in base alla data di inizio prevista. Le tabelle di triage sono scaricabili dal sito Kanban+ della Kanban University.

Questo articolo è liberamente tratto e tradotto dal sito di Mauvisoft, clicca qui per leggere il contenuto originale.

Explaining the concept of vanity metrics to a teenage son with Kanban

“However beautiful the strategy, you should occasionally look at the results.”
– Winston Churchill

“This is your throughput this week Son, what’s gone wrong?”

“Nothing Dad, I just didn’t feel like doing anything.”

“Ok, but what if no one here felt like doing anything….”

“No idea…”

“Come on, don’t fool me around, you know the whole housesold would collapse”

“Don’t think so, Mom and you would fix it.”

“Nope, I mean if NO ONE here felt like doing anything, including Mom and me….”

“You can shift some of last weeks’ cards to this week, can’t you? So my through…how-do-you-call-it would be ok for this week as well, score done!”

“It’ not about a making a score, Son, it’s about doing something to collaborate with the community you live in. That’s the objective.”

“Isn’t it about the score…”

“No it isn’t. Just making the score is called ‘vanity metric’.”

“I am not vain.”

“I’m not saying you are vain, I’m saying that focusing on the score, and not on the underlying event measured by the score, ends up being a vanity metric.”

“Again your nerdish kanban thing, Dad….”

“Yes of course, Son, but let’s go back to the point: are you going to do something for the community this week, or not?”

“If I should….”

“Yes please.”

This conversation and the characters represented in it are purely fictional for the sake of explaining some Kanban Method to the folks

I originally posted this article on LinkedIn on May 2nd, 2024