Category Archives: team

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.

definition-of-done.png

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 Pexels.com

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.

2018-08-03_13-46-49.png

Create a dashboard

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

https://THE_DOMAIN/THE_PROJECT/_dashboards/

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.

2018-08-03_14-11-55.png

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

TL; DR

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.

Reference

Microsoft VSTS Docs: https://docs.microsoft.com/en-us/vsts/report/dashboards/?view=vsts

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

 

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 Continue reading

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!

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)

imagesKKBBN896.jpg

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. – Treccani.it, 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?

incognito-modalità

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.

Sopravvivenza

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

photo_2017-03-26_15-18-31

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.

photo_2017-03-26_15-28-29

 

photo_2017-03-26_15-28-34

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.

Tu non fai la differenza

Come nasce un software? Facile. Lo scrive un programmatore, appunto, programmando. È quindi il programmatore che fa la differenza se il software è buono o meno. Giusto? Io rispondevo sì finché non ho letto quest’articolo su un gruppo software della NASA.

Non siamo noi programmatori che facciamo la differenza.

È il processo.

È il processo che crea un software, che decide come il software deve fare qualcosa, che ne scova i bug e che è pensato per migliorare continuamente. Le persone sono degli esecutori di un processo. Il software sarà buono tanto quanto lo è il processo. Il software e la numerosità dei suoi difetti sono rispettivamente l’output e la misura della qualità del processo.

Le persone non devono essere creative quando scrivono software, devono essere creative nel pensare un processo.

Può essere un punto di vista che annienta il nostro ego, il nostro sentirci creativi e potenti quando programmiamo: almeno in parte io mi sono sentito così. Ma noi programmatori dobbiamo smetterla di pensare che è tutto merito nostro. Non facciamo la differenza e il codice che scriviamo è pieno di bug. Perciò dobbiamo pensare e contribuire a un processo che ci salvi dai nostri stessi errori, che li prevenga e che tuteli l’intero team di sviluppo. È questa la differenza tra chi fa software “tanto per” e chi lo fa seriamente.

Un appunto. Il gruppo di sviluppo del software per il sistema di bordo dello Shuttle non fa le nottate a programmare. Iniziano alle 9 della mattina e finiscono alle 17, gli straordinari sono rari. Sono persone normalissime con famiglia e figli. Magari con 8 lauree e 2 Phd ma a parte questo sono l’antitesi dell’hacker o del programmatore che i media ci propinano. E loro scrivono software perfetto.