Questa risposta è scritta dal punto di vista di qualcuno che aveva un tale sistema di gestione delle prestazioni messo in atto attorno a un team Agile; come te, tutti i membri del team hanno realizzato la difficoltà / inutilità degli obiettivi SMART di un anno applicati a un gruppo Agile, dove, quando pienamente funzionante, l'implementazione di Agile può essere considerata intrinsecamente / già SMART.
No davvero! Se necessario, chiama la seguente razionalizzazione (se la logica è semicotta ...), ma spiegarla a revisori esterni all'organizzazione immediata ha posto le basi per gli "obiettivi" effettivi che abbiamo inserito nel sistema di gestione delle prestazioni.
- S per specifici : durante ogni pianificazione dello sprint, il team si impegna su una serie specifica di compiti da svolgere e si impegna a svolgerli. I compiti (e le storie degli utenti), rispondono alle domande su cosa voglio realizzare, scopi / benefici del raggiungimento dell'obiettivo, chi è coinvolto, dove si svolge e vincoli.
- M misurabile : l'elenco di questi compiti, oltre allo spostamento dei ticket durante lo sprint, dallo sviluppo alla revisione del codice fino al QA per il rilascio (o qualunque sia il flusso), risponde alle domande su quanto lavoro e quando verrà realizzato .
- A raggiungibile : i gruppi Agile funzionanti in genere 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 rilevante : domande come vale la pena, è il momento giusto, corrisponde ai nostri altri sforzi - storie e compiti non vengono trascinati in uno sprint e impegnati, a meno che la risposta sia sì a tutte queste domande ( tipicamente ... YMMV)
- T per limiti 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) è esso stesso un grande obiettivo SMART e che sai che stai raggiungendo i tuoi obiettivi perché il team si sta comportando bene, la velocità è positiva, i rilasci avvengono , quindi si arriva al punto della domanda, che è in definitiva come tradurre un processo SMART in una serie di obiettivi SMART a beneficio di qualcun altro.
Sono stato in grado di 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 raccolti 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 allinearmi al programma di sviluppo generale del prodotto (blah blah)."
"Voglio aumentare la velocità di sviluppo del team di n% dalla versione A alla versione B, concentrandomi sulle modifiche incrementali al processo di gestione degli arretrati, 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 vero gruppo di sviluppo, ma non sono del tutto indipendenti, e nella mia esperienza sono i tipi di cose che sembrano davvero SMART e utili alle persone al di fuori della tua organizzazione immediata (senza essere completamente bugie o totalmente zoppo).