Archivi tag: DevOps

My first month at Engage

Time flies.

One month ago it was my last day at Microsoft. It seems like it was forever ago.

Now I work at Engage IT Services, a small Italian software house that develops a sport betting platform.

I work to learn and as I started to understand that my passions were shifting from coding to people, teams and processes, I understood that my role at Microsoft was no longer a fit for me. A friend of mine, Alessandro Alpi, co-founder of Engage IT Services, told me that his company was facing a challenge as the business grew very fast during 2021. We had a dinner together and he offered me a job to help him shape the future of the software engineering practices of his company to meet new business needs. From teams management and interactions to promote new testing practices within the company: there’s a lot of work to do.

The “jet-lag” from Microsoft to Engage hit me quite hard. From a huge company (>100.000 employees) to a small one (<100). From a “services/consultant” profession to a product team. In so many ways this reminds me of MadLab, my first job.

I thrive in a product team because it’s where things are built and as an engineer and developer, in my heart, I love the process of building things and delivering into production. It’s here where I spend hours looking for ways to improve efficiency, software reliability, testing, reduce waste, improve communication between teams and the list goes on.

In a couple of weeks we reorganized the way we visualize and manage the day-to-day work scheduling with a kanban board and the benefits were immediate. Forgotten bugs, requirements and features were hidden. Now, we see. Power is nothing without control. This took courage and determination because we’re in rush to meet business needs for a new market for the company; but we were ruthless and completely changed the way we manage work. That was a very good first month.

So many challenges are ahead and new skills to learn…

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

GIT LEZIONE 3 – git reset: soft mixed hard – cosa fa


Devi annullare delle modifiche? Devi ritornare a uno stato precedente? Git reset è un comando molto potente che permette di tornare indietro e riscrivere la storia.

I 3 tree di git

Per capire git reset cosa fa, dobbiamo avere ben presente i tre “tree” di git.

  • Working Directory – La cartella di lavoro
  • Index – Il contenuto del prossimo commit che verrà fatto.
  • HEAD – Puntatore al branch attivo.

Git reset –soft

Questa è la prima variante del comando reset. Questa opzione sposta solamente HEAD al commit indicato col comando.

git reset commitid --soft

Git reset –mixed

Questa seconda variante è quella di default, quando non viene specificato altro. In questo modo git opera anche sull’INDEX. Viene quindi eseguito quanto fatto nella variante SOFT e in più viene riportato INDEX al contenuto del commit scelto.

git reset commitid --mixed

Git reset –hard

La terza variante, –hard, aggiunge un ulteriore step a quanto fatto dalla –mixed. Git opera anche nella working folder, riportandola al contenuto del commit indicato.

git reset commitid --hard


How to configure access policies to Work Items on Azure DevOps

One of the strengths of Azure DevOps is that it’s very scalable. It can be configured to work for company of all sizes: from small teams of a few people, to a large enterprise with thousands of users.

When we work in complex environment we should follow the best practices to choose how to organize people and projects on our Azure DevOps Organization. This is a great piece of documentation to get started when we work in an enterprise scenario and I recommend reading it.

A general (but please double check if it is suitable for your environment) guideline is to work inside a single project and create many teams.

With this kind of setup is common that customers ask me to provide a way to limit visibility of work-items. This way only some people could access some work items. This is to provide better focus to teams, for example. But your project could have other needs to do this.

Continua a leggere How to configure access policies to Work Items on Azure DevOps

Deploy a new IIS Web Site with Azure DevOps Pipelines

I was experimenting with deploying a completely new Web Site to a machine with a brand new IIS installation to see what are the required parameter to do a basic deployment.
I share here my findings.

Continua a leggere Deploy a new IIS Web Site with Azure DevOps Pipelines

GLV OnAir Febbraio 2019 – Video Link

Qualche settimana fa GLV ha trasmesso il suo episodio di GLV OnAir di febbraio 2019. La puntata è andata in onda col solito formato di 3 sessioni da 30 minuti ciascuna che elenco qui di seguito:

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.



Agile@School – episodi otto e nove

Si è concluso oggi il progetto Agile@School presso l’IIS di Rovigo che ha coinvolto alcuni studenti delle classi quinte indirizzo informatica.


Il post di oggi riassume gli ultimi due incontri (l’ottavo e il nono) dove abbiamo portato a termine un’app con Xamarin Forms per accedere a Twitter come output finale.  Continua a leggere Agile@School – episodi otto e nove

Agile@School – sesta lezione

Sono ripresi oggi gli appuntamenti all’ITI F.Viola / Marchesini di Rovigo di Agile@School dopo le vacanze: siamo al sesto episodio su dieci. Come ripromesso negli episodi precedenti abbiamo ripreso in mano dei principi Agile/DevOps che negli ultimi incontri erano stati parcheggiati in favore di approfondimenti tecnologici su Xamarin Forms.

Continuous Delivery

Continua a leggere Agile@School – sesta lezione