Background introduction
Regarding articles and related materials about Spotify, there are still a lot of searches in search engines. Then why do I still talk about it and talk to you about this topic. In fact, it is more based on some feelings in practice, because the author I happened to work in a company that tried agile scale based on the Spotify framework, and I saw the changes brought about by this model, but I was even more impressed by some "pseudo-agile" that look different from the gods. The current situation facing the company is that the proportion of outsourced personnel is relatively high, which undoubtedly increases the complexity of management. At the same time, there is a certain stock system that needs to be refactored and offline, and in order to meet market demand, it must continue to update products. Iteration; high management difficulty, heavy reconstruction tasks, and high market competition have become the three major problems facing the team. The most obvious manifestation is the competition for resources. The business team hopes to meet demand and deliver value as soon as possible, and the technical team must take care of it. The task of restructuring and repaying technical debt. Against this background, the company decided to learn from the typical practices of Spotify and try to change the status quo.
Spotify organization form
Regarding the background introduction of the spotify company, I won't repeat it here. Let's go directly to the topic and talk about the typical practice and organizational structure of Spotify. First of all, the author’s company hopes to learn from Spotify’s organizational form. The first step is to try to change the team structure to “squad” and “tribalize”. Here , it is necessary to explain the so-called teams and tribes, the smallest organization in the Spotify framework. The unit is a squad. We call it a squad. The squad can basically be understood as an agile team in scrum, including PO, ScrumMaster and Team. We hope that this form can achieve resource alignment, and every business area has tribes with it. Correspondingly, resource boundaries are clearer and communication is smoother. The characteristics of the team itself can be summarized in three aspects:
- stable
- Self-organizing
- Feature team
The so-called stability is the expectation that the team will not undergo major changes, because according to the Tuckerman model, each team has to go through several stages from formation, shock, regulation, maturity and dissolution. If a team has not been able to maintain stability, team members will come Come and go, the team may always be in a running-in period. At this time, it seems meaningless to talk about cultural construction, agile transformation, efficient cooperation, and learning organization, because you don't have the foundation for all of this-a stable team; and Self-organization is also a topic of "easy to say but not to do". As for the feature team, we hope that each team can deliver features independently. After the customer's needs are raised, the team can give the customer a satisfactory answer, and the function needs to be complete The most important thing is value, and the corresponding team form is to deliver a certain component. This component is of no value to the customer, because it can’t solve any problems. To get the complete product features, it depends on multiple teams. Collaboration, this kind of team is the component team. The concept of a tribe is a collection of multiple teams. The reason why they are defined as a tribe is because they have a certain relationship before, such as: they all deliver the characteristics of a certain business field; if there is a tribe, there is a tribe leader, we call him the chief , He is the person in charge of this large team and needs to provide support and guidance to the team. Back to the topic of company tribalization. First, the company organized training and trained core members to explain what tribalization is and what problems it can help us to solve. For example, tribalization can change products and R&D. For the "grasshopper on a rope", tribalization can solve the current situation of resource competition. After the training, everyone is full of expectations for this model, but what seems to be missing? Tribalization is good, but it must be based on agile, and how many of the trainees really understand the essence of agile, what does the agile manifesto emphasize? Do you not write documents? Still don’t need to plan? Forget it, the pace of scale has already taken.
Now that the vertical tribalization is done, it is necessary to talk about the horizontal connection of Spotify. Spotify has the concept of chapters and associations. The chapters are mainly based on roles or functions, such as the test branch. Although the testers have been divided into different teams and Tribes, but horizontally, they still belong to a branch, and the branch also has a person in charge. For example, the person in charge of the test branch is similar to the test manager of the traditional structure. The difference is that the person in charge of the branch will not have excessive management functions. To transport blood, he needs to recruit new members and constantly use various methods to improve the ability of testers. Okay, if there are problems, who should testers report to and who will evaluate their performance? The concept of the association is more based on interest groups, such as the Python Association, regardless of whether you are a java developer or a performance test engineer, you can participate as long as you are interested. I think this is a good practice, because everyone needs the opportunity to go. Learning what you are interested in and getting in touch with different friends is also a good way of team building in the long run. But this level seems to be abandoned in the company's practice. There is no interest group, because everyone has to focus all their energy on completing feature delivery. So this also leads to a very important culture of Spotify, a culture of innovation. Spotify encourages innovation very much. They can reserve time for each iteration to make innovative attempts, and even use a complete iteration to do innovative activities. We do not I have considered innovation because of too much demand and too busy work. This is exactly similar to the meaning shown in the picture below: a friend is looking for a key under a street light. Others will ask you why you are only looking for it here. Are you sure you fell here? He said he was not sure, but there is light here, I can see it, and isn’t it the same for us? We pay attention to the visible place, then we are always limited here, we are busy with daily delivery, it seems that we never have time to innovate, but when you try to look farther, the answer may be there waiting for you .
Our attempt
Spotify的核心价值观是：创新、激情、真诚、协作、好玩，如果只是简单的做部落化而不考虑背后的价值观，那一点都不好玩。所以笔者写这些内容并不是为了吐槽公司做的有多不好，而是把这个反模式写出来，如果您的公司恰好也希望借鉴spotify，那请先想好什么是重点。而我们发现这些问题后，也在努力解决这些问题。首先，我们开始试着让敏捷开始开花结果，我们开始做培训，不只是针对领导层，也不只是针对核心骨干，而是全员，我们期望大家理解敏捷的核心思想，我们通过看板做可视化，通过各种各样的信息辐射源促进透明，我们做兴趣社区，做敏捷交流小组，我们尝试多种方法开好回顾会，同时公司层面也开始推动DevOps落地。我们期望发布更容易，这样就可以实现频繁的发布，发布的规模也会变的很小，这样我们就更容易发布，也就形成了良性的循环。但是当我们不断的追求快速交付价值的过程中，却逐渐的忽略了质量，我们开始发现质量下降，我们开始不断的救火，所以我们很快进入了第二个阶段提高质量。提高质量似乎比快速迭代更难，我们从很多细小的点出发，我们梳理DOR，明确DOD，我们开始推动结对代码评审（因为结对编程领导不认可，只能退一步海阔天空），我们开始考虑测试左移。大家都明白，大部分的缺陷是在开发阶段引入的，但是大部分缺陷是在测试阶段的后期才被发现，甚至是在版本发布之后，而随着时间的推移修复的成本成指数级增长，所以我们期望尽早发现缺陷，我们开始提高单元测试覆盖率，我们开始推动团队做重构，以求得到更好的设计。我们也考虑测试右移，接入了更好的线上监控工具，开始做灰度发布，质量提升的工作还在不断尝试，整个组织也在不断成长。
还有很多话没有说
This article is just an introduction. I hope to share more specific practices, practices and experiences in the follow-up. Through the full text, you can find that I don’t have much introduction to Spotify, but more that we are referring to Spotify. After the transformation, the problems and countermeasures faced by various companies are actually the same. Any kind of framework is very simple to imitate, even if SAFe is a framework that everyone thinks is more complicated, spend some time and energy, and then ask an expert Give pointers and imitate things, but this does not seem to be the key point. The focus is on cultural change. Before the military and horses are moved, the food and the grass are first, and the transformation is not moved. The culture is first. It still broke the organizational gravity and changed the organizational culture. So now, we are full of expectations for the follow-up. We do not expect to reach a perfect end. What we want to do is continuous improvement. The road is still long, and it seems that this process is more interesting than the result.
