As described in my previous post (Research & Development – The Spotify Model) we recently discussed the Spotify Model and various changes and improvements we could apply to our internal team organization.
During our retrospectives two recurring problems popped out:
We started brainstorming, formulating some proposals that should help in mitigating our weak points. After the inspirational lessons about the Spotify Model, we decided to internally re-arrange our team organization. We cannot apply the structure Spotify proposes because of some obvious differences between our team and theirs. In any case, the schema described in the Spotify Model was a good starting point for our new arrangement.
In order to solve our organizational shortcomings, we decided to divide the team into two independent micro-teams (squads). Due to the fact that we are a team of eleven people and that NetEye requires deep knowledge of a vast set of technologies, we believe it’s just not possible to create two squads that can work equivalently on the product. So we decided instead to organize them around our main competencies: one will be more focused on developing and maintaining Icingaweb2 modules and issues related to the frontend, while the other one will work more on third-party software integration and backend development. On top of these two groups will be the Team Leader and the Software Architect who will help us keep in touch with our stakeholders and product managers, as well as in organizing issues for future sprints.
In this new approach, each sprint is composed of two independent issue lists, one intended for the first squad and the other for the second. Once two separate sprint lists are created, it’s easy to imagine that each member will sit in only on the planning meeting related to the list prepared for his/her squad. These meetings should then be shorter because we will have fewer issues to estimate in each one, and the planning should be easier since each squad’s available Story Points are much more likely to be dedicated and optimized for activities related to their competencies. At the end of the two meetings, we will conduct a joint wrap-up meeting in order to give to each team member a solid overview of what will be handled during the next two weeks.
In any event, we believe that sharing knowledge and experiences is also important across the two new squads, and we believe that flexibility should be the key point in our team. This means that some meetings will be still conducted all together, like our morning stand-ups and retrospectives. These are good opportunities for sharing ideas and asking for help. In addition, we will try to enhance team competencies by trying to internally solve issues that will require skills complementary to those the team already possesses, leading us to organize pair-programming sessions across the two squads.
One idea that we stole from the Spotify Model is the concept of a Guild. This can be another way for sharing passions and knowledge, and even keeping in touch with people that work outside the R&D team. We started with an IT security Guild, and more other ideas are coming …
So far only two sprints have passed since we re-organized the team. Some advantages are pretty clear, but we believe we can still improve. We cannot be sure yet if this new method will fully solve our difficulties, but we know that if we fail we will surely learn something new from this experience (as the Spotify Model suggests).