---

Che cosa può causare caos e frustrazione prima di Scrum? Potrebbe sorprenderti!

Per comprendere meglio l'impatto di Scrum sulle pratiche ingegneristiche e sulle attività, è utile osservare una giornata di un progetto software.

Vorrei quindi descrivere brevemente un progetto passato, prima dell'adozione di Scrum nelle nostre organizzazioni.

Pochi giorni prima di scrivere queste righe, abbiamo pranzato con un ex collega con cui lavoravamo quasi 20 anni fa.

Marcus ha ottenuto la certificazione Scrum Master e certificazione Scrum Product Owner da International Scrum Institute™. Oggi è Scrum Master presso una delle principali aziende software nella gestione agile dei progetti.

Sostiene un team Scrum agile con membri distribuiti geograficamente nel mondo.

Durante il pranzo, Marcus ammise che i team Scrum agili distribuiti incontrano molte difficoltà tipiche. Tra i problemi specifici del suo progetto citò:

• Stili di lavoro diversi tra i membri,
• Differenze di fuso orario,
• Incompatibilità culturali e
• Limiti linguistici.

Nonostante tutto, aggiunse che gestire un progetto software con Scrum agile è più divertente, produttivo e arricchente del modo in cui lavoravamo 20 anni fa. Rispetto a quando non usavamo Scrum per sviluppo e consegna software.

Le sue parole erano davvero una forte testimonianza del valore di Scrum da parte di un manager, Scrum Master e Product Owner molto esperto e affermato.

Grazie, Marcus!

Gli raccontammo quindi un nostro progetto precedente a Scrum. Sono sicura che molti Scrum Master riconosceranno esperienze simili nei progetti svolti prima della certificazione.

Alla fine degli anni 1990 facevamo parte di un gruppo di ingegneria software per costruire un sistema di infrastruttura a chiave pubblicabasato su smart card. Le carte proteggevano in sicurezza le chiavi private dei membri; le chiavi pubbliche associate e i certificati che le contenevano erano distribuiti apertamente, come suggerisce il nome.

Già allora era un progetto IT relativamente complesso, con più team hardware e software interdipendenti. Dovevamo svolgere moltissima ricerca e sviluppo (R&D) per costruire un sistema hardware e software pienamente funzionante.

Ricorda che nel progetto non usavamo ancora il concetto di prodotto minimo funzionante (MVP) per sperimentare, creare, imparare e sperimentare di nuovo.

Senza Scrum, creare un'infrastruttura così sofisticata, composta da molti elementi hardware e software, era una vera sfida.

Ecco tre difficoltà significative che incontravamo senza Scrum Master e senza persone certificate nei nostri team.