De Bono nel 1985 aveva già risolto un problema che Scrum non ha mai affrontato davvero: le persone difendono la propria identità di ruolo invece di esplorare prospettive diverse. I sei cappelli separano le modalità cognitive nel tempo — prima i dati, poi le emozioni, poi i rischi — invece di sovrapporre tutto in una sola conversazione caotica. Applicato a OKR setting e sprint planning, non è un esercizio soft: è governance cognitiva. Un team agile vero sa indossare e togliersi i cappelli a prescindere dal ruolo su Jira.
Cerca: “nas”
Abbiamo trovato 107 risultati per la tua ricerca.
Nell’articolo sugli agenti disfunzionali ho descritto come ho dovuto introdurre dinamiche di adversarial verification tra agenti AI per ottenere qualità: verifica incrociata obbligatoria, challenge sistematiche, accountability sui falsi positivi. Quel metodo adesso è una skill open-source per Claude Code. Si chiama adversarial-verify, e applica Chain-of-Verification combinata con tre tecniche di audit avanzate su cinque domini. Il punto interessante non è la tecnologia: è cosa ci dice il fatto che abbia dovuto costruirla.
Stavo preparando un hackathon sul green software. Quello che doveva essere un esperimento veloce si è trasformato in quattro tool open source in cascata, ognuno estratto dal problema reale che il precedente aveva lasciato irrisolto. Il risultato: un CLAUDE.md come contratto tra developer e agente AI, una libreria TypeScript zero-dipendenze per misurare la Software Carbon Intensity, e un Agent Skill che audita il tuo progetto e ti dice esattamente dove stai sprecando byte — e carbonio.
TL;DR: Durante un workshop per costruire una ToC su sostenibilità digitale, mi è stata fatta una domanda molto intelligente: “E se cambia tutto?” La risposta non è nella precisione del piano, ma nel distinguere cosa non cambia mai (l’Impact) da cosa deve essere flessibile (tutto il resto). Gli unknown unknowns non si prevengono, si navigano.
TL;DR: Mi hanno chiesto un catalogo di corsi per la trasformazione aziendale. Gli ho dato una Theory of Change. Perché la formazione non è shopping, è costruire il futuro a ritroso.
TL;DR: Ho passato sei mesi con quasi 1000 bambini pensando di insegnargli a programmare. Invece mi hanno riprogrammato. Mi hanno insegnato che fallire va bene se capisci perché, riuscire senza capire non va bene, e che osservare gli errori altrui è efficienza, non pigrizia. E che tutto questo vale soprattutto per noi adulti.
Racconterò questa esperienza in dettaglio all’AgileDay 2025 organizzato da Italian Agile Movement. Se siete curiosi, non leggete oltre ci vediamo lì, altrimenti questa che segue è la prima bozza della trascrizione del talk.
Ho impiegato 5 anni, innumerevoli workshop e corsi per arrivare a scrivere 3 libri utili a far capire ai miei clienti perché è importante ragionare sulle giuste metriche per il sustainable IT. Spoiler: Studiare la Theory of Change per certificarmi come facilitatore per un workshop sulla sostenibilità mi ha fatto capire cosa mancava.
Mentre tutti si focalizzano su business model, MVP e framework spesso la vera chiave dell’innovazione potrebbe trovarsi in un concetto filosofico di 150 anni fa che tendiamo ad ignorare.
Se i tuoi OKR sembrano chiari solo a chi li ha scritti, prova a costruire una Message House. E vedi cosa cambia nel modo in cui le persone ti ascoltano, rispondono, agiscono.
Dopo aver letto del comportamento inquietante di Claude Opus 4 (che ricatta gli sviluppatori nell’84% dei test), ho testato le presunte “capacità avanzate” di Sonnet 4. Risultato? L’AI ha ammesso che il 70% dei suoi “miglioramenti rivoluzionari” sono ottenibili anche con la versione 3.7 usando prompt engineering appropriato. La differenza reale è del 10-15%, non del 50-100% che il marketing suggerisce. Il paradosso più inquietante: come può un sistema essere genuinamente autocritico se sta solo seguendo istruzioni per esserlo? È come chiedere spontaneità su comando – contraddittorio per definizione.