Archivi categoria: peopleware

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…

Hard work does not pay off

Today I was chatting with a friend about working late hours and he said that he has to much to do and he’s stressed.

This piece from Olve Mundal in 97 things Every Programmer Should know came to my mind.

As a programmer, working hard often does not pay off. You might fool yourself and a few colleagues into believing that you are contributing a lot to a project by spending long hours at the office. But the truth is that by working less you might achieve more — sometimes much more. If you are trying to be focused and ‘productive’ for more than 30 hours a week you are probably working too hard. You should consider reducing the workload to become more effective and get more done.
This statement may seem counterintuitive and even controversial, but it is a direct consequence of the fact that programming and software development as a whole involve a continuous learning process. As you work on a project you will understand more of the problem domain and, hopefully, find more effective ways of reaching the goal. To avoid wasted work, you must allow time to observe the effects of what you are doing, reflect over the things that you see, and change your behavior accordingly.
Professional programming is usually not like running hard for a few kilometers, where the goal can be seen at the end of a paved road. Most software projects are more like a long orienteering marathon. In the dark. With only a sketchy map as guidance. If you just set off in one direction, running as fast as you can, you might impress some, but you are not likely to succeed. You need to keep a sustainable pace and you need to adjust the course when you learn more about where you are and where you are heading. In addition, you always need to learn more about software development in general and programming techniques in particular. You probably need to read books, go to conferences, communicate with other professionals, experiment with new implementation techniques, and learn about powerful tools that simplify your job. As a professional programmer you must keep yourself updated in your field of expertise — just as brain surgeons and pilots are expected to keep themselves up to date in their own fields of expertise. You need to spend evenings, weekends, and holidays educating yourself, therefore you cannot spend your evenings, weekends, and holidays working overtime on your current project. Do you really expect brain surgeons to perform surgery 60 hours a week, or pilots to fly 60 hours a week? Of course not, preparation and education is an essential part of their profession.
Be focused on the project, contribute as much as you can by finding smart solutions, improve your skills, reflect on what you are doing, and adapt your behavior. Avoid embarrassing yourself, and our profession, by behaving like a hamster in a cage spinning the wheel. As a professional programmer you should know that trying to be focused and ‘productive’ 60 hours a week is not a sensible thing to do. Act like a professional: prepare, effect, observe, reflect, and change.

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.



Only the code tells the truth

Treat your code like any other composition, such as a poem, an essay, a public
blog, or an important email. Craft what you express carefully, so that it
does what it should and communicates as directly as possible what it is doing;
so that it still communicates your intention when you are no longer around.
Remember that useful code is used much longer than ever intended. Maintenance
programmers will thank you. And, if you are a maintenance programmer
and the code you are working on does not tell the truth easily, apply the
aforementioned guidelines in a proactive manner. Establish some sanity in the
code, and keep your own sanity.

– Peter Sommerlad (from “97 things every programmer should know”)

3+ ways to try to be a better team leader

You did it! Now you’re in charge.

You are the team leader of your deparment. Now what?

It’s hard to be a leader. It’s even harder to be a respected one.

How do you earn the trust of your teammates? How do you know if they respect you and if they will follow you? These are the questions that bothers me every single day.

I’m far from being the team leader that I would like but I try every day to be as good as I can and to improve just a little bit; to be this week a little less worse than the previous.


I have 4 rules that I try to follow (and sometimes I fail).

1. Don’t criticize, condemn or complain

This is the first principle of Dale Carnegie‘s How to win friends and influence people. Try to not criticize when someone do a mistake: we’ve done mistakes so many times that we’re no-one to elevate ourselves and judge other people. Instead we try to understand why that kind of mistake was done and find a way so we can learn from that and possibly do not repeat the same thing in the future.

This is the hardest rule, to me. When I’m upset about something or when my mood is not so good this principle is very hard to follow. I try to have an open-minded attitude and to be patient.

2. Give Honest, Sincere Appreciation

This is the second principle of Dale Carnegie. I know: Dale Carnegie influenced me a lot.

People need appreciation like air. We cannot live today with the air we breathed yesterday. If a member of the team has done a good job we say thank you and appreciate what has been done. The appreciation is better if specific and precise.

There is a catch, though. We must mean it; really mean it because otherwise it’ll come across as flattery.

This is my favourite rule. I’m excited to give appreciation. I like to say bravo when someone does something good or on time. Being on time is hard so it has to be recognized. I like to appreciate skills that I don’t have, too. It makes me glad to be part of diverse team with many skills.

3. Help the team

As leaders our main goal is to help. Help can spread across many activities: explaining things over and over again until they’ve been understood, doing pair programming to solve a hard problem, doing a phone call to a coworker to ask if everything is ok. We also help the team by organizing a better way to work, to avoid distractions and to be more focused.

4. Apologize early

We all do something wrong. As leaders we are the example to follow and when we do mistakes (and we do a lot) we must be humble and apologize as soon as possible and with honesty.


This is my set of rules that I try to apply every day. Some days are good, some days are worse.

I think that, at the end of the day, the most important thing is to work in a positive environment where feedback is encouraged and errors are recognized as occasions to improve.

What do you do every day to work better your teammates?