We talked about some ideas on how to think through and introduce your practice of agile. Now we're going to take a look at a couple of companies that have done this and a few things that we can learn from them. Let's start with Spotify. You may remember from the Spotify video that they started with Scrum and then they found that they wanted to discard some of those practices. Now, I won't even mention what they are because that's really not the point. Those practices might be a great fit for your agile team and wasn't a great fit for some of their teams. I think the important points are that they figured out how they wanted to do it, they saw how it was working, and then they iterated. Related to that, they also gave the individual teams a lot of freedom about what to do, something that you heard. So it wasn't like they said, everybody stop doing burn down, they just gave them discretion about what they wanted to do. And they mentioned how they achieved this sweet spot of high alignment and high autonomy. They talked about how the company sets goals for the individual agile teams and they operate within the contours of the overall company priorities. So I think as you kind of interpolate between the different things they say, it's clear they spent a lot of time with a very directed company vision about where they want to go. And then decomposing that into the individual questions of where and who and how they're going to execute that in a way that gives the individual teams a lot of discretion to be creative and make the most about what they're able to do as a team. And this is something that probably every manager aspires to be able to do, but is extremely difficult. And yet, it is a big focal point for agile, and something that I think you'll see in almost every organization that has a large-scale successful practice of agile. One of the last things I thought I'd point out from Spotify, is they talked about how they value cross pollination over standardization. Why do you think this even comes up, or they feel the need to say this? I think one of the reasons is that as an individual or manager, we want to build the perfect machine, we think if we can get it just right we can let it run into perpetuity. And I'm exaggerating a little, but I think there is that instinct, that desire on the part of individuals. And it's nice to think that we could build this perfect thing and we don't have to worry about it, but the reality is, we constantly have to be in this loop at looking at what's working and revising. And the only way that we'll achieve that is by allowing individual teams to try a lot of different things. And valuing that over extreme standardization across the organization. I think that as soon as you get to a standard that you feel isn't terrible, it will probably be, if you're having a good practice of agile, and individual teams will already be added date. So I think for a large scale practice, it just generally is impossible. Now, if you find that for really good reasons it's important to standardize something, then you should do it. But generally speaking, I think it's worth taking note of the fact that Spotify felt a need to draw attention to this as something that allowed them to scale agile successfully across many, many different agile teams. So, there are a few highlights from Spotify. Next we'll take a look at how this worked at Salesforce, another large company that implemented agile across the organization.