Questa risposta è scritta dal punto di vista di qualcuno che aveva messo in atto un sistema di gestione delle prestazioni attorno a un team Agile; come te, tutti nel team hanno compreso la difficoltà / inutilità degli obiettivi SMART per un anno applicati a un gruppo Agile, dove, quando è completamente funzionante, l'implementazione di Agile può essere considerata intrinsecamente / già SMART.
No, davvero! Se necessario, chiama la seguente razionalizzazione (se la logica è semicarrata ...), ma spiegarla ai revisori al di fuori dell'organizzazione immediata ha posto le basi per gli "obiettivi" effettivi che abbiamo inserito nel sistema di gestione delle prestazioni. / p>
-
S per specifici : durante ogni pianificazione sprint, il team accetta una serie specifica di compiti da raggiungere e si impegna a eseguirli. I compiti (e le storie degli utenti), rispondono alle domande su cosa voglio realizzare, scopi / benefici del raggiungimento dell'obiettivo, chi è coinvolto, dove ha luogo e vincoli.
-
M per misurabili : l'elenco di queste attività, oltre al movimento dei ticket durante lo sprint, dallo sviluppo alla revisione del codice, al QA per il rilascio (o qualunque sia il flusso), risponde alle domande di quanto lavoro e quando sarà compiuto.
-
A per essere raggiungibile : i gruppi Agile funzionanti di solito non si impegnano in qualcosa in fase di pianificazione a meno che non sia chiaramente raggiungibile - tutti i pezzi sono lì per sapere come realizzarlo
-
R per pertinente : domande come ne vale la pena, è il momento giusto, corrisponde agli altri nostri sforzi - storie e attività non vengono tirate in uno sprint e impegnate a meno che la risposta è sì a tutte queste domande (tipicamente ... YMMV)
-
T per il limite di tempo : uno sprint è necessariamente limitato nel tempo, che si tratti di 2 settimane, 3 settimane, più o meno.
Se capisci / ti convinci che il tuo lavoro trimestrale (e quindi il tuo lavoro di un anno) è di per sé un grande obiettivo SMART, e che sai che stai raggiungendo i tuoi obiettivi perché la squadra sta andando bene, la velocità è positiva, i rilasci stanno accadendo, quindi si arriva al punto della domanda, che alla fine è come tradurre un processo SMART in un insieme di obiettivi SMART a beneficio di qualcun altro.
Sono riuscito a farlo con successo in passato scrivendo qualcosa che per me sembra vago e, beh, non molto SMART, ma in realtà è perfettamente accettabile per gli altri.
Un paio di esempi che sono stati trasmessi altrove per me:
-
"Voglio rilasciare una nuova versione di WidgetMaker ogni tre mesi nel prossimo anno, seguendo il nostro processo di sviluppo del software interno, per allinearci con il programma generale di sviluppo del prodotto (bla bla)."
-
"Voglio aumentare la velocità di sviluppo del team del n% dalla versione A alla versione B, concentrandomi sulle modifiche incrementali al processo di grooming del backlog, al fine di aumentare la nostra efficacia e ridurre i ritardi nella spedizione del prodotto ".
Sai e so che questi non sono i principi guida del tuo attuale gruppo di sviluppo, ma non sono del tutto estranei, e nella mia esperienza sono i tipi di cose che appaiono davvero SMART e utili alle persone al di fuori del tuo immediato organizzazione (senza essere menzogne o totalmente zoppi).