Il talk è pensato per esperti che occupano ruoli di management all’interno delle strutture IT (Business Peoples, Team Lead, PMO, etc), in particolare in contesti alle prese con progetti complessi.
Si tratta della naturale prosecuzione del talk Agile@Scale tenuto all’Agile Day 2013, che, dai feedback è risultato interessante ma estremamente condensato.
Da qui la volontà di riprendere il discorso estendendo, in questa occasione l’aspetto relativo al livello Program (rif. SAFe), ossia la concretizzazione della Vision di progetto attraverso la definizione del Program Backlog, dei vari Team Backlog e l’introduzione del concetto di Agile Release Train (ART) congiuntamente ai PSI (Potentially Shippable Increment).
La scelta del livello Program consente di concentrarsi, anche grazie ad esempi pratici tramite tool quali TFS o Jira, su problemi concreti legati alla gestione di progetti che si basano sul lavoro di più Team, abbattendo le complessità che rendono il cosiddetto Scrum-by-Scum difficile da usare.

Many people tend to underestimate the value of retrospectives in Agile: they are often seen as a waste of time and a useless component in the overall production picture.
The aim of this talk is unveiling the potential of retrospectives as the main tool to inspect and adapt: theory, practice and tips will show you the importance of this often overlooked meeting.

"Ma perché lavoro sempre con codice pessimo? Ma perché i colleghi non collaborano mai? Ma perché i manager non sanno fare il loro lavoro?" E' tempo di cambiare atteggiamento. Basta lamentarsi e iniziamo a progredire. La crescita inizia da noi stessi e influenza gli altri.

Perché parliamo di Scaling Lean Agile?
Ci sono due aspetti primari inerenti lo scalare delle tecniche agili a livello di Enterprise che è necessario considerare. In primo luogo lo scalare delle tecniche agili a livello di progetto per affrontare le sfide peculiari che i team di progetto devono affrontare. In secondo luogo è lo scalare la vostra strategia agile attraverso l'intero reparto IT, in modo appropriato. E' abbastanza semplice applicare Lean Agile su una manciata di progetti, ma può essere molto difficile far evolvere la cultura e l’intera struttura organizzativa per adottare appieno il modo agile di lavorare.
Lean e Agile (in particolar modo metodologie come Scrum e XP) hanno pienamente dimostrato il loro valore a livello di team. Cosa succede però nel momento in cui tentiamo di utilizzarle in contesti reali più complessi? Nelle reali organizzazioni che caratterizzano un’importante parte del panorama dell'IT in Italia? Muovendosi dal livello dei team verso il livello dell'organizzazione si incontrano una serie di problematiche più complesse e per un certo verso nuove. Ecco quindi l'importanza di conoscere valori e principi che sono alla base del tema del Lean Agile Scaling. Esistono parecchi modelli che negli ultimi anni si confrontano con le realtà delle organizzazioni.
In questo talk tratteremo a livello olistico questo tema e confronteremo alcuni di tali modelli di Scaling Lean Agile, quali: Scrum standard (Ken Schwaber, Mike Cohn, ...) – il modello di Larmann & Vodde - SAFe – Disciplined Agile Delivery di Scott Ambler – Path to Agility (Ken Schwaber). Inoltre verranno affrontate e discusse le esperienze personali effettuate in diverse società in fase di adozione o utilizzo su larga scala di Lean Agile.

Riteniamo, che non vi sia dubbio sul fatto le User Story (introdotte da eXtreme Programming) e il Product Backlog (definito in Scrum) rappresentino due portentosi strumenti per la gestione agile dei requisiti e delle specifiche sia funzionali che non funzionali. Ma … hanno alcuni limiti.
Ad esempio, nonostante le notevoli caratteristiche del Product Backlog, la sua unidimensionalità non consente di creare un modello dei requisiti adatto a scalare e che consenta di gestire le dipendenze che possono essere presenti tra i vari elementi che lo costituiscono.
In questo workshop presenteremo e utilizzeremo un altro potente strumento che spesso utilizziamo durante gli User Story Workshop sia in fase d’Inception, sia all’inizio di ogni nuova release di un prodotto. Si chiama “User Story Mapping”.
Ci divertiremo con voi ad utilizzarlo in una simulazione che partendo dalla Vision di un prodotto ci consentirà di mappare i bisogni di un numero selezionato di utenti su un insieme di funzionalità organizzate in una mappa.
Inoltre vedremo come sia possibile utilizzare questo strumento per gestire le diverse release di un prodotto a partire dal così detto “Walking Skeleton” fino alle successive MMF (Mininum Markatable Feature)
Sapete cos’è il modello di Kano, FURPS+, o come il nome della capitale della Russia possa essere utilizzato per assegnare priorità alle diverse storie? Se vi abbiamo incuriosito, o se pensate che avere un nuovo strumento mentale da aggiungere alla vostra cassetta degli attrezzi potrebbe esservi utile, partecipate. Sarete certamente i benvenuti.

Quali sono le responsabilità di un Product Owner? Quali le skill necessarie? Quali sono i tool che ha a disposizione? Quali sono le principali disfunzioni? Ha senso parlare di Product Ownership al di fuori di Scrum? Che differenza c'è con il Product Manager?
Le domande che girano intorno alla Product Ownership e al ruolo specifico del PO sono tante e, a volte, è difficile trovare le risposte. Per questo motivo, nel 2013 abbiamo organizzato il Product Ownership Camp e stiamo preparando l'edizione 2014. In questo breve viaggio attraverso la PO vorrei provare a presentare alcune delle risposte che ci siamo dati durante il camp e raccogliere le esperienze e le opininioni di PO e di chi, con loro, lavora a stretto contatto tutti i giorni. Esperienze e opinioni fondamentali anche per continuare quello che è l'obiettivo del camp 2014: realizzare il manifesto della Product Ownership.