 Yes, is this working? It sounds very strange to me. It's kind of like an echo in your head Okay, there's still some seats in the front row of Further in the front if you want just because you're sitting in the front does not mean you cannot leave in the middle of the talk You can still leave. I'm not going to hold it against you Lots of seats if anyone wants to sit in front If you sit in the front, you'll get the IMAX experience much closer Okay, thank you guys very much for coming today. I'm going to talk about a It's basically an experience report for a multinational bank that I worked in in Singapore I'm not allowed to name the bank Because I've not once were legal Can we edit that out? Maybe from the video later? this happened between 2013 and I would say 2015 second half of around June is when I quit So I know what happened since and it's not gonna get any better But while we while we did this it was awesome and we did a really really good job. I think Okay, very quickly about me Um, oh, you guys will also notice that I use a lot of Legos in my slides in general Something I would like to promote as well It's called Lego serious play where you use Lego at work for a very very serious purpose For example, you can come up with a business strategy using Lego and it works very very well And I just like Lego. It's fun So my name is Michael chick Originally I'm from Europe I Lived and worked in London and in Singapore and this experience report is from Singapore and I now live in Hong Kong. I Work a lot with financial organizations They pay me quite a lot of money to work with them My passion however is to work with startups. So I also work with a lot of startups I do something called lean startup with them But they don't pay very well Most of them actually do not pay at all, but it is so much fun I Work for companies like JP Morgan in Singapore FH Pacific in Hong Kong Hidality International In Hong Kong as well and some other companies that you may know Okay, um quick show of hands You don't even know the question Fine, but there's three questions. I okay who here works at a startup Okay, no one you work at a start up Define a little bit of a starter Well, that means why do you still only work a little bit at a start up if you be acting product owner at the start Not with that the same start up. Yes Same as me brilliant. Yes Who here works at the multinational Corporation Okay, that's basically everyone Who can work in financial services? Wait, no one here One person here, but all the hands over there Okay, if you work for finance in financial services, and if you work in for multinational corporations You'll probably see certain patterns that in general they're very very slow when it comes to change So Something really really remarkable happened at Jake Morgan in 2013 We are Jake Morgan decided to go on a radical change. They decided to implement something called large-scale scrum There are some other talks about large-scale scrum at this conference. I will not actually Tell you guys much about large-scale scrum. I'll just mention that we have implemented it There's some concepts that I will tell you about If you want an introduction to the framework, I think some other talk at this conference might be better So we went on this remarkable journey where suddenly in a 3,000 people part of the organization worldwide across I think five different locations or even actually doing more We decided to completely change the organizational structure If you know anything about less less requires you to change the organizational structure It requires you to implement something called feature teams and if you can Less would also require you to flatten the organizational structure So we went out we did all that We we went from I think four level of hierarchies on the ground to just one All over the power keys to one hierarchy That was really really flat There was an advantage as they come on as in taking long and have not have functional job titles They come on tends to have Hierarchical based on the level that you are They made it very much easier for example to not have senior developers because there were no senior developers in the first place Thank you. I did not say that Actually said Okay, thank you very much Him over here is one of the coaches that we work with as well He was based in the US and his goal is to transform the whole organization was my role was more focused on Singapore and a little bit India But in India again, we have different coaches Okay, and the thing that I'm really really proud of is we did scrum right not just large-scale scrum I think with its grammar did everything work out very well actually, you know, we still have problems and I'll tell you guys about those problems In this in this presentation But it was brilliant. It was awesome. I woke up in the morning thinking yay another day at work and You don't have this feeling alone Especially if you work for my big multinational corporation So most of you guys work at a big multinational corporation who he awakes up in the morning thinking Yay another day at work. I can't wait to go to work If you do, please raise your hand Yes, so no you see my desire So you actually wake up in the morning, sir thinking. Yeah, can't wait to get to work great But as you can see It doesn't happen very easy. We have them and I'm super proud of that Okay, this is as much time as I will spend on less Possible so less This is basically less you have up to eight teams That's scale. It's in essence. It's scrum with one addition at the end Which is called the overall record bet That's it. If you want to scale beyond eight teams, there is something called less huge Which adds a little a couple of additional rules to this framework, but in essence That's about it. That's the skating framework. It relies very heavily on scrum. Actually, one of the principles is less is scrum less huge It looks more complicated because it's somehow they had to make it look complicated To emphasize this is for skating. Okay. We did scrum really really well. We presented At adult Singapore That's actually what we first presented This is the quote that I have for my one of our managers We also did something to the manager. So one of the things that you oftentimes see In the literature is if you go to scrum, what happens to managers? What do they do? Do they have a role? Do we aspire them? Do we merge them back into the teams as developers? We turn them into well either developers or we call line coaches So we did really well, we were proud of it. We presented at conferences. We presented at Singapore twice We there were there were info QR people that we wrote and at least within Singapore, I think we were the most agile bank out there and Not just the most agile bank the bank that was willing to take risks by doing some upfront reorganization Of some actually a lot for bank. This was really revolutionary This you can't really see this very well. This is a slide that Kim born he sits over there normally is not present when I give this talk wanted to give at The scrum gathering in New Orleans in 2014 again We do scrum we do scrum really well, and we are proud of it Some of us used to joke that yeah, we are best in class and every time we went to every time we went to Community meetups and when we told people hey, I work for JT mall the response is always wow. How did you guys do this? And you give us some tips that was until suddenly we had a crackdown So now at JT mall, we don't have any large-scale scrum I can't see the last day from the patient. We don't have any last program That one scrum anymore right You do how big oh, okay? Now that I knew about he knows about it as far as I know this was the largest though and huge crackdown that Didn't come all of a sudden, but it gradually crept in There were first signs that we saw it that we saw in December 2014. That's when Suddenly there was a little bit more pressure put on us with deadlines before we were able to mostly set our own deadlines Like you're supposed to in scrum unless it was a regulatory deadline then it was broken post on us and we had to work with them December deadline started to creep in again There was a bigger emphasis again on the annual review cycle and bureaucracy was added there were more signs in January in February 2015 and also that's when people started to quit because No one likes change and if you're an adult coach, you don't like change took going back towards waterfall at all So probably I don't purchase this like change No, I Can say that for me because I quit as well. I put a little bit later, but I put it here. Okay Right now we have the four layers of hierarchies reinstalled In our teams basically everything that we did before has been undone. Oh, sorry. No, we now have five level of hierarchies We are more hierarchical than we were before Yes, one additional layer Um Yes, something more like a fast Okay, oh, yes, so after we again those four layers prepped in five layers prepped in gradually after we had those four layers We had a manager that didn't have enough time to take care of all the people underneath me So he created an additional layer Which is what normally happens And also very important we are now stressing once again 100% resource utilization Which we did not do before Not that it ever works out, but it kills the system and it I think it's better say it's killing That That We let it up well It was for the teams to decide and we all went for I think did as a general guideline. We went for about 70% of your time In the in the spring planning account for roughly 70% of your time the rest is from unforeseen stuff It never worked out either didn't even work out in in strong So Yes Yep, did I answer your question? Yeah, great Also now they're ending up doing a lot of rework so a lot of people because they're doing busy work You end up reviewing exactly same thing again It really doesn't get any better any worse I think And lots of people have quick things So Okay, so the way I structured it so this is as much as I will talk about The company as such and it's culture The way I structure my target. It's about lessons that I have learned while working there. I Wouldn't even say lessons that In general a lot of people everyone has learned at that company because I don't think they've learned any lessons Okay Okay, so I'm I want to start with stuff that we tried and that worked really well And even now the companies I work for at the moment I tried to replicate some of these things where I think it makes sense If you do less there's a requirement that you have to have co-located teams It doesn't mean you cannot actually Use teams in a different geographical area just means that if you have a team everyone in the team has to sit in the same place So you can have one team in India and one team I don't know in Moscow You can have one team in New York That's fine. Just don't have one team where two people are in New York and two people are in Moscow That would really really well for us Co-located teams we worked across five different time zones. I think we made that work as well as we could I don't think you can actually make it work. Well, at least I've never ever encountered anyone to make it work. Well And The most The biggest positive effect that we got out of that was high bandwidth Within the team everyone was able to communicate with each other at any given time We also created what's up chat groups Most I would probably say 80% of what people wrote on what that was banter and not really useful But sometimes it actually helped a lot What we did encounter however was a Us versus them and tell it to them slowly arose so Basically, if you're part of a team, it is thing use yourself by Seeing who's inside and who's outside and we started getting competition unhealthy competition Before we were able to actually tackle that we will shut down So the only thing I can say is be careful If you see the pattern do something against it or do something to prevent it Okay, another thing that we did that was really what really really well feature teams If you've been here this morning with the keynote where Yes, well, he said don't be feature team it doesn't end up Most in most cases Sometimes it really doesn't end up. I've seen a lot of cases where it doesn't in most of our cases. It did work Did we end up with that code? Yes, we did and I would people who wrote back home and then thought oh someone else is gonna clean it up But those people were always kind of named and changed So that they many of them stopped doing it unless it was a complete team Unless the whole team actually wrote back home that we weren't able to stop everyone named and change them But that didn't work It drastically reduced time to production Initially before we did the agile implementation. We had a release once every six months and After that we went to two releases a week It was actually a little bit too fast for most of the business and they asked us to Do only one reason And at the time where we were shut down It was moved to I think one release every two weeks Now as far as I know, it's quarterly Again, we're moving towards the wrong direction But it was really really well while we did it By the way, does anyone here not know what a feature team is? If you don't know what a feature team is raise your hand very very important Because it's one of the big learnings that I have Feature teams can work if you put the right constraints on the teams Product owners, we spend a lot of time coaching product owners and how to actually write. I Hate the word requirements. So Our product owners on this didn't actually write user stories. So I can't say user stories I guess they were So we spent a lot of time training the product owners don't write down problems that they wanted us to solve Again, phenomenal effect on the teams. They only receive problems and most developers like solving problems It helped it helped the motivation and morale Yeah, but that's also where the brain becomes we spend I For at least two or three months. I probably spend about 70% of my time with the program Just the coach and other coaches have to do the same It took a long time, but I would say the investment. It was a good investment if you can do that People coaches When you go through your transition people won't really they will be very Intimidated afraid. They won't really know what to do. Some of those people will quit The people who stayed you still need to guide them and coach them into It's one thing that you might be able to do if you're an adult coach and you hire someone, but that's not scalable and I think it's always a bad idea to hire Anyway, I say that even though I am an adult coach and that's how I actually earn my money But in its essence as our coaching is not scalable So one of the things that we start to do Was actually get getting Training people up as coaches not as an approach That would really well We also have scrum masters focus on becoming coaches. Actually, that was our first point of contact So we put a big emphasis on telling or making sure that the scrum masters understood that it was a people Not a process right now with this slide. I'm trying to say everyone needs coaching so as a coach How many people can you coach? In order for it to be scalable, you need a lot of coaches Maybe but there's also the other side that most adult coaches aren't actually coaches So hiring adult coaches won't solve the problem. You need coaches Did I answer your question? Okay, I'll take that fine Okay, overall high morale Really repositive impact Initially, we had very very high quality as well. I was initially later is the two Little bit and teams have they did it didn't feel very daunting despite the large scale that we have Okay, next point things that we tried That did not work so well No, it didn't work so well for us You guys can try it I've met a lot of other people who tried this as well and it actually did work for them So one thing is self-designing teams It didn't work very well for us. Everyone loved the exercise though and The teams that were formed when we did the self-designing team exercise The team members themselves were actually very happy but Where did not work work? Hello? Is it still working? Hello, okay, I can just speak louder What did not work was all the teams that we that we got We had a low rate of diversity People ended up Sticking with people that they already knew if you if you're allowed to form your own teams You probably don't want to end up in a team with people you You don't know at all It's one of the things where we did not actually put a constraint on that so we ended up with one team was 70% of Team members were female basically all the female developers that we had went into the team Which on the other hand none of the other teams had female members so diversity was very low and Sometimes it also reflected in the skill set so we ended up with team members where We had a lot of xp a xp ace turn developers we had a team where we had a lot of ex testers and You probably don't want that to happen. Yes Yeah, so the question is if we put any constraints on that. No, we did not which is why we ended up with that There's only so many times you can do this exercise so we We did it again once But that's it so in total we did it twice and we learned something every time so That's the learning is at the bottom If you do this make sure you have the right constraints You can never think of everything but maybe read a couple of blog posts read about people who've gone through this exercise and read about them in states I'm sure this can work really really well. Just didn't work well for us Did answer your question Self-organizing teams, this is more controversial way more Didn't work very well for us why? We had a lot of people Who played the system? So what we gave everything the freedom to be self-organized? It normally comes with a caveat that you have to follow the rest of strong and one of the very very important principles of strong is Conferences It only works if they follow the whole package. So our teams didn't follow transparency They hit a lot of their work and suddenly after five months There was a new system in place that they wrote and no one actually knew they had written it They were very proud of it. It ended up actually being a very useful system But imagine it had ended up being a not useful system. So by luck it actually ended well I see a lot Well, we discussed this for very very long time internally and one of the things that we think We should have done was rather go from absolute control that you normally have in in multinational corporations To freedom and instead actually ease the controls and slowly guide them into self-organization That's certainly a mistake. I will not make again because Yeah, sometimes we had really really horrible team Next one we turned our senior managers into line coaches So for Singapore, we had a location coach in Singapore. We had one location coach for India, I think we had one location coach And The role of the person was to enable the rest of the organization To adopt less to the ground without agility and to adopt the mindset. So we From what I think hope because that proceeded I joined in there from what I think of it was deliberately called coach Because the role of the person would have been to coach people as far as I know, this did not work in any of the locations Well, we implemented it. You know what? I'm not the only one who thinks For Singapore specifically we ended up having a Location coach who basically didn't do much and He didn't do any coaching and The rationale behind not doing any coaching was the teams are now self-organized I'm not actually entirely sure what the coach did most of the time But he looked busy That's all I can say what what we what I learned out of this is that if You come up with with new positions that you create specifically for senior management or for anyone that You're probably better off letting go In the first place be clear about goals and responsibilities But the role or responsibility of that location coach was never really really clear. It was always fluffy vague and a good idea. Yes What you do is that really doesn't kind of another thing that we did Completely failed for us We actually hoped that the people would not Game the system almost every team ended up ended up getting the system What does that mean? We don't know why we think it's a mix between competition between games. That's our competition between teams One big reason that we're assuming is just in the bonus system. We don't think it's only the bonus system Obviously sorry No, it wasn't the appraisal system as far as I know So we had an agreement with HR that no one actually gets a bad bad rating in the appraisal system So at least on that level everyone should have felt safe Yes feature teams. Sorry. What is your question again? It's the slack between. Oh When you implement feature teams all the things have to be long-lived as in we don't swap people in and out In in general, there was an agile a tendency in agile that you have longer loop You don't always swap now, but you tend not to have his project team It's a bad idea When I say project team, I mean teams that form according to a project as soon as the product is delivered You dissolve the team and then you start the next project. You create a new team You don't do not tend to have that in agile Sorry, I'm not sure I understand your question. Okay one feature team develops You mean you mean after it's in production. Do they have to support it? Yes They do No Support work is just like any other kind of incoming work, but they do have to support it. Otherwise Again, which probably ties into this slide if teams don't know if teams know they don't have to support it They will optimize for that So there are certain trade-offs that you can make short-term You everything is great, but in the long term, you know something will happen If you have to support it, you probably will not make that trade-off if you do not have to support it Then yeah, you make everything look good for now Okay, I'm not sure if I understood your question correctly. So but I'm still gonna ask you didn't answer your question Did I answer that specific question? No, it won't change Not just in feature team in agile in general it does not tend to change. Okay I lost my time of thought In the system probably so bonus system for the future in time. We were not able to get rid of that It was not appraisals, but normally appraisals would be in there as best So there was one part of the appraisal system that we were not able to get rid of which was you need a certain duration of very positive outcome of very positive appraisals in order to be considered for promotion That was still there and people were trying to actually get there specifically We tried different approaches for that is also with the bonus system Like people nominating other people who they think were actually performing really really well We tried different systems and none of them work with every system. We tried they just optimized for the system So at one state, it was basically a popularity contest But people just would regularly give out sweets and do other stuff to make themselves popular To get more votes. That was one of the systems we tried We were not able to crack it. I don't think anyone so far has been able to crack it unless well if you have a bone system Team selecting their own squad masters nothing have we tried There are some organizations that I've met or that I talked to where this worked really well. I Don't think it worked well for us. So we we had a lot of teams where You had xba's that turned into developers or programmers and They weren't very comfortable with the new role So when we came up with hey, you guys can decide yourself who is going to be a squad master And if you're interested in becoming a squad master just volunteer So we had a lot of people who just didn't want to be developed and They volunteered and also we had a lot of people who thought oh being a strong master You don't actually have to do my audience sit around them during meetings. You say, okay You speak someone else speaks or you do some kind of facilitation That's probably because they saw that so we ended up with a lot of Scrum masters who are basically just not developers They wanted to get out of the system then we had some teams who thought oh who's our worst developer? Let's promote him to become a scrum master Because he's dragging us down The downside work in additional downside was even after they become scrum masters the team wouldn't treat them differently They would still treat the scrum master. They were very very normal team and So sometimes when it's when a squad master, which is something that actually is actually good We'll just say I know what do you know? It used to be a very very bad developer. So why are you asking us to do this? Yes Well, if you volunteer, you still have to be voted in So if you volunteer, but no one yes by the team if you volunteer But no one actually wants you as a squad master. You're still not going to become a squad master I've seen places where this works really well Just didn't work very well for us We're not entirely sure we think again if it goes back to From total control to complete freedom Yes, actually most team members were already certified Yes, when we started the transformation No, it wasn't We started with transformation. We gave basically everyone on the floor We sent them to certified scrum master As a scrum master you have a very different role That means you get treated differently It comes with the role No, not a leader, not a boss But what is it? What's the role of a scrum master? Making sure that the team Understand not just the team or organization follows and understands scrumps so How do you do that? You have to sometimes make suggestions or do other things or tell people Hey, actually, this is the stand-up. It's it's not here to just do this and that And every time a scrum master would do that the team would say Who are you? You're just a bad developer But I wouldn't accept those suggestions Yes No, we did this in the beginning This was in the beginning No, only full-time scrum master We did not allow half-time scrum master and I honestly don't think it's a good idea. In general, it's not a good idea Sometimes it's the only thing you can do but in general avoid that Well, what? full-time scrum master Yes, they didn't have a variance in size, but only the small scrum that you see So our guideline was I think our guideline was seven plus minus three and only guideline When we did the self-designing teams exercise, I don't remember if it was seven plus minus two or six plus minus three But similar size Yes, oh, okay So the question is if a scrum master is not available for whatever reason is anyone taking Taking over or covering the goal. Yes The other scrum masters if you have full time if you have a team of full-time scrum masters, then another scrum master can cover you Did that answer your question? No, it sounds like a bad idea. In general It depends it depends very much what you see the role of a scrum master is if the scrum master facilitates all your meetings and Then it might be a little bit harder to scale But if the scrum after if you treat a scrum master's role actually more like an ailing self-organization for the team Where the goal of a scrum master you might say is to make himself jobless unemployed Then it's very very scalable because a lot of the stuff that In outside organizations a scrum master does and actually been on by the team So our goal was Initially, we had one scrum master critique Later on we scaled it up to one scrum master covering And very rarely we had one scrum master this week and I that didn't work out very well No No, there wasn't a requirement. Most people in the organization actually thought that And most of our a lot of our coaches got there, but that was not one of the Another thing we tried and failed is the Boy Scout rule Boy Scout rule says if you go somewhere and if you go to a camping site Leave it in a better state than we found in Basically and you can apply that to code So if you don't into especially legacy code and you do something with it Just leave it in a better state than you found it in the first place. It's a nice principle It just didn't work for us because a lot of people a Lot of teams went in change the code So I was probably even messier than before And they thought okay Yeah, maybe someone else will clean it up or I'll just come back later and clean it up And Maybe you know from your own experience if someone thinks I'll come back late and clean up It's never gonna happen at least in our case. It's never happened. No Not a formal one in formal one. Yes, okay Collective code ownership again didn't work very well for us If everyone owns it our from our experience in this case was No one owned it But that wasn't again that was just in this case. I encountered a lot of organizations where it actually works So I know it can work and if it works it works really well Didn't work for us But give it a try We think it didn't work because Scale okay We did really well, but in the end scaling had a huge cost It was worse when we had to work with the US so in Singapore and Delaware where the US headquarters were was a 12 hour time difference It's basically meant whenever you have meetings together Everyone is in pain There is no way to have a meeting where someone feels Okay, at the very least are happy So 12 hour time difference means 9 a.m. In one location means 9 p.m. In the other location So you get into the office at 9 You have a meeting the other side. It's even you don't want to do the meeting at 9 p.m There's no overlap where at least one side feels comfortable and you can just rotate it That really really had a huge cost The impact was people for decisions took a really long time because people were trying to avoid talking to the other side Every time they have to talk it was a pain Everyone's pain If you don't really have a need to and we don't think we actually had a need to scale a lot of the stuff that we did You could have just done it in one longer location It would have been in essence. I think cheaper Okay, I gotta be quick things that we tried did not work and I none of us who work there think it will ever work So don't try this Don't try your implementation your agile large-scale implementation with revolutionary change We made a lot of changes Which was in essence actually actually really good But if you make a lot of changes at the same time, you don't know what is what is the result? Well, you don't know What which change results in you put a Good, I don't know 56 new rules in place and you get result C You don't know which of those rules actually Contributed and which of those rules actually went against it The only thing you can see is the overall don't try and Don't try and do revolutionary change When you scale do it gradually Slowly it will also help you when it comes to resistance changing people's behavior Basically just don't do it. We can't think of any case where it will ever work and that's Six of our coaches as you know them. They all agree with this We ended up having development teams. Yes If you do this, you need a lot of good coaches. If it's a gradual change, you might get away with having no coach or having one and also if you can limit change in progress So don't implement more than I don't know three changes at any given time We ended up with development teams that were literally developers or programs We we educated our testers and our da's to become developers. I Don't think that was a good idea at all a lot of people felt out of place The morale was damaged and Honestly, some of them were just not very good developers Instead I would suggest that you actually integrate testers and behave into it. Yes now Is it very specific? Is it a very specific problem? Okay, come to me after the talk some Okay, don't do time zones great amount of time Seriously, don't do time there. That was probably the worst thing you did Okay I'll finish with don't do time zones before they kick me out Okay. Thank you very much. If you have any questions come to me now, I guess I'll probably outside if the next speaker's already here