Archivi categoria: kanban

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

 

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