Archivi tag: team

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 – Seconda lezione

Anche questa settimana si è svolto l’incontro del laboratorio Agile@School all’IIS Viola/Marchesini.

Stand-up meeting

In questa seconda lezione abbiamo applicato subito uno dei concetti affrontati la lezione scorsa: il feedback per incentivare il miglioramento continuo. Ne abbiamo approfittato per introdurre lo stand-up meeting che viene svolto da molti team. In questi minuti di  incontro “informale” in piedi abbiamo provato a raccogliere sensazioni e pareri sul primo incontro. Dopo un primo momento di silenzio qualcuno ha detto il proprio parere:

  • Alcuni hanno definito l’incontro più interessante del previsto, in particolare è stato trovato interessante il concetto di team e la sua gestione;
  • Qualcun’altro è stato colpito dalla potenza della visualizzazione del lavoro tramite una kanban board;
  • Uno dei professori ha riferito che i principi base riguardanti DevOps sono molto interessanti.

Ho provato anche a incentivare feedback negativi ma nessuno si è sbilanciato. Per ora 3 feedback positivi sono un buon risultato, avanti così!

Sempre per esercitarci sullo stand-up meeting abbiamo anche accennato gli argomenti che avremmo affrontato nel pomeriggio e quelli della prossima lezione.

Slack

Per prendere confidenza con gli strumenti di collaborazione più diffusi ci siamo inseriti nell team Slack agileschool.slack.com. I ragazzi si sono trovati subito a loro agio senza problemi. Useremo Slack per passarci esercizi e il materiale che di volta in volta riterremo necessario.

Pull-Request

Tornati seduti abbiamo lavorato con VSTS per esercitarci con le pull-request. Gli studenti sono stati suddivisi in team da tre persone che hanno lavorato su un semplice esercizio con un’app WPF già preparata a cui apportare piccole modifiche. Alla fine del lavoro si chiedeva un’approvazione tramite PR agli altri membri del team. Con alcuni team ci siamo scontrati con problemi di merge. In alcuni casi li abbiamo risolti, in altri non ce l’abbiamo fatta per motivi di tempo.
Ad ogni modo mi sembra che il concetto e a cosa servono le pull-request sia stato ben capito.

MVVM

Come ultimo argomento abbiamo introdotto le basi dell’MVVM, il noto pattern a tre livelli per strutturare app che verrà utile con Xamarin Forms.

Abbiamo svolto un esercizio che ci ha fatto mettere le mani e vedere funzionare i meccanismi alla base di questo template e in particolare ci siamo concentrati sui Binding.

L’argomento non era di certo facile ma l’impegno da parte di tutti è stato notevole. Era bello vedere come chi aveva concluso tra i primi poi spiegava o aiutava agli altri, questo è lavoro di squadra!

photo_2017-11-30_23-03-04

Alla prossima settimana!

 

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!

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.

Striking the Kanban bargain

Kanban richiede al team di sviluppo software di negoziare diversamente con i suoi business partner. Perché? Perché di solito la gestione di un progetto fa promesse basate su: obiettivi, tempistiche e budget. Dopo un processo di stima e di pianificazione, vengono assegnati un budget, delle risorse, un insieme di requisiti e la pianificazione è decisa a priori.

Kanban negozia in maniera diversa. Kanban non pretende di fare una promessa basata su qualcosa deciso a priori che è molto probabile che nel tempo cambierà. La tipica implementazione Kanban include degli accordi che ci sarà un regolare rilascio di software funzionante, probabilmente ogni due settimane. Agli esterni interessati viene offerta completa trasparenza sul funzionamento del processo e, se vogliono, visibilità giornaliera dei progressi. Allo stesso modo viene offerta l’opportunità di selezionare le attività più importanti da sviluppare. La frequenza di questo processo di selezione è probabilmente più frequente di quella del rilascio – tipicamente una volta a settimana.

Il team offre di fare un ottimo lavoro e rilasciare la più grande quantità di software funzionante possibile. Offre di fare miglioramenti continui per migliorare la quantità e la rapidità di rilascio.

Kanban non offre un impegno basato su una certa quantità di lavoro rilasciata un certo giorno; offre una promessa rispetto i service-level-agreement per ogni classe di servizio. Il tutto è sostenuto da un impegno a rilasci regolari, trasparenza, flessibilità e lead time ridotti. Un sistema kanban che funziona correttamente mantiene un impegno alle attività che creano vero valore per il cliente. In cambio, il team chiede una relazione a lungo termine in cui il team di sviluppo si sforza costantemente di migliorare il livello di servizio.

Il tradizionale approccio della consegna con obiettivi prefissati, scadenze e budget è indicativo di un rapporto “una volta e via”. Implica che non c’è relazione con i business partner, implica un livello di fiducia basso.

L’approccio Kanban è basato sulla nozione che il team starà insieme e avrà una relazione a lungo termine con i propri business-partner.

Traduzione della sezione “Striking the Kanban bargain” di “Kanban” di David J. Andreson.

image

Che ne dite di una build ogni ora?

La maggior parte di noi non lavora su progetti giganteschi ma chi ci ha lavorato assicura che compilare un sorgente il più frequentemente possibile porta molti vantaggi.

  • Minimizza i rischi di integrazione: uno dei più grandi problemi di un progetto in team è il merge dei sorgenti quando le persone hanno lavorato troppo a lungo in maniera separata. Sforzarsi ogni giorno di creare una build ed eseguire degli smoke test aiuta a contenere gli errori di integrazione;
  • Riduce il rischio di scarsa qualità: eseguendo dei semplici test sparsi per il programma si previene l’insorgere di grossi problemi legati alla qualità;
  • Rende facile l’analisi dei difetti: se la build del giorno n-esimo si rompe, è facile risalire al problema confrontando le differenze da quella del giorno precedente;
  • Migliora il morale: vedere un prodotto che funziona, anche se fa poco, aiuta a mantenere alto il morale del team.

Secondo Martin Fowler integrare frequentemente i sorgenti porta cambiamenti anche nel modo di approcciarsi al proprio lavoro da parte dello sviluppatore:

Frequent commits encourage developers to break down their work into small chunks of a few hours each. This helps track progress and provides a sense of progress. Often people initially feel they can’t do something meaningful in just a few hours, but we’ve found that mentoring and practice helps them learn.

In questo modo si tende ad approcciare il proprio lavoro in maniera incrementale, in piccoli step che ogni giorno aggiungono qualcosa (anche se poco) e ci si assicura che quei progressi si integrano correttamente con quegli degli altri.