 So this presentation is about a case study on the Spotify model of scaling agile. So how many of you know about Spotify? How many of you use Spotify? All right. So Spotify is a music app similar to sovereign or gana.com in India. So it's a mobile-based app, as well as a web-based app, so where you can stream music. And they have extremely sound algorithms for streaming the music that you like. So think about an app, a mobile app, where you can basically listen to music, whichever you like, and it will provide you suggestions as well. So that is the beauty of the Spotify. So now, Spotify model has got nothing to do with streaming music. It's a model for scaling agile. So I think today you have heard about a number of models for scaling agile. Can you recall one of them? DAD, there are quite a few of them. And I think quite a few more will come as well. The reason is every software organization is unique and the same model may not apply for each organization based upon the way the software is built, based upon their environment, based upon their customers. So different models will apply for different situations. So in terms of scaling agile, you can either do top-down approach or do a bottom-up approach. So for example, if you are a small startup and then you start with a small team and then you expand and expand, then you create more teams. So that's where you scale agile bottoms up. Whereas if you're an existing company and you want to implement agile, so then you can do top-down with the directive from top management. So in the case of Spotify model, they started with a small team and then created more teams and they expanded the model. So now we look at Conway's Law. Conway's Law basically states that based upon how your organization is structured, that is how the system that the organization designs will turn out to be. So for example, three-tire architecture, you know, three groups, three layers, that's how the system turns out. So in the case of Spotify model, so you're looking at highly aligned and loosely coupled teams. So what is highly aligned? Basically, everybody is clear about the strategic goal. Everybody knows what they are supposed to do and what the company is supposed to do and what is their role in the company. So they're all highly aligned. The reason why they have to be loosely coupled is because you get less cross-functional meetings, less time spent in interacting with other teams, less dependencies. So this is the kind of situation where Spotify model will apply. So in the Spotify model, they have gone back to the agile principles and they are calling the team as squad. So what is a squad? So it's like a scrum, it could be Kanban, it could be any one of the models that are used, but they call it as a squad. And the squad has a squad lead as well as a product owner who gives ideas to the squad. So the size of the squad is limited to 10 and this is the basic unit of development at Spotify. So what are the squad responsibilities? As you can see, the squad has the squad lead, a dev backend, the dev app, the quality engineer, the PEM and the tech ops. So this gives you a good idea about what kind of team structure this is. This is a fully functional, responsible for the entire feature kind of team. And there are multiple teams like that. So the squad will own the conception, the design, the construction, the testing deployment operation scaling, the full top to bottom of the software delivery. Plus the squad lead will choose what particular model they want to follow, either it is scrum or Kanban or waterfall. You will also do some management activities such as PTO and no ticket assignment if that is a model that you use. So why we have this kind of model is that it gives maximum independence to the team and the team owns the whole product. So now we move on to a bigger organization structure which is called the tribe. So in the tribe, it is responsible for a major portion of the software, but they're all related together. So for example, a tribe can consist of three squads, two squads, even a single squad. Again, the size of the tribe is limited to 100. As we saw in today's speech, some of these sizes are based upon the organization structure and hierarchy and research that has been done. So sharing squad details. So the squad has to be as transparent as possible. So the reason is that everybody should know what the squad is doing as well as how the work of the squad is affecting their work. So for example, you want to make sure that the dependencies are minimized. So we need to make aware the actual work of the squad. So you can use any methodology, any software tool that will help you achieve this. So the reason is that we want to have a highly transparent and open system so there is no hiding of information and things like that. So cross-squad communication. So there is a daily meeting to list dependencies only for the duration of a cross-squad effort. So basically a squad cannot complete the entire software end to end. So there will be dependencies, but the software should be designed in such a way that the dependencies are minimized. So this is the way in which the company that I consulted with ensured the cross-squad communication is minimized. So the project managers were used to take care of this cross-squad communication and for scheduling meetings for the squad members. So this is a slight change in the role. So different companies can use different ways for taking care of this communication. So the Spotify model is kind of an open source model where you basically adapt the solution to fit your organization. So chapters and guilds. So yesterday we heard a talk from chapter lead of Spotify. So what is a chapter? So all team members from the same tribe who belong to the same function form a chapter. And what is a guild? So all team members from different tribes who are interested in the same function form a guild. So can you see what is the chapter and what is the guild here? Anybody? So the pink boxes that I have marked here are the dev web from the chapter. So they have a chapter lead and then the QEs, they are forming a guild. So basically they share information, they share the latest technological updates. They have a slightly different reporting structure. Again, it is up to your organization to change it any way you want. So the big question is, will it all work together? So you have, as you can see, you have a group of people all working on their part of the software. They take care of the full front to back, all the operations. And they are having very, as far as possible, very minimal communication across the squads. So do you think such a model will work? Well, in this case, actually it works because different squads are producing output at a different pace. Squads are dependent on one another. Each squad is the mini startup and competition among squads exists which helps the product development. So this kind of organization, which I talked about earlier, highly aligned and loosely coupled organization. So for those kinds of organizations where your software is constructed or architected in such a way that it is possible to have this kind of independence, then the model will work. For a squad is, the size of the squad is limited to 10, the maximum size. So if you require more work, then you basically split the functionality into two independent parts and then let them work together. So ideally you should have a single product owner for each squad, but of course it depends upon the situation. You may have a product owner who takes care of all the squads. So it varies based on organization to organization and the amount of work, like today we heard lots of information about the role of the product owner and how it should expand and how it needs more support. So based upon that you can see like what is the workload and how well prepared they are, what is your backlog and things like that and decide how to form the organization structure. So the solution. So the squad dependencies are identified and resolved by senior management and agile coaches if needed. So we need help from the senior management to achieve this. So the senior management has already made everything transparent. So the work of all the squads are visible to each and every squad, right? And if there is a dependency between squads, so we identify, okay, this is the dependency that we are facing. So let's try to resolve it as soon as possible. So that squad will take that as higher priority and execute on that. So these squads work to some extent is controlled by the business objectives as well as the technical objectives that the squad itself has. So it's a combination of both the goals. So it should not be like the squad will work on some features that nobody wants. The squad owns the product, but at the same time it is responsible for delivering the business requirements. So how do we achieve this concept of different parts of the software coming out at different times and how to take care of all those conflicts? For example, if you have a software that is installed, then you have to basically ship a CD to somebody or ask them to download. So it is a single package. So in such a scenario, how do you ensure that the software that is produced at different rates by these individual squads are coming out on time? So that is where we come to the concept of the release trains. So here we have this regular periodic releases at specific schedule. So what happens is you have a bi-weekly release for the entire product, not just for a small part of the functionality. So the entire product, the entire software product gets released every two weeks, every three weeks, every month. So the higher the frequency it is, the better it is for the squads to work together. Again, continuous delivery is another option. And the other trick that people use is feature toggling. Basically, for some of you are familiar with it already, it is basically enabling a feature based on license keys or versions. So that, for example, there is a squad A which is producing a feature A and then there is a squad B which is producing feature B and feature A needs feature B to work, but feature A is already ready, but feature B will come in the next release. So what they will do is they will release the feature A, but it will be hidden. So as a switch, it will turn it on once the dependent feature is available. So these are the ways in which we can control the output of the different squads and coordinating the output of the different squads. So team ability and autonomy. So this is one of the concepts that we want to give to the teams. So more the teams that are more autonomous are high ability. So those kinds of teams will find the Spotify model very exciting because you can have one squad which is working on Java, another squad which is working on C sharp, another squad is working on Node.js. So different kinds of technologies can be brought into the company and they can develop their own solutions. So again, they should have good, very high confidence level. So there should be not looking for instructions from higher management or the architect to say, okay, this is what you're going to do from now on. So they want people with initiative who will take up responsibilities and execute on them. Second thing is, is there any role for an architect in this model? Yes, the architect is kind of like a consultant within the team. So he will move from squad to squad based upon like the current need of the squad. So maybe this squad requires the help of an architect to complete a solution. Yes, the architect moves in and helps there. Similarly, for example, there is an external client or external some dependency which is not following the agile methodology. So there is a project manager who will help out in terms of ensuring that these goals are met at these delivery points. So this is a combination of both pure agile where we deliver the software when it is ready to fix a deadline model where you can say, okay, we have to have this feature by this date. So please put in all the resources. So it's a very flexible model. So it gives the autonomy as well as the ability for the company to provide the best results which will give the maximum value for the business. So what is the outcome? So the outcome of this model is there is competition among squads. So no squad wants to be the bottleneck of any other squad to solve a business problem. So for example, you have a squad which takes care of, let's say payments and then they are looking at to get some VMs. So there is a squad which takes care of providing VMs. So the moment you see a lot of requests going to that squad, then you realize, okay, so we need some resources in that squad to take care of this problem that the business is trying to solve. So the agile coach and the management has to check if there are more members needed for a squad. So for example, the requirement is huge. So the squad's responsibilities increase. So you can increase the size of the squad. Similarly, you can split a squad into two separate squads. Again, as time progresses, now the squad can shrink in its responsibilities because maybe the product is getting sunset or something. And the tribes themselves are much more long-lived. So they will be having three squads, four squads. They will expand the number of squads. They will construct, decrease the number of squads. But at the end of the day, they will still be responsible for a major portion of the software functionality. So how the tribe will solve this functionality using different technologies, different methodologies is up to the tribe. So here is the system overview when you have this kind of software that allows you to plug in releases at any time. So as you can see, you can mix the chocolate version one with strawberry version two and with butterscotch version three. So things like that can happen. So your software should be robust enough and your architecture has to be robust enough to accommodate this kind of flexibility in terms of releases. So this is the actual real-life model. So this is a case of an organization where it was following a traditional SDLC model and moving into a pure Spotify model where the freedom for the developers increases and the autonomy increases and their engagement also increased. So you can see there are different sizes of the tribes. There are some tribes with just one squad. Then there are project managers and business analysts which are who are embedded into the squad in some cases or in some cases they are outside helping a few squads. Again, as you can see a product owner is helping out two squads, two small squads whereas in other cases a product owner is responsible for only a single squad. So it's a very flexible model and it allows a lot of freedom for the company to organize the software. So here is the question then. So what about reuse? So what will happen if everybody is building different pieces of the software from the top to the bottom and everybody is recreating the same logic somewhere? So the idea is that some basic functionality or basic features should be embedded as or mandated from the management. From here is where the chief architect helps out a little bit. Says okay, these are the things that you need to take care and you need to adhere to in the system so that you are all able to produce something like this. So suppose you are going to build a cake which doesn't fit in any of these boxes then it will be very difficult to serve that as to the customers. So for example, so we say a restful JSON endpoint shall be the default so that things like that so it will be easier for people to communicate with the different output of the different squad. Again, there should be agreements between the squad. So if this squad is saying I own this part of the functionality and I provide you this agreement so whatever request that you make I will return the result within one second or three seconds and SLAs things like that they have to agree to. So it is pretty much like a small company within a bigger company so that there is a lot of independence for the team as well as the commitment from the team that they are responsible for that piece of software so the ownership increases. So here is the reference for the Spotify model basically it's an open source model so it was invented or discovered at Spotify and then it has been adopted in many various organizations and actually there is a small one pager in the book that you have been given on scaling agile along with all the other models that are there. So thank you, any questions? So can I ask questions? So how many of you think that your organization has this kind of software, the architecture system? So I would say for example, software which is more of a phasing website kind of software or mobile app kind of software that would be a software which would be ideally suitable for this Spotify model but if you have a lot of dependencies, agreements and contracts with the government and things like that that you have to ensure so that you don't fall out of the law then maybe this model may not be suitable because the model works in such a way that people are producing output at their best pace and they are very much engaged into the product and it's very hard for them to wait for different approvals and staging and things like that. So here is the ideal system overview. So to some extent as we move forward to the cloud and the source model, more and more systems will become like this where you have all these features available in different portions of the way and then their full feature teams where they take care of producing the entire piece of this trade, right? Well, the main advantage that we saw is that the engagement of the team increases so the team output is higher and then in terms of handovers, very less handover so basically any production issue comes along immediately the same development team takes care of the issue so the customers are extremely happy and then you will see new features coming out very quickly so for example, you want to have a newer version of payments, a new credit card or any one of these features that you can think of so all of those things will come out very quickly so the velocity is very high so the organization initially has about 100 people so 100 people who got into the transformation first so they were split up in, they formed the tribe and then they were created into separate squads and split into separate squads with squad leads and a lot of changes in the organization but from before where the software was not getting ready was getting delayed so the changes improved the availability of the new features of the software so that way it was a big advantage the challenges I would say in terms of one of the big challenges is how to evaluate the team members in terms of performance and other things so that is a big challenge that came up so some of the HR aspects have to be changed as well to say okay because of in terms of agile methodology these are the goals that you have and then you have to adhere to these goals which are basically our self-director basically the individual is asked to provide the goals that he would like to achieve so same way like the scrum says the individual team member decides what story he would pick up similarly the goals for the individual person is to be determined by the person himself and then it has to be approved by the manager so there is some level of standardization by the manager saying okay these are the goals the team has selected on average and then based upon that you will see like so okay this team member has performed well he has embraced the change whereas some team members who require a lot of guidance they would not be able to embrace the change so that is how you can say the main challenges in terms of the goals where basically in terms of software output as well as individual development so for example somebody would say I would like to learn F-sharp and implement the software in F-sharp and somebody would say I am going to do some DevOps activities so those kinds of technology challenges as well as responsibilities for different increased scope of the features so you say this is a complex feature so let me take this so those kinds of goals that came up and based upon the goals that we set and then the banding so to speak has to be set in such a way that the goals that they set and the expectations that they have or matching and then based on that the review happens so in terms of productivity see the main thing that was measured was basically the velocity but the thing is the velocity should not be measured across squads again as we see the squad is very flexible it is increasing in team members decreasing in team members so all of those changes had to be accounted for so for that a lot of one-on-ones were you know done to ensure that it is you know there is a alignment of the employee with the company's objectives as well as whether the employee is able to commit to the work that is expected at the same time is able to deliver to his commitment so those kinds of things were the ones that were decided you know the primary determinant for a performance so in terms of leadership style yeah initially it was a very command and control where the project managers desired who you know what projects to pick up and which project would add more value so there will be a lot of competition among the project managers saying you know my project has highest value so let's implement this project whereas now most of the value is the value is determined at the much higher level business level so the project managers have turned into more like let me remove the blocks it's more like helping out the team let me remove the blocks let me communicate with the client or let me communicate with the you know the non-agile folks so that they are all in sync so that is how in terms of the organizational structure that was affected so the initiative has come from the top management from the CIO himself and the CTO so they had primed the organization for this model for almost six months with the option to go for different types of coaching different types of models whatever they want to adopt so all the flexibility was provided so basically the management top management itself took a step back saying okay the only guidance we are going to give you is you are free to do this and this is your business code so that way the individual the goal setting happened not from top to bottom but from bottom to top well there are many people who didn't fit in into this culture who are more into you know let me stick to the old command and control model I would you know I'm used to this kind of style but there were people who adapted to the new style and you know got used to the new kind of responsibilities that the company expected them to do and in terms of people who were not able to adapt to the responsibilities they basically moved on to different opportunities so if you look at the structure so you have a project manager who is needed only if there is a dependency between squads or between the squad and external agency so project managers themselves have now become you know moving consultants they will be you know for three months with this squad ensuring that this objective is achieved and then they move on to a different thing so the project managers are like a flexible a part of the squad so the technology folks so basically the focus turns to the technology folks which leads to good engagement and better output so the focus is on the technology people to own a piece of software and wherever they need assistance they will be taking using project manager or the architect for different purposes so the main recommendation you can say from a 45 model is that the team has to be co-located so in case of you have a team so anyway there is only 10 people right 10 people is the maximum size of the squad so if you cannot co-locate them then you basically split them into two squads and have them all co-located but if it is absolute must that you should have you know the squads split in different continents for various reasons like supporting for example production issues squad so for that you will have all these daily meetings where you basically have multiple meetings with the squad which is located here and the squad which is located there so that way the coordination has to increase so there is a cost to having the squad split so in terms of coordination for example there was a case where a factory has to implement a hardware system and then the customers had to be told about that you know the implementation so the software team and the hardware team so they were connected closely with one another with the help of a project manager and then this project manager also had a project manager on the you can say the hardware side so there are two project managers who are interacting one between the hardware team the software team and another between the hardware team and an external team so they were in close contact so it is more like two project managers helping out in terms of the coordination and the messages that are getting transferred from the client to the software team so it wasn't basically giving directions okay you have to do this, you have to do that because basically these are our goals and these are higher priority and this is the deadline for us so there is an element of deadline because you know there are external people involved there so in those cases there were some you can say non-agile models were introduced because non-agile methodologies were there because you are putting a deadline saying you have to finish it by this point but for those you know urgent situations which are happening in any which can happen in any business so we had some external resources basically people from other squads come in and help out so ideally the main bottlenecks that were occurring was basically in terms of the machine's availability so we had different squads asking for different VMs because we want to deploy each of these services into different VMs so there was a positive of resources to take care of that situation so it's a work in progress and so I think it's mentioned there in the slide that it is it is not a concrete model that has worked in that it's up to completion but it is like a work in progress so we are identifying all these bottlenecks and removing the bottlenecks for example in terms of the VMs it has been the rides have been transferred to the squad leader himself so that he can create the VMs that are necessary for the squad again there is a lot of you know give and take because if you create more VMs then it becomes more expensive whereas you know business wise but software says you know you have to have as many VMs as possible so these kinds of decisions are made to some extent given the freedom to the squad leader to some extent by the business manager thing feel free to you know use up to this limit and if you need more just come and ask any other questions so the main thing is each squad is responsible for its own unique functionality so for example logistics would be one squad's responsibility then suddenly there is an external demand from a client saying okay from tomorrow onwards I'm going to charge you 10 percent more or 15 percent more suddenly you have to you have new work which is going to save the company billions of dollars at the same time your squad is very lean and they are already working on some next priority in a higher priority system so those kinds of situation basically is coming from the business value that is gained from this particular feature implementation so for example we discover a new a competitor introduces a new product which we can also introduce very quickly but if you wouldn't introduce it we would lose a lot of revenue so those kinds of business situations urgent requirements lead basically the management to say okay these are the priorities for us because of the value into the business so okay so we have a slight tweak here basically we planned such and such situation but the situation has now changed so let's see who can help out in this they mainly basically based on for example the architect himself is like a consultant within the tribe so he would immediately join in and help out and then he would also you know identify other members who can join and help out so those kinds of judgments are left to the technology team but the business decision is coming from the business manager who says we have a higher priority here so let's focus on it so this is basically building known product so hopefully it was very informative alright thank you very much