Archivi categoria: team

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.


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.)

ALM DOs & DON’Ts – Definition of done

We all have been in this kind of situation: someone in the team states that a feature is done but in reality there is that little thing to figure out and the coding is completed the day after. Why is that? Because every person has a different definition of done inside his mind.
How can we protect a team from this? Simple! With a Definition of Done.


A good definition of done explicits what activities has to be done before declaring that our coding activites are over.
For example:

  • All unit tests are green
  • Coding style and conventions are respected
  • UI respects the specs validated by the Customer.

Every team and every project will create a different definition of done. The very important thing is that you and your team discuss such a definition to remove wrong expectaions about the status of work in progress.

Power is nothing without control

You can’t control (leave alone improve) what you can’t see – Me

Power is nothing without control – Pirelli

Why a dashboard?

When we drive our car we have everything under control: speed, revs, oil and water temperatures and fuel level. We need a dashboard in our car because we have to know our current speed to respect speed limits, to know how much petrol we have in our fuel-tank to decide if we can go to work without a trip to the gas station etc. All this data to do the simple job of driving! This is necessary because we need to take informed decisions.

white motorcycle cluster gauge
Photo by Mikes Photos on

What does it mean for our daily activities in a software department? We need our dashboard, too! How can we do our job of deliveing (not only writing!) a working software with the lowest bug count as possibile, quickly, on a budget and coordinating with other people? It’s a huge task compared to drive a car alone and yet many of us rely on instinct and guts to make decisions for an entire software team.

A dashboard for the software Engineer

Which indicators and gauges do we need as software engineers? I think there are a few things we Always need to know about our team.

  1. Team Cycle time: how much time/days does a unit of work take to go from started to completed? And with completed we mean delivered to the customer.
  2. Team Lead time: how much time/days dows a unit of work take to go from a created to completed?
  3. How fast are we going? How many story points we deliver every fixed amount of time? (sprint, week… name your favorite).
  4. Bug count. How many known defects (bugs) have we? Is the count increasing or decreasing?

Here we can see a dashboard created with Microsoft VSTS where the team can get an immediate report of the situation.


Create a dashboard

Every team is different and needs specific/custom dashboard. To create a dashboard with Microsoft VSTS we can go to


and then we expand the dashboard list with the arrow button (1) and click New Dashboard (2).

2018-08-03_14-02-31.pngWe give our dashboard a name and hit Create.

2018-08-03_14-09-48.pngWe can add widgets picking from the right-side list, search or browse the Marketplace to add something extra to our VSTS.


When we’ve finished to create our dashboard we click “Done editing”.


A dashboard is a must have to control or improve our team and our process. It enables us to understand our current indicators and shows if a new way to work improves or worsen the situation. With a dashboard we can take informed decisions about many arugments: current velocity of the team, quality of the software, lead time and so on. We’ve seen how to create and configure a dashboard with Microsoft VSTS.


Microsoft VSTS Docs:

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.


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.

Default settings of VSTS

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.


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.


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.



Reading – The Manager’s Path

I’m currently reading Camille Fournier’s “The Manager’s Path”.

It’s a practical guide to be a better manager in tech. The are some general management principles but it is very specific for the tech/software world.

I find it very inspiring and it makes me think about how I interact every day with my team: what am I doing wrong, what am I not doing at all?

What do you do to be a better manager today than yesterday?


Agile@School – settima lezione

Settimo appuntamento presso la scuola rodigina IIS Viola/Marchesini per il progetto Agile@School nella giornata di ieri 24 gennaio 2018. Si è giunti alla parte finale dove cerchiamo di mettere insieme tutte le parti finora studiate. Ci siamo dati come obiettivo quello di realizzare una semplice app per l’accesso a Twitter mettendo in gioco le conoscenze apprese.

1.png Continua a leggere Agile@School – settima lezione

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.


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!

The best tip on software estimation I’ve ever found

Count if at all possible. Compute when you can’t count. Use judgment alone only as  last resort. (Steve McConnell)


Count-first is the approach that Steve McConnell suggests in his Software Estimation book.

If you can count the answer directly you should that. […]
If you can’t count the answer directly, you should count something else and then compute the answer by using some sort of calibration data.

Reading about this approach makes me think about how I estimated things in the past. My job is changing and the tasks of estimating and scheduling are more frequent. I know that software estimation is hard and crucial for every project to succeed.

If you, like me, are having troubles on software estimation I strongly recommend Steve McConnell’s books “Software Project Survival Guide” and “Software Estimation”. They are like strong related cousins; you’ll be a better software project manager if you know how to estimate and you’ll estimate better if you know how a software project has to be done.

Una promessa in incognito

Valutare approssimativamente il valore numerico di una grandezza. –, Vocabolario online.

Quando qualcuno ci chiede una stima riguardo a quanto ci vuole per sviluppare, ci sembra che ci stia chiedendo un’indicazione approssimativa delle ore uomo? Abbiamo l’impressione che la risposta che diamo possa essere approssimativa? Che possiamo poi cambiare idea e rifinire la nostra risposta?


Probabilmente no. Aggiungerei poi che tale risposta potrebbe esploderci in mano quando lo sviluppo non avviene entro i tempi stimati. Perché? Perché quando un manager solitamente chiede una “stima” sta in realtà chiedendo un impegno o un piano per raggiungere un obiettivo. La distinzione tra stima, obiettivi e impegni è fondamentale per capire cosa è una stima, cosa non è, e come rendere migliori le prossime che faremo.

La stima è, rigorosamente, quello che dice il vocabolario. Un obiettivo è una frase che indica un obiettivo di business che si vuole raggiungere (es.: questa funzione deve essere completata entro il primo giugno perché la mostreremo in una fiera). Un impegno è una promessa di rilasciare determinate funzionalità con uno specifico livello di qualità entro una certa data. Una stima può essere lo stesso di un impegno, può essere più aggressiva o più conservativa. Non diamo per scontato che l’impegno debba essere uguale alla stima.

Molti dirigenti/manager non hanno il bagaglio tecnico per distinguere tra stima, obiettivo e impegno. Diventa perciò dovere del responsabile tecnico di tradurre la richiesta del dirigente in termini più specifici.


Uno degli ultimi acquisti in ambito di manuali: Software Project Survival Guide di Steve McConnell.


Conosciamo tutti Steve McConnell per il suo super famoso Code Complete 2.

In questo testo McConnell ci spiega come gestire un progetto software che richiede dai 3 mesi a un paio di anni. L’autore ci fa capire quanto alcune attività che dai manager mediocri vengono considerati sprechi sono in realtà necessarie e sane. Inoltre ci fornisce delle check-list di controllo e propone dei metodi di controllo.

Calza a pennello, a mio avviso, il paragone che fa subito all’inizio tra la piramide dei bisogni di un essere umano di Maslow e quelli di un progetto.




Se un progetto non riesce a soddisfare i suoi bisogni di sopravvivenza e sicurezza non sarà possibile raggiungere i più alti livelli di stato dell’arte del software.

È ricco di molti altri spunti di riflessione e mi senti di consigliare a chiunque sia coinvolto in progetti software (anche se non strettamente un programmatore) a studiare questo testo.