 Thank you. Welcome to my talk. It's an agile team. Just have people. I'm Simon Cohen. I work at Spotify But before I worked at Spotify, she mentioned I'd worked at other places and one of the places that I worked at We had a team of engineers where I was also an engineer and we were doing a bunch of different Stuff that had some agile practices in it like with their continuous integration. We had unit tests We had some pairing. We have many different practices, but we didn't use any of the teamwork practices They would see scrum or any of those things none of us on the team actually had any experience with it and Except for one guy and this one guy he had a lot of experience with teamwork and agile practices and he Really pushed us to try and Implement scrum and do any one of those practices. We always push back or like we don't need any of your stuff You know, we're productive. We're putting stuff into production. Everything's working. Well, we have testing. We're you know Doing XP practices. Why do we want any of that hippie stuff that you're talking about with all this scrum and all these extra Meetings and all these extra talking about stuff. We don't want that but he kept chipping away at us And eventually at some point he got us to agree to try something and The thing he decided he wanted us to try was daily stand-ups That was the part of scrum that he wanted us to start with so we agreed He said all right. Well, we'll run this for an experiment. We'll do it for a little while and see what happens so every day for a Few weeks we would stand in a circle kind of like that and we would usually stand in the same place relative to the other people because of where we sat in the room and We would go around and we would check in and talk about what we had done the previous day and what we were gonna do that day and We would do that every day for a while Then at one point this one day the data scientist that would usually stand to my right It was his turn to talk and he just he stepped back and he held his forehead and he scratched And he was thinking really hard trying to explain what he had done the previous day Eventually he stepped back into the circle and he said I'm analyzing data and he took the baton It just gave it to me and I took it and I'm like, oh, okay Well, I was working on the same data set that he was I was cleaning it He was actually knowing what to do with it, but I was like, uh Yeah, I'm analyzing data to pass it on to the next guy and then the baton kept going that way And you can imagine that basically for the next two weeks or so. That's what happened with the rest of the team It just evolved into yeah, I'm analyzing data. I'm writing code. I'm testing stuff and that was it It took us about four weeks until the whole experiment of introducing scrum or any other agile practices for the teamwork Completely failed and then we stopped doing that and we never talked about it again so that's how I saw agile practices being introduced as a failure and it wasn't until I had joined Spotify and I was a year into my term at Spotify that I was sitting on a deck kind of like this in California on vacation and I was reflecting about that year that I had spent at Spotify and I was wondering what had I learned What did I know from working at Spotify for a year that I didn't know when I was working at that other place Well, we tried to introduce agile and failed and I thought you know I'd be really interesting to try and capture everything that I learned and try to maybe kind of share it Because people really like what Spotify does and a lot of people from outside of Spotify. They don't really know what it looks like So I kind of set out to sort of write a letter to myself a kind of message in a bottle through time To send to pre Spotify Simon with the capturing of like hey Here's what you're gonna learn after you will have worked for about a year at Spotify and Here's kind of what I've learned And I first came into Spotify During the team the first thing that I started working with Immediately what I saw was a lot more structure a lot more process than I'd ever seen The first thing that I saw was something like this. You can see there's Trello board She probably all familiar with and this is something that we would start using at Planning sessions start seeing there were this notion of planning sessions We would sit down every sprint about two weeks for an hour and we would talk about what we were going to work on and we would populate the to-do column and then during the sprint we would move stuff from there to do into doing and Move through that process. So that's a bit of a con bun flow But inside of the scrum because we're doing some scrum bun kind of like mixing it up We don't really adhere specifically to how we do things So after the planning you see stand-up now you can see here There's a gross violation of stand-up rules people are sitting down, but I guarantee you it actually works And we go through everything that we've talked about you know the usual stuff in stand-up What did you do yesterday? What are the blockers? What are we gonna do next and then we move on? We have retrospectives at the end of every sprint we talk about what went well what didn't go so well and What were the learnings and things that we kind of picked up along the way that info into these other two categories? Pretty much every retrospective at Spotify follows those three categories in general. There are other versions of it But that's that's the main stuff All right, so Yes, but why you're probably wondering I know about scrum I know about combine why you tell me about all this stuff Why am I here instead of out there drinking some really nice filter coffee or chai or at that other talk that sounded Really interesting, but I came here Well, that's a great question because when I sat down to think about That year at Spotify. I was really wondering what happened in the first team that I worked out where agile failed We try to introduce it and you fail. Why did that fail? Why is it working at Spotify? So well So one of the real issues I had is that there's a sort of minimal set of practices that you have to have It's the minimal set of things that if you want your team to actually succeed And you want the team to actually observe that there's something useful in doing this you need to have these put in place You can't just put daily stand up and go that's it. It works and Through that thought process. I also realized that one of the things that's missing a lot for me And I think was missing conversations. I was having even at Spotify was trying to understand Well, why does it work? Why do I need more than just stand up? Why do I need the planning session? Why do I need the retrospective? What do I need all these things? What's the minimal set and why why does it actually work? So Do you want to know why? Can I get a hell yes? All right, good. So at the core of every high-performing team is this concept This is the very very foundation What we do is you're learning and you're learning to get better This is what we need to do because one of the things that a lot of people Look at teams and they go like okay This is a high-performing team and they put a label on it and that's not actually accurate because the high performance is not a static label It's not like I have a team the high performance put the label done high performance is a dynamic label It varies with time even high-performance teams have Chuffs and they go down in performance and they go back up and what they're basically doing is they're adapting Because every team in every situation that we have in life has to adapt because the environment the external circumstances are always changing and Us as humans what we figure out the way to actually Adapt is by learning you observe what's happening you figure out what's changed and then we change ourselves so that we can adapt to the Environment that's what we're doing and the best way we know how to do that is to learn So high-performance teams at the very very core what you will see them doing is they're actually learning They're actually observing their environment. They're actively scanning to see what's going around them And they're using that to learn how to improve them so So what's a good way to actually learn? Well, there's this concept called the PDCA cycle first thing to know them about it It's a four-letter acronym which is fine because it's not a computer science term So it can be four letters and it's also it's a cycle and that's kind of important You'll see that throughout my talk that cycles are kind of the key thing to think about the PDCA cycle itself Is basically for repeatable steps first thing that you do is you plan? The next thing that you do is you actually do what you plant then you check to see Did the stuff that I do actually produce the results? I was expecting in my plan and Then at the end of it you act or you adjust some people use it as a just instead of act that adjustment is saying Or I'm gonna take everything I learned from having done and then checked on it And I'm gonna feed it back into my next plan. That's the basic idea And you're probably all very familiar with it In how it looks is scrum. The first thing that we do was how the planning session in the beginning of our sprint That's our plan for the PDCA. The next thing that we do is we'll actually do the sprint That's the do part of your PDCA Next step after that is a retrospective. This is where we check sit down with the team and we look how well did we do How close are we to the sprinkle? Was the sprinkle effective? What do we think we learned about what went well? What didn't go so well? How do we want to adjust to the next step and that's actually what you're going to get in the next one Which is capturing the learnings and actions from our perspectives and you feed them back into the next loop and normal stuff that you see around these kind of things to be changing whip limits changing behaviors for the teams changing sprinkles Anything what I want you to see here is that scrum itself at that level that sprint work is basically a PDCA cycle That's what we're really doing scrum itself the reason that it works though the engine behind it Is is it's a learning tool beyond everything else might in it's really just a learning tool PDCA In and of itself is a Is actually rooted in the scientific method and the scientific method looks like this First thing that we do is we ask a question and then we set up a hypothesis Think something will work this way The next thing that we do is we experiment with it We actually go out and we run an experiment and all we do in the experiment itself is we're collecting data This is if you look at it is really the due part of your PDCA cycle We ask my hypothesis of the plan the experiment is to do then you move on to analyzing the actual results We're looking at it. Okay. I'm gonna look at the results of the experiment that I ran Look at all my data and then with that analysis I can move on to actually conclude whether I reject my original hypothesis whether I accept it And then I can feed that into the next set of questions to the next hypothesis So when you look at high-performing scenes you see the stuff that happens in high-performing teams It's part of that for example when the ones that are going well and the ones that are working well They are actually doing things that will come like that it part of their scrum It's part of the regular basis of working they are doing lots of experiments for those of you are here for the previous talk This is the same kind of concept constantly running experiments We're constantly trying stuff and then we're checking on it And we take conclusions of the learns we have from what we checked we feed it into the next cycle And we keep getting better and better over time so That's kind of the idea of how PDCA works along your scrum Now we can play a short little game There's actually a secondary PDCA cycle that happens inside of the scrum and The little prize anybody thinks they know where it is raise your hand Anybody any idea where there's a secondary PDCA cycle that occurs in our regular sprint work that man wins the prize Throw you a little catch it Close enough. All right, that's true So Daily stand-ups actually it's a little bit tricky, but what daily stand-ups do is they actually start the PDCA cycle at the checkpoint First thing we do is we get together in the day for do the actually there you stand up and we're checking What did we do yesterday? What's changed? How did it go? Are there any blockers? Where are the pull requests of Terra Terra next thing we do is we act Maybe we decide that we need to unblock. Maybe we decide we need to move something from doing to done Okay, once we've done that we make the plan for the day. We take new stuff from the from the to-do column or Planning or whatever name of the column that you have if you're working with a kind of con balm Flow and then we move it on into doing and then the doing is what we actually do for that day in the next day We go through it again Now what you're seeing here is basically one of the main differentials between Waterfall and agile waterfall is about predictive planning I make a plan with an intention to try and predict what's going to happen in the future as much as I can whereas in Scrum and an agile what we're really doing is we're creating adaptive planning and the daily stand-ups are really a way to Constantly adapt to what's happening at the micro level The scrum is a slightly bigger level and then there are even larger cycles that happen inside of every company Happen inside of spot as well. It could be quarterly. It could be yearly It could be any length of time that you need and what I'm trying to show you here And what I want you to take away is that if you look at a lot of these cycles and a lot of these processes that we have We basically wrap them inside of a PDCA cycle What happens when we do that is that we're actually creating a learning environment around every cycle that we have So almost everything that we do effectively generates learning and we're very very kind of anal about it Making sure that we're always going through and checking and checking and checking whenever we have projects that maybe took six months long We'll have massive retrospectives. We'll spend a lot of time looking at that So the idea is that you want to be able to look at the organization You want to find where you have cycles you want to be able to? Wrap them in PDCA's so you can actually learn there's one other part about this That's really important to understand is that PDCA says is that you need to start by planning just like the scientific method you need to start with hypothesis a Lot of places you will see in a lot of times even at Spotify You see people that don't actually start with that they just go when they do stuff and they try and experiment a lot And that's very good wisdom. However, there's an advantage to actually setting out with an explicit hypothesis and The example is this if I think that I found a problem something that I want to change something I want to do in the system or my product or whatever it is and I go and experiment Great thing could happen is I try something and it works. Awesome. I saw the problem What if I try something and it doesn't work? Well, what you usually see is people say then you go and you do because analysis you figure out what went wrong Okay, well, you could do that and you figure out what went wrong and then you do that again to try and sell the Problem you still didn't solve it. Why? Don't know would cause analysis do it again do it again and again and again and that will work But that's basically trial and error and the problem with trial and error is you can keep trying it And who knows when you're gonna actually find the right solution You will eventually probably because we're smart people will figure it out The difference between that and the scientific method is that we're setting up hypothesis We actually have an idea in a theory of why something should work and when you set up hypothesis in the beginning of any PDCA cycle and then at the end of it You check on it. You get this extra nice benefit. She say I didn't get the result. I want it Why was it was it because I didn't do the experiment? Well, did I fail at implementing what I thought I wanted to do or did I not analyze the situation properly? Maybe I didn't look at it. Maybe I thought the problem was here, but I really had problems here So now you have the ability to separate and ask yourself an even better question How well am I doing and analyzing my actual situation? How good am I at actually implementing solutions? Those are two very different things and by actually setting up hypothesis up front You can actually learn a lot better. You won't spend as much time on trial and error You'll be able to also improve how you actually analyze your situations. So that's kind of important and in terms of practice What you ever you do make an experiment That's kind of the only thing that I can say about this if it's a cycle wrapping the PDCA Whatever it is that you're doing and people have said it here Just try it if you can set up a hypothesis up front set up a hypothesis Don't spend too much time on it But at least have some and I some idea of what you're aiming for and why you think it's going to change Whatever you're changing in that direction So whatever you do Try to make it an experiment that that includes spring work that includes You know trying out new behaviors for your team that includes Whether or not dogs should be allowed in the office. It's all good. It's all available for experimentation. I'm sorry Explicit hypothesis spring goals themselves are usually specific hypothesis We think that we're going to be able to move this metric and we're going to do that in this way So those those can actually be used if you frame them in the right way with a crude definition of done You can actually use spring goals as an explicit hypothesis. I'm hoping that answers your question Yes, you can you can use that the main the main point of trying to create the explicit Hypothesis is as I said is you want to capture what you thought was the actual problem Or what you thought was a situation because you want to separate What happened in terms of I did all this work, but did I screw up the work or did I do the work? Right, did I screw up the experiment if you're thinking like a scientist you have to screw up the experiment, right? Or did I screw up analyzing what the situation was? Because then you just different responses to both of those situations And that's the actual value that you get by actually experimenting and by being a scientist by thinking about that So you want to be able to create this Good question Great, you're probably thinking we're done. That's it right well scientists. It's great We have high-performance team into the core that our learning will adapt to anything anybody throws our way We can just go out there now and it's all great. Well, no, it's not that quite that simple Maybe I told you I was sitting on that deck back in California long long time ago I was also sitting on a deck and reading this book This is a book that proves the phrase of don't judge a book by its cover. This is an excellent book It's called leading teams. It's written by J. Richard Hackman who was an organizational psychology researcher That wrote this book sort of as the culmination of the work that he had done over about 50 years five decades in that field of organizational psychology research and This book is all about teamwork and he had done work in many many different fields from airplane carriers and Hospitals You name it every other type of industry you can think of manufacturing all of it and the stuff that he puts in this book It's really talking a lot about the theory of what makes for a great team And that's the theory that kind of applies across any field and of course also applies in software development in the agile world that we live in Now what Hackman talks about is this concept of effective teams. Well, I'm highly effective teams We usually talk about highly performant teams. He talks about highly effective teams Now that actually brings up a really good question. It's a difference between effectiveness and efficiency Well in the agile world a lot of the stuff you see us talking about has to do with efficiency We talk about velocity. We talk about throughput. We talk about our deadlines We talk about all the estimates that we're going to put on cards or no estimates We're going to put on cards. There's a lot set up about that and efficiency is really really important however, efficiency is only one dimension of actually being highly performant and Effectiveness is something I think maybe a little less is said about in terms of teamwork Not in terms of product in terms of teamwork and that's something that I want to go through a little bit more in detail luckily we have a quote from Peter Drucker who was an American management consultant and he says this Efficiency is doing the thing right Effectiveness is doing the right thing So as you can see here, that's kind of a big statement, but it's a really important one So if you think about it, if you're working really well and you have no losses, no waste, nothing Everybody is at 110 percent efficiency But you're building the wrong thing Doesn't matter No, it doesn't you won't get any results you're building the wrong thing if you have the most fuel efficient car in the world and You're driving to the wrong destination Doesn't help So that's the extreme case. So let's talk about not the extreme case of where most of us live and we'll use a metaphor Suppose we're all going on a hiking trip now and we have this kind of backpack That's our backpack and we're gonna go away for a week Quite a bit of time. We're gonna need a bunch of food This is our packing list Kind of like our backlogs. It's really long. It's really big What do we do? We have this problem. We need to pack stuff. It can't fit. That's the backpack we have Right, we can try and increase the size. It's not gonna happen. There's only so much weight You can carry. All right, this is it. This is the backpack. We have this is the trip we're going on How do we do this? Well, the most obvious way that you can start with is like I'll pack as many small items as I can get in there Turns out maybe that's dried fruit. Great. Now I have a backpack full of dried fruit Is that gonna sustain me for a week of hiking in the Himalayas? Probably not. I need more nutritional value. I need protein. I need carbohydrates. I need fiber I need fat. I can't just live on dried fruit for a week while I'm hiking in the Himalayas So I need a different way of doing things So usually what we're doing is then we try and max, sorry, we try to like max, maximize our Efficiency by mixing different things of different sizes so we can get everything that we want. That's what we're trying to do There's a different way of, slightly different way of looking at it and asking yourself the question is When am I actually trying to do here? What's the problem in front of me? Well, the problem in front of me is I have a fixed-size backpack, right, certain capacity And what I'm trying to look for now is the stuff that I can put into this backpack for this one week That's gonna give me the best solution for weight that I'm carrying for the volume that it actually takes up in my backpack And for the nutritional value and that's the key part about it You want to see that you get the nutritional value that you want from that volume and that weight So what you're really kind of looking for are these things these energy bars which are by the way available here in India And these energy bars are actually the solution to that problem They are the highest density in the lowest weight For the best nutritional value. In theory, you could spend an entire week with a backpack Full of just these, not even full, that's the great part about it, right? This is what these energy bars are kind of trying to do. They're trying to give you the nutritional value that you need for the entire ride In terms of our backlogs, this is kind of What it means to try and be effective about what we're going to select to work on. It's not just about how many cards can we jam into the next sprint We're really looking for these energy bars. We're looking for the ones that we can put in there They're gonna actually create the largest amount of yield, the largest return on the work that we put in and the yield can actually be looked at in some way as the amount of value returned over the time spent. And that's that's the idea in those kind of selections. Now in terms of what it looks like in practice for teams This should look very similar to what you already know because there is a lot that's said about effectiveness in the agile world around product management There's Lean, there's Toyota Cata, there's Value stream mapping. There's a million things What they boil down to and what you can see at least also in Spotify is one of the things that we do pretty much all the time is to try to visualize all the things. Visualize all the things because what we're trying to do is we're Trying to capture the stuff that we're talking about outside in the world. Our brains are actually better at being able to look around and once we put stuff around Visually in front of us. It's easier for us to activate more parts of our brain to actually be able to make Comparisons and make sense of our world. It's just how we're set up and The reason we visualize other things part of the reason that is because what we're trying to do is we're trying to actually sort them Trying to like figure out what they what they are and what makes sense. What order we put things in So pretty much most of the time in terms of the heuristics of what we're doing is we'll visualize everything think about trailer boards They're a visualization of the work that we want to do But then we're trying to just sort Those things for the top-end things that matter to us for example and could be your whip limit for the sprint It could be other things in other examples like in retrospectives. How many actions are you actually going to work on? Right, you have to choose you can't have all of them if there's 50 actions You're not going to implement all of them So you have to sort for them first you visualize them then you sort for them and one example of an anti-pandemic that I've seen people do You say they can have backlog grooming sessions that go on for two hours every sprint because they go through 45 things in the backlog Over and over again trying to sort them and update them. It's not important It's not important because the next thing they're going to do is only whatever that whip limit is at the top of it So once you have your new top once you have they say you're three or four or five or ten Items at the top stop sorting. You're done for that sprint move on That's actually the point that I want to make here save the rest for later Don't worry about it. That's the idea of prioritizing. That's what it needs to be effective with time Remember what we said is efficiency is about how well we use the time that we have and effectiveness is about what we're using it for What is it going to be used for so we have to prioritize, you know It's in order to know what we're going to use our time for and that means the last thing which is you have to get into the practice of letting things Fail, that's the point of prioritizing when we prioritize we say here's what's important and that means that the other stuff is not as important and That also means the other stuff can maybe probably fail That's what we're saying and that's okay to say it because if everything is important then nothing is important So you have to look at that and you have to say to yourself as I'm doing this as I'm prioritizing This is what's important for now or for the next sprint or for whatever time period and everything else may be important May not even be relevant by the time we finish the sprint or by the time we finish this quarter and it's okay if it fails because We figured this is more important than the rest and if we get this done and the rest failed We know that at least we got the most important stuff done. That's what you're looking at That's what the order was well also said the nine tenths of wisdom is being wise in time Effectiveness is all about thinking about how you're spending your time This is a thought process. It's a bit meta and it's another practice of habit that I'm trying to Have you see here? That's really important if you're spending your time thinking about how you're spending your time That's good. You also have to think about then another level of inception of meta How much time am I spending thinking about how much time am I spending all right? You don't would you sit down for five days and do a planning session for a two-week sprint? Probably not maybe you'll do an hour. Maybe you do five hours. You have to figure out what's right for you based on the task So that's that's what you have to constantly be thinking about am I spending the right amount of time Figuring out what I should be doing So that's the point I'm trying to make here is be effective prioritize prioritizing Now we've talked about those two aspects of being a scientist of learning and being effective We also need to ask the question then what do effective teams actually look like? When you see one what do you actually see well luckily Hachman actually talks about that and he has the three traits of effective teams That's in the book that I mentioned in leading teams and they start with the first trait which is Teams that are highly effective serve the clients well these traits are things that you're going to observe About the team if they're highly effective you will see that they are doing this you'll be able to observe them So serving their clients well as the first one second one is they continuously improve and the third one is The members of the team find personal development and fulfillment from work Many of you are familiar with the three P's what you're looking at here is product process people That's what they basically sum up to so let's go through them one by one for clay Serving the clients well That's defined by Hachman as the teams output meets or exceeds the client standards This is actually kind of a key point to understand your team itself Cannot define whether or not it's doing a good job Just cannot do that that doesn't work. They can't tell if they're doing good quality work or not That's based off of Hachman's work. That's based off of academic research So who can define if your team is doing a good job or not? teams clients Whoever is consuming the output from the team if the teams producing documents specifications shipable code Mobile applications it doesn't matter whoever is on the other end of it who's consuming the output of your team They get to define if your team is serving them well or not They get to define the quality level of the work of your team So you want to have that in your mind and examples of doing stuff like that is user acceptance testing Which is the most obvious one because it's right there You go to your user and users says if it passes this level it meets my standard And then you go ahead and you hack on that and you're done every time your code runs and it passes to your acceptance testing It means it met your clients standards So that's kind of an obvious one a be testing is a maybe slightly less obvious one But how do you know if you're serving your clients? Well when you were building a mobile app and there's millions of users you can't ask millions of users to give you Acceptance tests just not gonna happen So you a be tested it's part of what you can use a be testing for you actually look for ways to get Feedback from your clients and whether or not the stuff that you're building something they want to use So it's another example of that And of course you can just ask And the infrastructure group that I've worked in spot-a-five the last couple of years We do a lot of that we send surveys we ask our clients We try to find out what they're doing and what they think we asked them what sucks the most about our infrastructure We keep getting feedback for them to find out where they think we are where you think we need should be and how our quality is So the next part or the next trait is continuous improvement and Hackman defines that in the book as the team's social processes for doing its work Enhance the team's ability to work together in the future It's a big big statement. There's a lot in it. I highlighted the words that I thought were kind of important We're focusing here in improvement for the team around the social processes That are trying to make the future better for working together better. That's what you're looking for So this is about how people are working together in your team But the orientation is towards the future. This is not about tactically How do we get this print right now or this meeting right now to go better? That's just the right now what you're trying to do with continuous improvements. You're trying to help the team Do meetings better do sprint work better as a whole it's a statistical move That's kind of a mindset you have to be thinking about that and examples for continuous improvement The things that you do for social processes are Collaborating looking at the team and seeing highly effective teams will be collaborating They'll be supporting each other people in the team will support each other somebody's struggling somebody needs help They'll go on they'll help them maybe pair program with them. They're giving feedback to each other That's a great thing to see in teams and by the way, we don't see enough of that at least in the teams that I've worked with Holding people accountable is also a very very good one This is about you said you were going to deliver this and you didn't show up We need you to do this or you're blocking my my pool request. I need you to unblock me This is holding people accountable and it's a very important habit to see so you can see that people in your team The team itself is not blocking for too long where people are actually changing their behaviors in a way That's actually making the team work better if you collaborate better So that's all around continuous improvement in the next part that we're going to go to Personal development. These are actually going to be anti patterns I'm going to talk about and what you look at highly effective teams And you don't want to see in a highly effective team, but you do see in a lot of other teams So the first one is senior over junior senior the people are more important than junior people They get the really interesting tasks and the junior people and not so much to get the scraps Okay, that's not good Because people are not going to be happy. You want people all the people in your team You want them to feel like they're developing you want them to feel like they're actually continuously proving themselves You want them to feel they're fulfilled So stratifying your team is saying senior people get this good work and junior people are getting like all the other work And when they get to be senior, they'll do that. It's not a good incentive. That's not going to work You want the whole thing collaborating on everything Next thing you see is secrets and rewards. Sometimes you have individual Incentives or compensation methods like bonuses etc that are driving people towards the wrong kind of choices And that would look like stuff like I'm the expert on a team on Jenkins Jenkins breaks all the time So I'm indispensable to this team can't fire me You got to keep paying me a lot of money because without me your team is not going to deliver anything And I'm not going to teach anyone because I have the secret and I have the knowledge I don't want to share that's another big anti pattern for the personal development and for the fulfillment of everybody in a team Because it stratifies the team. It actually makes everybody compete with each other Instead of people Collaborating with each other because there's incentives there. I either get a better bonus Well, I get to keep my job. I have job security. Whatever it is, of course never shipping That's kind of a big issue if you have a team that you see around that over and over again It's failing to ship or the stuff that they ship doesn't get used because their projects get destroyed or they get Defunded or whatever it is. That's going to be a problem over time People on that team are not going to feel fulfilled because you have to close that feedback cycle I write something ship it people use it I get some kind of feedback if people are not getting that feedback Then you're not going to see people who are happy and eventually you'll see high attrition. They're going to leave that team They're going to get frustrated. So solutions around that usually go back to things like MVP You want to like start cutting scope as much as you can to start creating feedback cycles that are meaningful to people Where they're actually shipping stuff that gets used you have to start looking into those kind of examples Those were the three traits that we that I just mentioned which were Serving the clients well continuously improving and personal development and fulfillment. What do all these traits have in common? If you look at them those three traits They're all actually cycles That's kind of an interesting thing because serving a client's well isn't something you do once and you're done Neither is development of fulfillment fulfillment by definition is cyclical like we said It's a feedback group and continuous improvement also by definition. It's something that always is happening So these are cycles. What do we do with cycles? You wrap them inside of PDCA Why because then we learn how to do it better. We learn how to get better at serving clients We learn how to be better at continuous improvement And we learn how to be better at having people who are happy and joyful and working and developing themselves and getting fulfillment from work That's what we do when we see cycles. How have we done that at Spotify? That's kind of an interesting twist on what I learned in that year working as pop actually now. It's two years when I wrote this This talk we added people and This is this is kind of interesting because what we've done actually with our Spotify model Which I hope you are familiar with is that we've created roles that are very specific First of all I'm talking about is product owner product owner serves clients. Well, that's their role their role is to Nurture the trait in teams that says these teams are serving their clients. Well, they are delivering on time They're delivering the things that matter to the clients. They are actually they're Doing the job that matters to the teams clients So there's a person whose responsibility is to nurture this trait of an effective team The next one is an agile coach. The coach's responsibility is to make sure that the team is continuously improving That's their job. That's what they're there for The last one is chapter leads. These are line managers and their job is to actually make sure That the members in the team are developing and that they have fulfillment in their job So as I've shown you here now, we've taken the three traits and we've actually split roles That are responsible for nurturing those traits in every team Then what we did is we made a team out of that leadership team Because we're all about teams and collaboration and we call that team the pocklock team, which is the PO chapter lead agile coach team the pocklock team is responsible for nurturing all three of those traits and There's overlap between all three of those roles when you really start to think about it and there's also this section in the Venn diagram where they completely overlap and where they completely overlap is where the pocklock team really works as a team and that's where all three of the Roles come together and they try to improve the team's work At every aspect of it now this this is kind of an interesting Part of the Spotify way of doing things is because in a traditional organization You usually have one team lead one manager that person is responsible for all three of these things they're responsible for delivery as a product owner and for the clients and getting all the Conversations going on with them. They're responsible for the team improving because they're the team manager and then they are team They're also responsible for the line management for the individuals And what you usually see and I've done this myself because I used to be a traditional team lead Is that you have to make these decisions on a regular basis where you have to think about all those three interests at the Same time and you have to figure out which one's more important Guess what happens? Almost every time where you have to make a decision on your own about which one of these three is more important You're gonna end up choosing delivery Just because that's the primary thing You're gonna feel like you're held accountable for and it's the most immediate thing if you fail to deliver this print People will notice if you fail to improve in this print if you fail to develop people also who knows It's not very visible so what ends up happening in traditional structures is that that one person that's responsible for the team has to manage the the tension between all three of those interests and Usually it's hard for them to see their blind spots the incentives are set up wrong And there's what it's just gonna be much harder for them to make sure that the team is doing the right thing over time so What is it that I want you to take from here This I want you to take that We saw the Spotify by having three distinct roles and we have multiple people doing it We have multiple chapter leads sometimes per team not just one It's usually only one product owner and one agile coach, but we can have multiple chapter leads and that's definitely happens often But you don't need to switch to the spotify model at all What you should do is you go home or to your office and you should look at your organization And you look at the roles and you look at the people and you ask yourself What do I need? Who are the people that I have in my organization right now or what roles do I have or do I need to create? Such that I can actually nurture all three of those traits And I want to be able to create a situation where there's more than one person who's responsible all three of them because what I want is I want the interest to be made explicit in conversation between people I want the product owner to have a damn good argument why this time around we shouldn't try to improve the team Not why shouldn't we let them fail this sprint so they can learn something important or Why is this print more important than a bunch of people going on a training session? That's going to give us a payback over time You want those conversations happening outside of one person's brain? So even two people is good enough co-getorship is great product owner and then somebody else and they be responsible for just The coaching or for like line management or whatever it is. That's another common structure I want you to think about it. I want you to make it your own And I'm going to give you one example of how to think about this a little bit What we see here is a basketball court. This is a game. So what can we see here? What do we actually observe? There's players. They have different jerseys. There's a referee. There's the hoop There's the audience What else do we see here? There's a coach somebody who has put that What's what's noticeable about this coach? First thing that we notice about this coach is he's wearing a suit Why is he wearing a suit? I don't know maybe he means business. I don't know but he's wearing a suit So the other thing that's really important is the coach is standing by the sideline a Sports team coach never plays the game when the game is going bad You don't see the coach take the suit off put the jersey on go in and stop playing the game It doesn't happen Why is that because the coach's job is to stand outside of the game and observe? That's what the coach is doing We as humans are not as good at being able to multitask at the same time to play the game and to also Be observant of what we're doing. It's much much harder and you're not as good at it as just Totally playing the game being totally immersed in it or being stepped back and look again and just observing When you think about the roles that coaches have in sports teams, they're usually paid for the team not winning one game They want the team to win the whole season. It's not one sprint They want the team to win the whole thing, right? So that's what coaches are there for when you're thinking about who's gonna do coaching How they're gonna do coaching or what kind of coaching I need you're looking for that You need somebody who's not playing the game in terms of software development not playing the game means I don't stand in the path of critical Delivery, okay, I'm not in a critical path. Sorry of delivery so product owners can't do it because they are accountable for delivery and Your engineers may or may not do it depending on how you structure it But if I'm writing code and I need to make the choice between writing code or helping the team improve and Observing how code is written? Critical path of delivery is always gonna win. I'm gonna end up writing code instead of delivering So think about it think about it in terms of sports teams. It's one aspect to think about I want you to take from that last point is be nurturing foster those three traits go back to your organization Think about it. Look at what's going on and make sure that you do that so Capture everything I said in this letter to myself Dear Simon, here's what I want you to know One be a scientist experiment to learn To be effective prioritize prioritizing. It's all about time three be nurturing foster the three traits For take the Spotify job. It's awesome. It really was yours truly the future. Thank you Could you please explain the spot if I spot if I word Is you're using I'm not able to get that the spot by what take the Spotify job What does it job? Oh the last one? It's just it's just because this is a letter from My future self to my past self. It's just if you want to learn how to Have highly effective teams during Spotify. You can see a lot of interesting stuff Trying to kind of work on it You mentioned about never shipping products or never the teams who are never shipping things. Yeah So what would you suggest for the teams who are into that situation? So what I suggest is doing your best to cut scope And doing your best to find a way to have impact in what you're doing on a shorter cycle. So My experience has been that a lot of times when you see people not shipping It tends to be things that either the team is stuck in Kind of waterfall mode. They're like we have to get all the data before we can go and we can make a decision We have to architect the final solution before we can go and do something. That's like one one example Which happens from within the team and you have to work with team to be able to Do fast iterations and to be able to cut down what you're doing to start producing something that comes back and gives you a little bit more Experience there's a good exercise for that. I Think he's available on the internet. It's called elephant carpaccio Which you can do with an elephant carpaccio Which is basically the idea of taking a very big thing and slicing it into really really small pieces And it's a it's a facilitated exercise that you can run with your team When done well that exercise really gives you a visceral experience of oh That's why we do agile that makes sense because it's it gives you that it Take something really big you go through it and it changes the requirements halfway through and it teaches you that if you're gonna sit there And you're gonna try to architect an entire system and build it for the next six months Things are gonna change in those six months and your architecture is gonna fail And then what usually happens you get like really really clingy to the architecture that you had three months ago And you can't let it go Doesn't work. So that exercise is a pretty good exercise to run with the team especially if they have never seen agile or if they're and if they kind of fell off the agile Horse and they're like, yeah, they need to get back in there Of course, if it's the it's the other side if your issues are systemic An organizational because of other problems you're working on the wrong projects or whatever it is Like they're gonna be funded or you know, you're working on something that's never gonna get shipped That's a very different issue that you need to like then take outside of a team and you have to work with the rest of the organization to find Even smaller things whether they're tangential or parallel or how to take that actual project itself and change it So you can get some small wins You have to start the the actual feedback cycle of people shipping something that they know has meaning to somebody else