Scenari sperimentati:

A) Progetto annuale giunto al 4° mese con un buon andamento.

Per l'iterazione corrente della durata di 2 settimane vengono richieste features stimate complessivamente in 3 settimane.

Si è provato a negoziare una riduzione dello scope individuando le features di maggior valore realizzabili in 2 settimane ma il tentativo non ha avuto successo. 

Non consegnare tutte le features richieste dal cliente provocherà un grave danno all'immagine.

Il boss convoca un meeting con sviluppatori e coach per studiare le opzioni possibili.

B) Il team XP che lavora su un progetto da tempo si sta assottigliando, ed entrano nello stesso progetto dei consulenti. Attualmente i consulenti lanciano i test e si cerca di fare un po di pair programming. Siamo nella prima retrospective del team misto (composto da una minoranza di XPer e una maggioranza di consulenti esterni) con il coach come moderatore. Tutti i post-it delle azioni proposte dai consulenti riguardano porposte atte a togliere pratiche del pomodoro, o non fare piu pair, o dedicare persone apposta per i test e così via. Nel momento della votazione i consulenti votano solo le azioni da loro proposte.

Scenario 1 (proposto da Tommaso Torti)

La vostra società ha contattato un cliente e si è concordato di impiegare 10 giorni per fare un prototipo di una applicazione. 

Quanto più il prototipo è ricco quante più chances hai di vincere un contratto ricco! 

In questo contesto c'è uno sviluppatore XP che vuole tutto il set di tool e pratiche ben oliato, foss'anche per un prototipo: non ammette che non si scrivino test, che non ci sia una macchina di continuos integration, vuole comunque una qualità del codice perfetta, vuole stimare le attività da fare per i 10 giorni, scrivendo AT etc.

Scenario 2 (proposto da Sergio Berisso)

Il cliente ha un prodotto software scritto in Access/vba con il codice in evidente bancarotta.

Nel frattempo gli utenti hanno bisogno di modifiche settimanali che costano lacrime e sangue.  

Si è deciso di riscriverlo ma il team è diviso su come affrontare il progetto.

Il coach (duro e puro) vuole riscriverlo da zero in C# con tutte le pratiche XP, prendendosi diversi mesi e bloccando tutte le modifiche al vecchio Access/vba.

Gli sviluppatori del team invece vorrebbero riscriverlo gradualmente, sostituendo le parti più critiche in C# (dando agli utenti per un po' di mesi una soluzione mista C# / Access / vba).

Sviluppatori e coach non sono nemmeno d'accordo sulle pratiche XP da adottare.

il coach è un dipendente-quadro dell'azienda cliente (con ampia libertà/influenza decisionale) e gli sviluppatori sono consulenti.

Ma se questo scenario è troppo vincolante possiamo variarlo (fra un dipendente/project manager e dei consulenti si sa già chi vince).

Che so, introducendo un product owner dipendente del cliente e/o facendo il coach consulente, gli sviluppatori misti consulenti e dipendenti.

tony: il coach e' ben distinto dal product owner?

sergio: direi di no, cioè nello scenario iniziale non c'è un product owner ed il coach fa anche da project manager (volendo decidere un po' lui quello che va bene per i suoi colleghi del business)

tony: propongo di individuare un product owner, distinto dal coach.

sergio: si, è meglio con product owner distinto dal coach (e la mancanza di una figura di riferimento del business è uno dei problemi dello scenario iniziale ... se non il problema)

tony: questo sito mostra delle tecniche utili: http://www.mindtools.com/pages/main/newMN_TED.htm.