Archivi tag: agile

Come fare un daily stand-up meeting efficiente in “stile kanban”

Gli standup meeting sono un elemento comune dei processi di sviluppo Agile.

Meeting con kanban
Meeting con kanban

Di solito si fanno al mattino primo di iniziare il lavoro e hanno un formato standard. Uno standup meeting tipico consiste nel chiedere a turno ai partecipanti le tre fatidiche domande:

  1. Cosa hai fatto ieri?
  2. Cosa farai oggi?
  3. Sei bloccato con qualcosa e hai bisogno di aiuto?

Ogni membro del team risponde a queste domande e così il team è coordinato per le attività della giornata.

Con l’adozione di una kanban board le cose si svolgono diversamente.

Non c’è bisogno di chiedere a turno ai partecipanti le tre domande perché la loro risposta è implicita dalla posizione dei kanban sulla lavagna. La lavagna contiene tutte le informazioni su chi sta lavorando a cosa. Chi partecipa regolarmente ai meeting si accorge anche di cosa è cambiato e se qualcosa è bloccato o meno è visivamente evidente.

Perciò il processo è leggermente diverso in ambito kanban rispetto a daily meeting tradizionale. Il facilitatore, di soluto un PM, “attraversa la board”. Per rinforzare il concetto di sistema in tirare/pull, convenzione vuole che la kanban board si legga da destra versa sinistra (al contrario del processo di produzione del valore). Questo perché non ha senso spendere tempo ed energie su cose “a monte” quando “a valle” ci sono problemi che ostacolano il flusso del lavoro. Inoltre, questo aiuta a far rispettare i WIP limit per cui nuove attività non possono iniziare se quelle incorso non liberano il loro posto.

Il moderatore del meeting pone enfasi sugli elementi bloccati (visivamente evidenti per delle convenzioni sui colori). Vengono poste domande sul perché questi elementi sono bloccati e si adotta un approccio proattivo per cercare di sbloccarli il prima possibile.

Dopo aver discusso gli elementi problematici, il team può passare in rapida rassegna gli elementi in lavorazione, ma i team più maturi in questo ambito non ne hanno bisogno.

Questo meccanismo consente di ridurre di molto la durata di meeting, considerando che si parlerà solo di cui c’è bisogno in maniera puntuale. La kanban board per sua natura funge da radiatore di informazioni che, con un minimo di pratica, a colpo d’occhio possiamo interpretare e capire lo stato dell’arte con un semplice sguardo.

Video

In questo video una dimostrazione su come fare! 🙂

Libri di riferimento

Kanban, Succeful Evolutionary Changes for Your Technlogy Business | David J. Anderson | Su Amazon

Personal Kanban: Mapping Work, Navigating Life | Tonianne DeMaria Barry, Jim Benson | Su Amazon

(I link ad Amazon sono link affiliati, il che significa che se vengono acquistati gli articoli tramite quel link ricevo una piccola percentuale da Amazon. Per te non cambia niente.)

Improve leadtime and workflow with WIP limits on VSTS

A powerful method to keep or make a customer happy is to satisfy his needs quickly. In our typical very busy day we do a lot of things and this hurts our ability to concentrate and focus. This is true for us individually but this is also true as a team.

Little’s Law

We can improve the response time to our customer by leveraging the Little’s Law:

It is a theorem by John Little which states that the long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system. – Wikipedia

L = λ W

For example if our team completes 2 user stories every day (𝜆 = 2) and every user story takes 4 days to be developed (W = 4) we have a system with L = 8 ongoing activities.

If we write Little’s Law like this

W = L / λ

we discover that wait time (W) can be reduced if we reduce L, the amount of ongoing activities at the same time.

VSTS boards and WIP-limits

If you manage your team activities with Visual Studio Team Services (VSTS) you can improve the flow and reduce lead-time by limiting the amount of work in progress in your kanban board.

You can setup the WIP-limits in the board of your Backlogs. Go to Work -> Backlogs and then click on Board.

2.png

As you can see VSTS has the default value of 5 for the Active and Resolved statuses. It means that your team cannot drag more than 5 PBIs in the Active or Resolved column otherwise the number of activities turns red, indicating that your team is doing too much work at the same time.

1.png
Default settings of VSTS

3.png
Too much activities!

You can change the values for to better fit the needs and size of your team by clicking the gear icon in the board and access the settings and then click save.
Of course you can also change the column names and add other statuses as well but we’ll cover this in another blog post.

4.png

Where do I start?

A very low WIP-limit can freeze the activities of your team and it may be very hard to respect. Don’t spend lots of time to calculate or debate about WIP limit: start with number that gives flexibility, plan a meetings two week later and discuss it again. You and your team will find the right balance.

TL;DR

Limiting the work in progress is a powerful way to improve the lead-time of our activities and it’s very cheap, too! It’s a team discipline activity and at the beginning it can be counter-intuitive and hard to respect. When a team is doing too much activities at the same time the quality goes down and the lead-time goes up and rework will be required. If the WIP limits block you from starting a new user story you can pair programming with a colleague or reply to that old e-mail that’s waiting so long.

Picture1.gif

 

Agile@School – Inizio

Anche l’ITI F.Viola/Marchesini di Rovigo si è unito ufficialmente al progetto esperimento/laboratorio Agile@School basato sull’idea e il supporto di Alessandro Alpi.

Immagine

Il tutto è stato inserito nelle attività ufficiali di alternanza scuola-lavoro dei ragazzi delle due quinte dell’istituto rodigino.

Il laboratorio ha come obiettivo introdurre i ragazzi ai concetti Agile e di lavoro in team: si mettono le mani in pasta e si utilizzano strumenti all’avanguardia del mondo professionale per realizzare un’app con Xamarin.

Nelle tre ore di laboratorio abbiamo toccato svariate argomentazioni e devo fare i complimenti ai ragazzi per essere stati complici e attivi in questo inizio di percorso tutto da esplorare.

  • Abbiamo introdotto i primi concetti e terminologia del mondo Agile e delle sostanziali differenze di cosa vuol dire fare un software per hobby/studio e farlo professionalmente.
  • Abbiamo esplorato le funzionalità di base di VSTS (Visual Studio Team Services) creando varie tipologie di PBI e mettendole in relazione per far capire come si possono condividere informazioni tra i vari ruoli in un team: il punto di vista del developer, del referente di progetto (middle management) e di un livello ancora più alto. Abbiamo esplorato le board e i backlog.
  • Abbiamo simulato un flusso di lavoro con feature-branch con git e Team Explorer di Visual Studio.

Come primo incontro è stato molto ambizioso, ci sono stati dei momenti più coinvolgenti e altri meno: molto è sicuramente da imputare alla mia inesperienza come formatore ma farò il possibile per calibrare sempre meglio i contenuti e le mie capacità.

Mi ha sorpreso positivamente vedere come alcuni studenti avessero già mosso i primi passi su GitHub e conoscessero il funzionamento di branch e pull-request.

Un grazie particolare va ai professori del corso di informatica e sistemi che hanno sin da subito appoggiato e creduto in questo progetto. Grazie prof. Borsetto, prof. Melon e prof.ssa. Bellini.

Alla settimana prossima!

Sulla costruzione di una squadra, ep. 1

-“Fissiamo già la prossima data!”

-“Sì sì sono d’accordo. Apriamo i calendari e decidiamo data e argomenti della prossima volta.”

L’entusiasmo era palpabile, persino quello dell’amministratore che si è prestato come moderatore nella nostra prima revisione tecnica. Non mi aspettavo un tale successo e invece la nostra prima attività vera di gruppo si è svolta alla grande.

La quotidianità stava per minare lo svolgersi di questo esperimento e farlo rimandare ma l’abbiamo scampata. Abbiamo scoperto quanto già in una prima e rudimentale versione di revisione di gruppo formale sia rapido lo scambio di conoscenze tecniche e di dominio del problema che si va ad analizzare. Quante cose ognuno di noi dia per scontate rispetto agli altri e viceversa. Quanto ci manchino linee guida, procedure e tecniche per rendere più snello il nostro lavoro e per renderlo il più coerente possibile all’interno della squadra.

Anche le persone stesse riservano grandi sorprese perché a fare il ruolo dell’autore è stata la persona che meno mi sarei aspettato ed è successo spontaneamente! Ha scelto autonomamente un pezzo di software da lui costruito e l’ha sottoposto all’esame della squadra senza alcun risentimento con la totale volontà di mettersi in gioco e crescere insieme.