In the previous post of this series dedicated to VSTS we talked about continuous integration. Now we’ll talk about publishing our Web-App hosted on Azure with the release management tools provided by VSTS. With this kind of tools we can deploy the latest version of our web-app to Azure in complete automation removing manual procedures and human errors. The setup of Azure will be covered in another blog post.
Let me tell you how addicted to urgency you are. Do you have notifications enabled on your phone for WhatsApp, Slack, Email, Sms, Facebook, Twitter? Do you read a notification a few seconds after you heard it? Then you’re an addicted to urgency. If you’re not this blog post is not for you.
The first thing you have to know about productivity is that the less you do the more you can do. Dropping things is the number one way to scale and feel better at the end of the day.
Saying no to things it’s hard but it’s even worse to delay our very important deadlines and schedules.
Turn off notifications
When it’s “hammer time” turn off your phone notifications and ringtone and never look back. No one is going to blame you if you don’t answer to that e-mail because you were focusing in the exact thing you’re supposed to do. Your main job is not to answer e-mail (unless you’re a manager?). Turn off notifications of Skype, Outlook, etc: everything in your workstation.
Free your mind
When something comes up to your mind while you’re working write it downquickly in a place (post-it is the best) and then go back to what you were doing. This will free your mind from thinking about it and look at the collection of post-it you’ll have created later. Some things that seemed so important in that moment are totally useless and you’ll throw them away.
In this blog post we’re going to configure a build process in VSTS to enable continuous integration for our ASP.Net Core example web-app. Continuous integration is a powerful technique to prevent merge-hell and improve quality on the “left” stages of our software production process. In the fast-paced world of development we want to merge into the main line of development the new developed features as soon as possibile to avoid open branches that will cause painful merges. If we keep our unit of work small and focused we’ll have great benefits.
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.
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 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.
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.