In Europa è una settimana di 5 giorni. La maggior parte delle aziende lavora fino a 40 ore alla settimana nell'ingegneria del software.

Abbiamo ore di base 10-4 in cui dovrebbero essere presenti tutti coloro che non sono in vacanza. Puoi avere fino a un'ora di pausa per il pranzo (la maggior parte richiede 1/2 ora).

Questo sistema funzionerebbe per te?

Hai identificato un conflitto chiave tra la metodologia tradizionale di Scrum e gli ambienti di lavoro flessibili sempre più popolari verso cui i datori di lavoro si stanno muovendo.

Se l'azienda supporta il sistema di lavoro flessibile, e il personale non è tenuto a esserlo. lì alle 09:30, poi dovrai lavorare con il tuo team agile attorno ad esso.

Mi vengono in mente due semplici soluzioni:

• Nomina un vice di mischia, così puoi delegare per le volte in cui non ci sei
• Consenti due riunioni in piedi al giorno, così tu o il tuo vice potete coinvolgere tutto il personale

Altrimenti la politica di lavoro flessibile è non funzionerà per te e ti ritroverai stanco.

Un'altra alternativa è richiedere la partecipazione a sprint di mischia chiave, magari all'inizio e alla fine di fasi importanti.

Ricorda: agile significa essere agili, non seguire le regole stabilite nel libro sacro di Scrum come se fossero scritture.

Ciò significa che puoi e dovresti cambiarle.

Hai problemi con gli stand-up che sono difficili da programmare. Quindi sbarazzati di loro. Sostituiscili con un altro modo di comunicare il carico di lavoro al resto del team, magari tramite e-mail, uno scrum o un altro sito web del progetto, o un feed di aggiornamenti in stile "social media" da ogni membro del team. Quindi i tuoi standup saranno continui, aggiornamenti.

Qualunque cosa tu scelga, il punto è che la modifichi per adattarla alla tua squadra. Scrum non è mai stato molto agile in primo luogo, ma è importante costringerlo a farlo per te.

Penso che sia necessario lasciare che sia il team a risolverlo. Sono tutte persone intelligenti che dovrebbero voler fare un piccolo sforzo per risolvere questo problema a meno che non vogliano perdere il loro tempo flessibile.

Assicurati che la politica aziendale e l'obiettivo della riunione siano rispettati. Spero che questo obiettivo vada oltre il semplice portare tutti nella stessa stanza contemporaneamente. Sembra uno spreco. Ciò potrebbe richiedere più documentazione sulle riunioni e fornire informazioni alle persone che potrebbero aver bisogno quando qualcuno è assente.

Qualcuno che perde un giorno della settimana non dovrebbe essere un grosso problema. Si verificano ferie e assenze impreviste. L'obiettivo di essere agili è essere in grado di gestire queste situazioni e non fare dell'adesione a qualche processo il problema.

Sei lo scrum master / il capo del team, quindi hai l'opportunità di cambiarlo.

Chiama una retrospettiva (o come vorresti chiamarla) su questo aspetto del tuo lavoro e del tuo team. Spiega che non puoi lavorare 7 giorni alla settimana e che il sistema attuale non funziona per te. Consentire a tutti i membri del team di esprimere le proprie opinioni (magari dare loro un po 'di tempo per prepararsi a portare con sé un aspetto positivo, negativo e un aspetto che cambierebbero) e alla fine lavorare per un sistema che funzioni per tutti nel team. Può sembrare impossibile iniziare, ma potrebbe essere implementato pezzo per pezzo per cominciare, con una soluzione perfetta in mente per guidarti.

Penso che dovresti fare in modo che la squadra accetti di stare tutti insieme almeno due volte a settimana, quindi sei tutti in contatto. Penso che anche qui la soluzione del vice sarebbe vantaggiosa.

Dovresti fare in modo che le regole flessibili funzionino anche per te, non lavorare 7 giorni alla settimana se non funziona per te. C'è un compromesso.

Avere una politica di "orario di lavoro flessibile" in realtà finisce per causare gli stessi sintomi che i team distribuiti devono affrontare. Alcuni team sono sparsi in tutto il mondo in molti fusi orari diversi e devono farcela se desiderano praticare Agile / Scrum.

I team distribuiti non condividono lo spazio dell'ufficio, o un momento comune nel tempo che ciascuno il membro del team può chiamare "l'inizio della giornata". Pertanto, devono portare la loro comunicazione offline. Considera una Slack room dedicata in cui tutti possono inviare i propri aggiornamenti.

In qualità di Scrum Master per un team distribuito, sono solidale con il cambiamento organizzativo che stai attraversando: è un problema difficile da risolvere e da risolvi bene. Ho twittato su questi problemi su @albieio, inclusi esperimenti per migliorare Agile remoto.

Concordo con il punto che questo è un problema di squadra. Il tuo gruppo dovrà capire quali sono gli elementi più critici della mischia e come verranno soddisfatti, e cosa succede se non vengono raggiunti in un dato periodo di tempo. Certamente come scrum master il tuo compito è assicurarti che i bloccanti del team vengano eliminati e che il team sia in grado di autogestirsi. Ma ciò non significa che tu abbia personalmente bisogno di essere presente 24 ore su 24, 7 giorni su 7, 365 giorni l'anno.

Ecco alcune idee specifiche ...

Stato

Scopri un meccanismo di stato di non persona per alcuni giorni. O quando sei fuori, o quando una massa critica della squadra è fuori. Trova un modo in cui lo stato persista in modo che i membri del team che sono andati per un giorno possano recuperare il ritardo quando sono tornati (come email, una bacheca delle attività o altre trasmissioni fuori banda).

Fai la pianificazione del tempo del team fa parte della cadenza dello sprint

Il team si impegna a una cadenza, il team si impegna a trascorrere il tempo fuori dall'ufficio: allinea l'impegno mensile del team al piano dello sprint, in modo che sono responsabili l'uno dell'altro (e di te) sia di ciò che fanno sia di quando decollano. Assicurati che i normali impegni della squadra siano coperti nei piani di ferie.

Nota, questo non significa necessariamente che la squadra debba tornare all'impegno di tipo M-F 10-4. Se mischia MWF alle 2:00 PM e sabato, martedì, giovedì. alle 8:00 al lavoro e metà di coloro che si incontrano c'è un vice che si incontra con te a giorni alterni ... poi finché tutti hanno ciò di cui hanno bisogno - fantastico. Ma il team ha bisogno di una sorta di accordo.

Mentoring / Pair Programming

Potrebbe anche essere necessario fornire alcune indicazioni generali su quest'area. Il collega più recente, ad esempio, potrebbe aver bisogno di impegnarsi per un periodo di formazione in cui lavora sempre con qualcuno a portata di mano, quindi se nessun altro è presente sabato, anche il nuovo ragazzo potrebbe non essere in grado di scegliere il sabato. Allo stesso modo, tendo a ritenere i miei ingegneri più anziani la più responsabile della fornitura di una buona guida, quindi potrebbero dover assicurarsi che l'80% del loro tempo sia trascorso con almeno il 60% del gruppo in giro - o qualcosa di simile. Questo viene spesso lamentato - perché il bisogno di guidare gli altri riduce la capacità di concentrarsi completamente sul lavoro del software. L'obiettivo deve essere il beneficio dell'intero team , non il lavoro di un singolo individuo.

Trasferimento davvero buono

Se tu avere persone che lavorano selvaggiamente al di fuori di una norma (diciamo che la maggior parte del team lavora dalle 9:00 alle 18:00 e una persona vuole dalle 19:00 alle 16:00) - potresti dover forzare il punto che è richiesto ALCUN livello di coordinamento con la disponibilità di persona per X meetup a settimana o mese. È difficile credere che qualcuno possa lavorare in una situazione di squadra in cui è completamente disgiunto nella pianificazione dell'intero team.

Se può davvero, davvero lavorare in modo indipendente, dovrai comunque definire come riferire, come ottengono aiuto, come coordinano il lavoro. È del tutto OK dare l'onere alla persona che vuole allontanarsi dalla mandria e chiedere a loro di assumersi la massima responsabilità per rimanere in contatto.

Pensiero finale

Se vuoi davvero mantenere un programma estremamente flessibile, devi sviluppare una definizione davvero critica di come appare il successo o il fallimento per l'output di un individuo: non solo la qualità del lavoro tecnico dell'individuo, ma anche il suo debole abilità e la loro capacità di far parte di una squadra. Questo tipo di responsabilità è necessario se le persone vogliono davvero questo livello di indipendenza. Se non vogliono assumersi la responsabilità come individui, non hanno il privilegio di impostare programmi altamente individualistici.

Abbiamo avuto una situazione simile con orari flessibili e un team distribuito e abbiamo risolto il problema con degli standup in un momento specifico in cui era più probabile che le persone fossero in giro, ma su uno specifico canale Slack. Gli stand-up erano tramite video se le persone lavoravano da casa o solo tramite chat di testo. Facevamo anche tradizionali stand-up faccia a faccia quando la presenza lo rendeva possibile.

Se una persona non era disponibile, inviava un messaggio diretto con la sua dichiarazione di standup allo scrum master designato che l'ha pubblicata o letta a il momento opportuno.

Quando uno scrum master non era disponibile, un senior o un lead prendeva la posizione e prendeva appunti da passare allo scrum master in modo che potesse occuparsi dei bloccanti (anche se molto spesso la squadra lo solo trovare un modo per gestirlo durante lo stand-up).

Retros e riunioni di pianificazione richiedevano che tutti fossero in ufficio, ma in genere c'erano vantaggi per incoraggiare la presenza fisica in quelle date (il direttore del dipartimento ha pagato per birra e cibo).

Non mi definirei un esperto di esperienze qui, ma sono sorpreso di non vedere qualcuno suggerire di parlare con il tuo team, capire perché scelgono le ore che fanno e quali sono le loro gli interessi sottostanti sono.

Ad esempio, uno potrebbe portare i bambini da / a scuola o all'asilo, un altro potrebbe prendersi cura di un parente anziano, un altro potrebbe essere in volo dalla famiglia venerdì pomeriggio e tornare lunedì mattina e un altro potrebbe avere solo un cronotipo in ascesa.

Quindi destreggiati tra i tempi delle riunioni per bilanciarli nel miglior modo possibile. Dopotutto, lo faresti in un contesto non lavorativo, quindi perché non anche in un contesto lavorativo?

Alla fine il personale viene a lavorare perché lavorare su obiettivi condivisi aiuta a raggiungere i propri. Non sfuggirai al tentativo di capirli comunque se vuoi fare bene queste cose.

I suggerimenti per imporre solo un programma o orari fondamentali sono un po 'un poliziotto -out, e ti perderai i vantaggi del lavoro flessibile quando potresti non averne bisogno. Hai davvero intenzione di dire al tuo staff di assumere una tata, di non vedere la sua famiglia o di essere assonnato tutto il giorno (o di lasciare l'azienda) solo per poter programmare una chat di 15 minuti più facilmente?

Alcuni le persone possono perdere la riunione alcuni giorni, ma ciò accade comunque. Per quanto riguarda il dover tenere la riunione 7 giorni su 7 ... ci sono davvero così tante cose nei fine settimana che non puoi affrontarle venerdì e lunedì? Se è così, non può gestirlo qualcun altro, proprio come potrebbe accadere quando sei in vacanza, a una conferenza o in malattia?

In ogni caso, lavoro flessibile di solito non significa "fai quello che come se non importasse il tuo lavoro ", può facilmente significare" non ci sono requisiti a livello aziendale, ma assicurati che il tuo lavoro venga svolto e trovi soluzioni specifiche per la situazione con il tuo project manager / manager di linea ".