Quando si introduce un nuovo metodo di lavoro all’interno di un team, bisogna valutare il contesto del progetto e delle risorse che si hanno a disposizione. Il rischio è quello di essere poco efficaci. O quantomeno, di non centrare l’obiettivo al primo colpo.
Sia Kanban che Scrum hanno degli aspetti che si sposano bene in alcuni contesti ed altri che si possono rivelare delle forzature.
Prendiamo un esempio tipico: gli sprint di Scrum. Come è stato dimostrato nella pratica, avere dei blocchi di sviluppo ben definiti consente di rimanere timeboxed, di avere feedback rapidi dagli stakeholder e così via. Ma siamo sicuri che non ci siano progetti (o contesti) che possano beneficiare dal fatto di non avere questi vincoli?

Lavorare a ciclo continuo, in modalità Kanban, consente di dare al team di lavoro il controllo dei rilasci. Non appena si colleziona un blocco di funzionalità deliverabili, una release si può considerare pronta per la produzione.
E così via. E’ il team che sa (e ha la responsabilità di decidere) quali funzionalità può prendere in carico, quanto può ancora produrre entro un periodo di tempo ragionevole, quanto è in grado di fare con il livello di conoscenze tecniche o funzionali di cui dispone in quel determinato momento.

Trovo che, nel momento in cui il team garantisce un ritmo di delivery soddisfacente, una produzione a ciclo continuo sia quella che garantisce più autonomia e libertà di movimento a chi lavora al progetto.