Tony: Yes, that’s right.
Shane: Tell us a little bit about yourself and about Skype’s Agile Transition.
Tony: Sure, so started with Skype just over two years ago now and before that I was at IBM, I led some of the transformation, co-chaired the Agile Leadership Team around Agile in IBM for a couple of years. Before that I worked at IBM out of the labs and before that I run two Start-ups and sold two Start-ups, so that’s a little bit about me, and then the Skype pieces: Skype’s been on the Agile Journey now for a number of years, I came in part way through that, sort of half way through I guess, still on Journey, and that’s where we are right now.
Chris:Yes, for most of my career I’ve been a Delivery Manager, so I’ve been using Agile since about 2003 but mainly as a user of Agile rather than as a coach, and Skype was my first job as a change agent, if we want to call it like that, and I was quite surprised of what was required of acoach, I always thought that it would be teaching people Scrum and Kanban and it didn’t turn out to be that way.
Tony:Sure, I think one of the interesting facts that I think is always keeps me up at night, I guess, is that, certainly if you go back to 2013, that were 2 billion minutes of conversations happening every single day over Skype, so when people talk about scale one of the other things I think about is operationally, that’s the level of service we offer. I think there is massive amounts of international calls and everybody when you turn up, the interesting thing for me was when I started at Skype, the number of people who smile at you when you say you work for Skype and then within 3 seconds you get the: “How the Skype make money conversation?” which is always interesting. And then you start to look at the organization, the size of your organization that supports that, and I think again I was surprised when I walked in and I thought: “Wow, there is more people than I expected”. There’s more than 200 teams geographically dispersed across 8 locations, all building what you and I would fire up as Skype, and that also now includes with the acquisition of Skype by Microsoft, that now includes what is called today “Skype for Business” which is used to be called Link, and now it’s being rebranded and it looks more like the Skype product.
Shane: So a large product, a large customer base, a large demand and a large development group.
Tony:Sure, and also two almost fundamentally different customer bases; one enterprise customer set who would use what was the Link product and then you’ve got the consumer side of the business, and Skype at the moment, our big messaging is all around trying to connect the business and your personal life to be able to make that more seamless and frictionless.
4. Tell us about Agile at Skype, what’s happened there?
Chris: One of the things you discover with Agile is that when you get enterprise threads, everyone is doing Agile, as soon as you say Agile is a good thing, everyone says they are doing Agile, and so Tony and I had a lot of conversations about what does it mean to be Agile. We had a metrics program going on as well, and it wasn’t just kind of business metrics, it was operational metrics, and where we’ve kind of landed with the definition of Agile was that each iteration delivers value, of high quality and that’s kind of UX and no bugs and it performs, and the third one was that you are doing it in short iterations, kind of about a month or less because that was best practice was ten years ago. What was interesting, we had one guy we are working with who was with very good with game theory he said that we have to had all three because any two metrics could be gamed, so that almost became our definition of Agile, was you could do those three things rather than you are doing Scrum, you are doing Kanban, you are doing SAFe or anything like that, it’s one of the capabilities of the group.
Tony: Sure, so all the teams were following the Scrum practices I guess you describe, the operational teams were using more of the Kanban, as you expect more of the Kanban like approach. Chris has spent a lot of time with certainly the operations teams going them into look at how best to optimize around that, and also the Scrum teams were following when I turned up, I think it’s fair to say that the practices, the ceremonies would been followed, I think what was clear though was the underlying principles hadn’t yet embedded in the organization, so we’ve spent quite of bit of time trying to think about how to get them to think about the underline principles so that can make better decisions around Scrum, so you’d see people not really understanding would do what they were doing; after while they’d do the ceremony, they didn’t really understand the value of them and then they start to go: “Well maybe we should start doing Scrum and doing Kanban” and you go: “Why are you doing Kanban?” and they go: “Well it means we don’t have to do all those ceremonies of Scrum” and we’re like: “That’s not really why you do Kanban” and so those are the kinds of conversations we were, and sometimes we still have.
Chris: And what you find is that the teams are pretty good at doing Agile, they are pretty good at picking up Scrum, picking up Kanban. The problem is always when you’ve got more than one team working on the same thing, particularly if they are not collocated, which the ideal would be you collocate but we’ve got people in different time zones, what you find is that the team structure for delivering a particular item shifts from kind of release to release. So the configuration of teams needed to deliver something almost changes each time, that depending on which slice you’re going for and that was the bit that I think the teams struggle with and I think as a coach I was looking for practices, that was the place where I found a bit of a gap in terms of what is standardize good practice that Agile will promote. The traditional answer would be: “Well you do a Scum of Scrums” which didn’t really kind of manage all the organizational complexity and it’s a kind of a, you have to pull up the Scrum of Scrums for a period of time and then you drop down again as you finish up that piece of work.
Tony: So one of interesting things is when you look at the books etc, a lot of the books and some of the frameworks, it’s kind of where enterprise architecture was a few years ago where they show you the perfect Zen-garden of an state and nobody really talks about the journey about how to get to that, and the messy road through that, so we spent a lot of time understanding what are the things that you need to think about as you move from where you are to where you want to get to. And what that looks like: so for example as Chris talks about getting anything done, it can take a number of teams to make sure that happens, sometimes six or seven teams have to work together to make something come together and the obvious answer is well: “Hey stupid, why don’t you use a feature team”, well that team changes on a monthly/quarterly bases, so why don’t you just have a liquid pool of staff? Well you try going from where you are, where you’ve got rigid teams to make that happen and how do you move through that, and that’s where we’ve spent a lot of time and effort thinking about that and making it work.
Shane: So what are some of the messages or learning that you’ve taking away that perhaps others might be able to look at and not use directly because of course, it’s very context dependent, but maybe get some advice from.
Chris:quite a lot of it just didn’t stick, whether that was for cultural reasons or operational reasons or whatever, and what we found in the end was just focusing on one thing and getting that done right, being Agile I suppose, started to pay off real dividends.
Tony: And it was interesting because you think, if you look at all of the conversations we hear now around from the product perspective around multi-variant experiments, I mean we tried all that, I mean it was quite interesting that we tried out, I’ll call it drink our own champagne or eating dog food, but we tried a lot of that, but it was interesting that the attention of the organization is something that you have to take into acount, so trying lots of different things at the same time, the organization couldn’t focus around that one thing, so we decided that that’s, we stepped back from that; some of the things we tried were we tried cost of delay, we looked at using a metrics program, we looked at focusing teams on specification by example, techniques, we tried a lot of different techniques and practices, different flavors and variants, but we found that going back to one thing was the most useful thing we took away.
Chris: And what was really surprising for me is that there is a lot of techniques that I’ve kind of talked a lot about in the Agile Community that when you actually drill into them and trying do them for real in a large organization, all of the sudden are really, really hard, so when we are talking about what’s the lead time, all of the sudden how do you calculate the lead time and how do you use that as a metric demonstrating that you are improving as an organization and you suddenly realize that you can’t aggregate it, so you can’t hit a lead time from two teams and add them together because it doesn’t work, and so then if you do it, we are going to do a project, well each project that we do is a completely different shape and size, so that has no value as well, and so I looked at the theory of using duration but the problem with that is that people just don’t understand it, and even things like cost of delay which sounds really simple it kind of assumes that all of your investments are in dollars, expressed in dollar terms, and we had the situation where we got key metrics, how many people do we have using Skype each day and how active are they and how much money do we make and it’s an awkward situation to go right, well how do we compare 10 million new users in Vietnam to 2 million dollars in America. So it gets really tricky just even doing cost of delay, because you got no way of doing that exchange between different values.
Tony: So I think we netted it down to let’s focus on something that is a principle led conversation, so the thing about principles are, it doesn’t matter where you go or what you do, that principle is always true and so we started with what can we do and what can we take the organization to get them to think that way and what is the one thing that is simple enough to make so people can understand and you are powerful enough to get them to ask the questions that will lead them towards answering that comes out with the answers themselves, that will lead them to become more Agile.
Tony: So we spent an awful lot of time thinking about this and where we ended up was because of the planning process, because one of the biggest challenges that we had was simply just the coordination of how do you get 150 teams with teams within those teams to understand the order in which to do anything and without falling over each other. We very quickly came back to, and Chris did a lot of work around this, which is we started to think about the portfolio planning process and how do we get the organization to align around something consistent, and the theory of constraints came out as the thing that was the simplest to understand that would drive those principle conversations.
Chris: And it was one of those things that is a coach, we spent a lot of time building the relationships with the key players until such time is they said: “Hey, what do you think we should do” so that we have to wait for them to invite as in, we then tried to apply theory of constraints, and it was a very simple process which is you have a big kind of initiative that needs to be done and you go: “Right, ok, which teams needs to be involved, which components needs to be involved” and then the product owner for each component would do a rough estimate, a SWAG, Sweet Wild-Ass Guess, is actually written as that in Jira. From that we could work out and what’s the demand on each team and we can make sure that no team was actually asked for more than they can actually deliver, and that then became the constraint. Interestingly, it’s a really simple process, and the one thing that we spent more time than anything discussing was the accuracy of the Sweet Wild-Ass Guess, and it was great because we actually, we had actually trained the Exec and kind of give them Todd Little’s paper on the cone of uncertainly and in one of the meeting the Exec goes right guys, says: “This is a SWAG, we know that on average it’s going to be double the estimate and in 10% of the cases it’s going to be at least 4 times what we thought it was, but that doesn’t matter”, so putting in an estimate of 2.2 what you are saying is so between 2.2 and 8.8, this does sounds silly? But is amazing the amount of kind of energy we put into getting people not to do big estimates and the fact that IT had a real problem, the engineers found they should be providing the estimate and we are saying: “No, no, the reason the product owner is providing the estimate is so that you can deny the quality of the estimate, you cannot be held a countable because the purpose of the estimate is only good enough to create the organizational backlog and identify the constrains, it shouldn’t be considered good enough as a commitment by the teams to deliver”. A lot of people really struggled with that.
Shane: Yes, because where we ask for estimates we want to be, really we want to give quotes.
Tony: It’s funny how we’ve baked that in as an industry, I guess, and I think that’s something that we still going to, we are still trying to unpick that, the no estimates guys are working hard to try out to get us to think differently about that, and so some of our teams in Skype now are experimenting with that idea, they are trying to slice their user stories to be similar sizes or less worrying about sizes, and so a lot of the time when we were rolling up, when we are trying to roll up data, because of the size we can simply just count the number of items as throughput, closed PBI’s became the measure we use rather than trying to worry at all about points of any description, so that’s quite interesting. But going back to the theory of constraints, if we came back to that about the planning process, I think the interesting thing was that it forced the organization to think about where the bottlenecks were and I think a lot of us forget who have come from a software development background and run, and we all get really excited about the concept of building multi-threaded applications and think about processes through CPU’s and we optimize JVM’s, not realizing that actually Agile at Scale is simply another way of looking at a system in the same ways we think about code running through a system. And the irony is of a lot other guys who work in Skype are really smart about thinking about the technology stack, but trying to get them to realize that is the same problem at the system, at that organizational design level, and that’s what the theory of constraints gave us, it gave us the opportunity to say: “You do realize is this just like a CPU with putting something through CPUs and think about the things going through and you’ve got bottlenecks, how do you manage that?”. That was really interesting to get them to just come back to that and it was a simplest way to get them to think about that thinking they had to connect that.
Chris: And what was great because one of the things that I hadn’t read about theory of constrains is you can almost imagine the theory of constrains as a process where you have to go through the steps, and what we discovered is that as soon as we now identify these teams as the constrains, and these teams have got free capacity, we could then start thinking of strategies, how do we move stuff around; but what was amazing is it kind of forces you, because it shows you where the next problem is; as I was saying earlier, it’s more like a compass than a map and I think some of the scaling frameworks are brilliant, but what they are is really a map and there is a certain point you get to and it’s like where do we go now and you are on your own where is with theory of constrains is it just a compass, so where ever you are you are kind of like: “Ok, well I know I go there next”. And it was fascinating to see how, when we hadn’t got the constraints identified, all the managers would assume that we can do everything and since you identify the constraints and they started to actually have conversations about priority it really focused the discussion. When we started to talk three days in Eastern Europe, three days in London and three days in Redman with a group of 50 people in the room doing the planning, and because everyone at the end knows what actually is involved and everyone knows what part of the process they play and that’s because they train everyone who joins this, I think it’s stand to a couple of hours now.
Tony: So now we’ve got to (since Chris left), because we were left in a good state and what we do now is we’ve, at the end of the day we love writing tools, tools so we have written our own tooling to allow this to happen now virtually so now we can run it over Skype, we run the planning process over Skype in a couple of hours and we really simply focus, the idea now is you come together with all these teams, you come together around, you are literally only focusing where the constraints are, and do you want to live with those constraints or do you want to change the plan to alleviate constraint or to move things up or down, so it’s really then becomes just conflict, conflict management around the constraint.
7. Because choosing to live with the constraint is a valid option?
Chris: What was fascinating is that when you do it as well, how quickly the HR policies start popping up, so we had quite a few interesting conversations where we say to a manager: “Right, well you’ve got spare capacity this cycle and that manager of the team sitting next to you has got huge amount of work and there is a huge amount of change that they’ve got to do, why don’t you are going to help them” and was like “the policies won’t let me, because my manager want me to do this”; so you spent a lot of time with HR, didn’t you?
Tony: I did and it was actually during the time in the last two years it’s the same time that Microsoft changed all its HR policies and I think an influencing factor, I wouldn’t say was the factor, but certainly an influencing factor to Lisa Brummel who was the Chief People Officer in that time, she came to look around Skype and she very clearly saw the commitment that Scrum teams have to each other and to trying to deliver useful things together, and she was absolutely fascinated by that, and saw it as a real positive compared to the typical old school way of thinking about it where it’s the “every developer builds a feature and gets a cookie” kind of mentality; this is about the team committing to each other, they all are going to do the right thing in shipping together, she was fascinated by that and the other thing she saw very clearly when we sat down with her was the “build a feature get a cookie” mentality of reviewing somebody at the end of the year and saying: “you individually build?”, was actually conflicting with what we were trying to get done, and she was really excited about the idea of she could see a model of work that she could refer to, in other parts of Microsoft they were doing similar things, so she changed the HR policy during the last two years to be much more now around, what you’ve been done for the team, what you’ve been learned from the team, what you’ve added to the team, so we now have a different set of questions completely for our performance review system, based on that.
8. Turning things upside down?
Tony: Pretty much.
Chris: And you know, even know is just the two of us here, I mean there is a huge team involved, they had more people working on Jira than Atlassian, because Jira was the central tool used by the entire organization for a lot’s of stuff that it was never originally designed for.
Tony: That was turning a caravan into a canoe, that’s the way to describe that.
Chris: And so there are a lot of teams that, we had a Scrum team, in effect Scrum Masters, who actually run this whole process within product and it was amazing how many people were actually involved in it, it wasn’t just like, it was alone: “It was just me”, it was a big team.
Tony: I think the other lesson we learned was when I came in was managers had really been left to work it out which is interesting, and at scale, I mean the interesting thing I’ve done a lot of reading around since joining was this whole idea of no managers organizations. And it’s interesting, the more I realize that we even, even some of the examples and cases that you see, everybody mentions Semco as an organization with no managers and you realize they’re a journey as well, they still have the concept of a manager, it’s just the teams themselves decide who the managers are going to be, and in Skype we are kind of left them just to work things out, or disenfranchise them as I say, so everybody went on Scrum training including the managers, but nobody then said when the managers came away. In fact Scrum kind of, when they put up the chart it’s “Mmm, I’ve got all these roles, I don’t see me”. So and even when some of the training we would sent people on actually said: “You managers need to go and become individual contributors again and go and forget this whole nonsense of being a manager” and that caused organizational angst is the way I describe it. So we’ve also spent a lot of time going back around and saying, Chris and I and few of those who work with in our team, we run and we literally rewrote the career profile for what a manager might look like in terms of an Agile Manager in the organization, so they actually understood where they fit in this process, and that’s really been helpful.
Shane: Gentlemen, this been really interesting, thank you for that insight into Skype’s transformation and good luck going forward!
Thank you very much!