Have you ever heard about the Scaling Agile @ Spotify (or the so called “the Spotify model” or “the Spotify process“)? Well, I am not a big fan of it, but some principles, adapted to the different companies structures, have been adopted in most of the IT companies (if you read the document, you will find lot of analogies with your company, I am sure, even if we could argue what is just their way of working and what is generally the agile framework).

In this post I am speaking about the Squad Health Check model, I am not going through all the details and if you are interested, I strongly suggest to read that post. But hey, there are some differences that we put in place as part of adaptation to our needs. Firstly because in my company we don’t work in tribes, or at least, we don’t care and other tribes are not doing what we are doing, secondly because all the stakeholders of this model are part of the team. It is probably useful to speak a bit about that then.

When a team is doing the agile ceremonies, especially the retrospective, team members are usually not really preparing it. Therefore, it is strong the principle of locality: you add tickets on the retrospective boards that are related on the two last weeks of work, ignoring issues that are maybe more evident in the last 2 weeks, but that were becoming bigger and bigger in the last months. An example: we moved to remote working for the pandemic, and our inter teams communications have degraded quite a lot, making our teams becoming more like a silos. Still, nobody raised it during the retros, because there was no exact moment in which we thought about that as a huge issue to report in a retro.
Another important problem of retrospectives is that you don’t think at all the long term aspects of your job: is learning still happening? Do we have fun in doing what we do? Unless something critical happens, that gives a sense of peak of a problem or a success in one of those fields (like a very nice course that a team member did for the company), people usually speak about more ordinary aspects during the retrospectives.

That is the reason why I think that a Squad Health Check is really useful. It is a moment, that can happen quarterly, in which the full team is asked to think about the health of their work, focusing on general aspects that should cover all the possible problems of our type of work. In my team I took and extended the list used in Spotify, and the aspects are:

  • ON CALL: it is related to our 24/7 support turn. A low score means that our support is affecting our life and it is decreasing our quality of work
  • TEAM WORK: how it is working in the team, speaking with other team members, pairing, asking questions, having support…
  • HEALTH OF CODEBASE: this is related to all the code that the team manages, and if it has a low value it means that either the code is not well written, it is difficult to extend or maintain, it is too old and relaying on old libraries, not really readable or simple or well split into small functions or…
  • SUITABLE PROCESSES: because there are processes for everything (deploy, test, manage tickets, doing agile…), how much our processes make our work smooth. A low value means that either we have too much “bureaucracy” that brings no value and makes us wasting our time, or that we have processes that are complicated or error prone
  • DELIVERING VALUE: this is mostly related to the fact that developers usually want to work on new products, and that new products usually mean new revenue for the company. A low value means that the team members think that their work is not really useful for the company, either because it is mostly maintenance or because the new components are not used or they are used in contexts that are not important
  • LEARNING: because learning is always important, this measures if the team is learning something new. Our job is in constant evolution, if this value is low it may mean that the team member can feel that they are becoming obsolete in our market and they can have problems when they will work again on new projects
  • SPEED: agile is also about speed, but there may be dozens of reasons why a team think is not going fast enough. Classic issues are: too many useless/long meetings, processes, long times before agreed features are appearing in the backlog, lack of information in tickets, recurring context switching…
  • EASY TO RELEASE: in the ideal world, a feature that has been peer reviewed should be tested and go in production in few minutes with a CI/CD pipeline. But the World is not perfect, and processes and tools may have issues, or they may degrade, making the deployment process complicated. Developers want to deploy soon and easily, the lower this value is the further is the achievement of this goal.
  • FUN: well, it is work, but maybe we can make it more enjoyable, isn’t it? This aspect may mean using new techs for someone, or spending time doing code challenges for others, or having tea time once per week. No matter what “fun” is about, you want to have a bit of it in your office hours
  • PAWNS OR PLAYERS: A low score means that the team is feeling like a pawn with very limited space for internal decision, not too much democracy, executing orders, not having voice on discussions, on tech choices, on design of solutions… We should have a margin of freedom to do our work
  • TECHNOLOGY: sometimes you work in a team and you are suffering for the decision taken in the past to adopt a specific technology for a specific task. You know that there are better choices. But that’s it, nobody changes anything. This value represent the mood that team members have about the technology choices for the team components or for the organisation processes
  • COMMUNICATIONS: while the internal communications should be considered as part of the TEAM WORK, this value should measure if giving and receiving communication with external entities has the right quality. Are there (recurring) issues getting updates from (some/all) external teams? From business managers? Are the senior managers aware of what the team is doing?
  • SUPPORT RECEIVED: that should measure the quality of the support the team is getting from external entities. Is it prompt? Should it require multiple interactions? Are the team members being bounced from one team to the other due to a lack of ownership?
  • STRATEGY: this is a kind of bonus value. It should measure how well communicated the strategy for the team is, and how good the quality of this strategy is perceived. People does not want to have period in which they have nothing serious to do, and they are not feeling great if there is no clear strategy for their work in terms of next product to work on or importance of their future work

Now that we have defined a list of aspects that are most likely to be affected in the long periods, how to make the exercise to evaluate them? First of all, this is an impression that should follow the member feeling, not being a long thinking process. In an idea world it can be a quarterly meeting in which one by one the team votes those aspects. I found anyway that in meetings in which someone thinks it is not a good idea to be honest (yes, in the ideal team there is 100% freedom of speech, but in reality a huge problem of leadership is to have honest feedbacks from the people under the leader), those results may be tricky and the full process may be useless. IN GENERAL I would suggest that for 100% honesty, the vote should be anonymous and a great tool for doing that is to send a survey (I was using SurveyMonkey – their free membership covers a good number of response, even if you will have to split each Squad Health Check in two surveys – but any similar tool should work very well).

It is not important if the vote is 0 to 10, 1 to 10, 1 to 5 or whatever. But my suggestion is that, for each aspect, you give a numeric value and a value compared to the previous quarter. It is enough a value chosen from “improved“, “stayed the same” and “decreased“. This because the numeric value is usually taken as an absolute value (like “our tech stack is great, I will give a 9“) but we definitely want to understand the direction that we are taking (“in the last 3 months our tech stack is improved“). And NO WAY!!! Don’t make the mistake of asking a numeric value and then inferring if an aspect improved or decreased based on that!!! That would be an error for two reasons: 1. team members does NOT remember what they voted in the previous quarter, 2. People perception about one aspect may (slightly) change, but this does not mean that they don’t recognise the effort in improving it.
The second point is worth an example: a person can say “yes, we still use Java and flyway and those are great tool, I’ll give 7” and maybe the quarter before he had a bad mood and doing the same reasoning decided for a 6. But then he thinks “anyway this month we have introduced sonar, therefore our stack is improved a bit“. If you ask for a single value you would have not caught the sentiment of improvement and you would have thought that people thinks that tech is going down.

Who has to vote? That is a problematic question. For sure, with that list of aspects, all the devs. The question is: should the team leader vote? And what about the Product Owner? In my current team I was not voting, as team leader, it gave a better view of what the development team was thinking. The team was small, and my vote would have moved the bar. On top of that, in some periods I was not developing, and then for example my tech value would have been a bit random. For the Product Owner it is the same. With an additional issue: you cannot ask the PO to not vote aspects that are not related to him, if you are keeping the survey anonymous, otherwise… it is not anonymous for him. Obviously those problem don’t exist if the vote is done in a meeting, face to face. You can then introduce the “no answer” for those who want to skip voting.

Obviously at the end of the vote, the result must be used to decide or not if an action should be taken. The action should be a meeting to discuss degraded values, when the sentiment is worrying. In that case I would suggest, to protect also the fact that the vote is anonymous, to focus about solutions more than issue. It does not matter why the value is low, and to know why it is low you need to make the person who vote coming out. The important part of the discussion is about the HOW you can make that aspect great again, and anyone can answer to that, even people that didn’t vote for a bad value. That may generate a situation like a person not liking a tech, or a language, like NodeJS, and during the meeting another person says “in my opinion to improve our tech we should use Jenkins instead of teamcity“. Well, that will not solve his issue, but it will improve the tech stack if everyone agrees that that is an improvement. He can then ask for his language suggestion. Anyway, the purpose is to improve our way of working, if a person does not want to speak and a vote looks really affecting an aspect, better to have anyway a general chat about that, other people may have a negative opinion about that.

I found this a must-have as a ceremony in a team. I hope to have clarified my opinion.
Stay tuned!

Share