 Helo, maenai Steve Peacock, co-CEO i'r company called Dragon's Arm, an agile training organisation. Sorry I can't be there with you this afternoon, but the events of the past few days New Zealand have meant that I've been unable to get to you, so I hope you'll forgive me and understand this. So who am I first of all? I am, as I said, the CEO of a company called Dragon's Arm. I'm an agile coach and trainer, and I'm not that agile trainer part, but I've been all through my life in some way or another relating to organisational change. So what are we going to talk about today? Well, as the title said, it was talking about culture, but I want to talk about the view of the two different types of culture, private organisation versus government department culture. Now, neither of them are bad and neither of them are good. They are just simply different cultures. So I'm not putting art with them down. There's just a difference. And why I'm talking about it is the effect that it had in the learning that I had to do when I tried to put my private organisational training and experience into a government organisation and the culture that I met there. Now, I'm going to talk about Statistics New Zealand, which is a fabulous government department, and I'm going to tell you about a natural disaster that happened and how this affected that department. And then six months later, I joined them as their agile coach and all the learnings and failures that I went through for that. But first, an understanding about this discussion is that I'm not talking for Statistics New Zealand or for any other organisation. I'm talking on my own and what I saw and how I perceived that. And my learnings and failings, while I had permission from Statistics New Zealand and they understand this talk is happening, it's all about being able to understand it from my point of view. First of all, what is your definition of culture? Well, here's one, but that's not the type of culture that I'm talking about. Yes, that's me on the right there and that's my wife next to us. Yes, we're Chinese and we went up last month into the Punjab area of India and immersed ourselves completely in Indian culture. When my daughter on the left there got married to my son-in-law, they'd been married in New Zealand for a couple of years, but we went back to India to do the official, if you like, the Indian full immense area. It was a lot of fun. We had a ball. I even got to dance. It was a lot of fun. But what do you mean by culture? If I had to think of a few words, it comes down to this, the way we do things here. And I don't know. I can't remember where I heard that from, but it stuck and I think that is a correct definition of culture, the way we do things here. So I talk about a private sector on what I was used to because I've been through private sectors quite a lot. I'll talk about Stats LLC, a US company, but it's a multinational company. It has offices in almost every city in the entire world and I would not be surprised at all. In fact, I would be surprised if there isn't an office where you are now. So Stats is after sporting analytics, a multi-billion dollar industry, and they lead the way in that. I was with a team as their program manager in a little place called Palmerston North about two hours north of where I am here in Wellington, New Zealand. We worked with that. The team wasn't particularly productive when I came there. And with what I was doing, there was problems with the code that they produced and the customers weren't happy. So after about a year of trying, and I wouldn't do it without the permission of the head office, the head office said, OK, well, go for it. Give it a try, see what happens. And this is changing it to agile. And in fact, I'll relate it to Scrum. Now Scrum is a framework that can easily be agile added to it, but it's a framework on its own. So what I did was I sat down with the team and I said, this is what Scrum is. These are the things that you'll be expected to do. How about we start doing that from Thursday? And they said, don't worry, just do it for a couple of sprints. Now sprints were two weeks at that stage. Let's do it for a couple of weeks sprints at the end of two sprints at the retrospective we have at the end of that. We can ask the question, do we want to continue working this way or should we go back the old way? And if you want to go back to the old way, I'll step back and say, cool, we tried. It was fun, we tried, we decided it was not best. So we went to this way. It was quite easy to do. In fact, it was child's play, really. When you're in a position when you can ask the team to do something and there's a certain expectation that they do it, then that's a lot better. It's not command and control, it's culture. When they ask to do something, they can do something. Government department has a different type of culture. Government department has, do I really need to do that now? Who's asking? Why is it asking? What's important or they don't know anything? I'll carry on. That's sort of a government culture. Now that's not bad or good, it's simply the culture. So I joined this company, as I said, of course, Statistics New Zealand, and I came across an interesting guy called Chris Buxton. Now he started as the CIO, Chief Information Officer for StatSceneZ in March 2014. Now he implemented things that were quite radical at the time. He wanted to take, he took a look at this and said, we're not an IT organisation, he joined the IT department. He wanted to take the word IT out of the language altogether. He said, we're not about hardware, when you say IT you're thinking service and you're thinking printer. We're not about that, we're about information, we're about databases, we're digital. So he changed the IT department to be digital business systems and he changed to support that. He took a radical approach back then, which is quite a gamble, and he changed his own title from CIO to CDO, Chief Digital Officer. Now that was a gamble because back then Chief Digital Officer wasn't thought of as on the same level as CIO, so he effectively took a step backwards, but he also showed everybody that he was behind what he was doing. The old hierarchy of command and control eventually moved on and he implemented a new management team that was supportive and working for that sort of an agile way of being able to assist teams to do what they need. And he started to wear this around agile, but he had this vision of DevOps. DevOps he said was a five to seven year implementation. I know organisations can sometimes do this in a year, no he realised this is a government organisation, things work slow there. So he had this five to seven year vision and he had agile as the first step to that. So he started to change the team names from development teams to DevOps teams. He had the team leads renamed to DevOps managers. He would have liked to be involved in that decision, but that's what happened. And then it happened. In November 2016 parts of New Zealand stood up eight metres taller and walked five metres further north. I don't know if you can see it in there, but right in the very centre of that picture are two people standing up against that where they stood up and walked forward. So that rip in the earth went for over 170 kilometres. That's something. Why am I talking to you about this when the government city of Wellington was hundreds of kilometres away from us? Well, this is the reason. That, ladies and gentlemen, what you're looking at there is what happened at midnight on that fateful day. Over a couple of minutes, floors pancaked down on top of each other. The structural beams went out of alignment. One of them was even leaning away from the building itself. It was not able to be went and gone into. These photos were taken by remote control. There was no way to, anybody was going to be inside that building again. You couldn't go in to get a hard disk. You couldn't go in to grab that server. You couldn't even get your laptop off your desk to take it away with you. That was it. So in effect, statistics New Zealand lost 90% of its IT capability overnight. Now how many organisations do you know in the world that would survive that? And this is where fantastic people as statistics New Zealand just got up and got things done. They re-established core production services within five days and the full restoration of all the IT within 12 weeks. That's fantastic and it's amazing. But at what cost? What did this create? Well, this ended up creating a bit of a problem in that the solution also became the problem. The solution was the hero. People would just do things. Now why was that a problem? Because when I came along to try and implement that agile, we had a hero type of mentality within there, a hero culture, if you like, in that what heroes do, they work on their own. They do things, they make decisions, they shift everything and they solve problems immediately. But sometimes the decisions they make affect people, but they don't talk to the people and ask the people who are going to be affected about those decisions. They just make those decisions. So their own hierarchy of power and it's not conducive to teamwork or agile. So that's what happened there. We had nine DevOps teams, or development teams if you like, but nine DevOps teams, three very high-file profile projects and these were so high-profile that if I wanted to implement a change that they didn't like, they just pulled us out and said, no, that's not going to happen and they had the power to do that. So I met up with a culture clash, if you like, when I walked in there. So what happened? Well, it's not the old government culture, but something different. When you talk about government culture in New Zealand, you start thinking about the 1980s where people who worked in government went to work all day with a specific requirement of ensuring they didn't do any work. Read the paper all morning, went out for two-hour lunches and went home early each day. That was the perception of what's happening and I know there were some very hard workers in there, but that was the perception of government. That's not what I'm talking about here, that perception disappeared over the next 20 or 30 years. What happened here was that we have the heroes, fabulous people, the experts. I'm talking about international well-known experts that work in Sydney, New Zealand. It's an amazing place and we have the mother hen protectors. Now, what do I mean by that? The mother hen protectors will protect me, their team from me, for example, or they'll protect their team from anything else. When they ask them for reports, that's nothing to do with you, I don't want anything, no, no, no, go away. You're trying to say that my team is wrong, go away. So you have that type of culture. You have the biases. Now, these biases are normal in all organisations. But it's the same biases that you come across. And that's things like the confirmation bias. The confirmation bias says they're looking for things that support what they already believe in. So if you're telling them something different, they already have another belief and all their hearing are the words that support their belief. We all do it. It's natural. It's a positive syndrome, which is your experts. They don't want anybody else to interrupt them. They like their expert status and they become just a team member. Then they're nothing, whereas they're experts. And the positive syndrome says if somebody looks over their shoulder and says, what are you doing? How are you doing it? They'll realise it's very easy what they're doing, but it's only easy because they're international experts and that's the thing that they do. So you've got that. And I come across quite a lot. We are already agile for a reason that some of them might have had some scrum training about eight to ten years ago. Some of them had a statement of, oh, we once worked on an agile team. Yeah. And some of them felt that I even had one person say, oh, but we belong to a DevOps team. Therefore, we are already DevOps. It's a difficult situation to go through. And remember, I didn't have any power, any status, anything whatsoever. Nobody had to even listen to me. So I had this sudden realisation by lunchtime on the first day. This wasn't going to be done by Thursday. I was out of my depth. I knew that at the time. I was almost ready to walk away from this. The only tool I had was influence because I had no power with what I'm doing. I wasn't in a specific status that said that I could ask teams to do something. And quite frankly, none of them reported to me. They all reported to different people. They didn't even have to listen to me. So we had a problem. I was out of my depth. After a while, I didn't have access to the teams because you had those mother hen protectors. It didn't have access to find out what they were doing because there was no reports. And if I asked for them, I wasn't given them. So we had a problem. When you spoke to each of those DevOps managers and anybody else in the organisation, they were all quite willing to speak to me. They thought I was a, when I first came on a management spy, they quickly realised not that. I'm quite a nice guy. They all had came at the time of day. They all spoke to me. They all went out with coffee with me, all those sort of things. So I then became, rather than a management spy, I became something called harmless. Which means I had practically no influence whatsoever. So if that was my tool, it was totally inactive. So the first thing I did there, after trying almost every other thing that I could think of, talking to other coaches and trying their suggestions, all the other things that you'd normally try, I realised that if you spoke to every one of those people there and asked them about agile, everyone would give you a different statement, a different reason for, a different meaning for agile and probably very few of them, would have anything to do with the agile manifesto. So I said, Chris, we need training. And I went to him and I said, you're in luck, Chris, because I'm a certified ICI agile trainer and I have a company that is an ICI agile member organisation, so I'm also allowed to put on this training. And I've also created certified training materials for that. He was thrilled, he was great. We did that. Over 200 people were now certified after a while, after a few months of going through that. It was great fun, it was a lot of fun. But what happened was teams were inspired to try because during the training I told them about all the other teams and what they've done. I've told them about changes and how it could happen and how it can affect teams. We did their questions, we did the full training of what this actually means and where it means, so they understood, they were on the same page and they were inspired when they leave that. The conversations changed after that. It was quite interesting to take it. That was the first step that I could actually make. Agile meetings were actually happening. So you can go around, there was a piece of piece that were actually happening. They were there. There was still protectionism there so you weren't able, still weren't able to get to see things like you burn down charts but I'd learn why later. And other reporting but otherwise they were actually quite inspired and I then became, had some ability to have influence and take them to the Agile manifesto that I planted on the wall and I say, well let's see what the manifesto says about this first. We talk about that and it's quite good. So things changed there. That was a big step. Learning number two was about acceptance. I had to accept that some people were not going to be on this journey with me. For me as a person but Chris Buxton helped me along on that one. He said he took me to a side a few times. He says, not everybody's going to do this, not everybody's going to come along. We have to accept that. So it's not my fault nor is it my problem if they don't. So that was the next one I had to do. In the end what happened was that people went along not because of my teachings or influence or anything else but because they wanted to be part of the team and they saw the team doing things so they were fine. Yes, one or two still are not part of that team. They've gone off and done something else and on the whole we treat them as an outsourced contractor if you like, send them stuff and expect it back again. So that's rather sad but I'm hoping that we're still not finished this journey. So now that I had that look at the teams and I wanted to know what problems they face I still didn't get any reports I still didn't get any burn downs I still didn't get any indication of the types of work that they were doing which by now is rather difficult. You know, what work are they doing? I don't know because I don't have access to it. So the only thing I did have access to was a tool that they used called JIRA. Now JIRA I've used before because I know about it. If you don't know about JIRA it started out as a bone tracking online tool and it became very agile and a way of working through stories. So every project had a different process that it can go through. So if you think about a scrum board it has things like a simple scrum board might have to do in progress in test done and that's a process. So it's one of the ways you can do that. You can set up your own process for each one. So I started looking at that and I came across something like this. Now when you look at it you'll see those red signs in there. This isn't the actual ones this is just something I got off the web but it gives you an example of what I was faced with. Those red steps in there maybe one might be built where the development team actually does the programming and gets it done and the other one might be rework for example and I said you can't how can you operate like this? You can't. What say we change this a little bit for the teams to be able to do their word properly. Now I realised very quickly that this is the business process this isn't the development process and the teams were being forced to do what they are. So here's the challenge I had the first one is to drag the teams back into DBS now that might sound anti agile not to work closely with your customer but I'm saying they're still working closely with the customer they're just not doing what the customer is doing they're doing the development side of things. So it's a way of working that they have to have their own boards and their own things so the business ask them to do a story they can process it through their own five to seven steps and finish it so that they can get it done within that sprint. I insisted that only columns that are steps in their process that the teams can control should be on that Scrum or Kanban board not things they can't control and as I went round they were all accepting of this long conversations with business who realised that no they weren't really losing control they were allowing the teams to process in the best ways they could and they can because it's an online tool this year they can still see what's happening but the biggest problem I had there was that I saw the teams all had user acceptance testing as a column and I said why do you have that as a column user acceptance testing and I said do you control user acceptance testing no but things come back from it we do that it gets tested it gets done it completes this testing it goes to user acceptance testing and then it might come back might have failed user acceptance testing and go back into need to be done again straight away so it goes back into to do column and here I had another very long discussion and a number of discussions with both teams and businesses because I said nothing can ever ever fail the user acceptance test and I know what you're saying but that's the actual fact nothing can fail user acceptance test but what happens if it doesn't work well if it doesn't work you've got a bug so you create a bug you tell them the steps it's created and you file that with the team and the team can prioritise it as normal well that's a big bug it needs to be done now it's more important than what these team is working on now so it has to be done within the sprint bring it in, add it to the sprint drop off whatever is needed so that we can still finish the sprint and away we go or the columns are not quite lined up well that's okay but let's do that next sprint those sort of priorities are now able to be related rather than simply absolutely everything being done as a bug because it failed user acceptance test so now they understood only the user acceptance test cannot fail but new stories or bugs can come out of that now they know when a story is done suddenly they're now able to publish their burn downs because for the first time ever they're getting stuff actually done within their sprint they can finish a sprint they can reach their sprint goals but it hasn't passed UAT that's a business process that's not a development process so people are starting to get that it was good then I started the next step in my learning of course I had no say in anything and no ability to ask the team to do something now I did so I asked to become I took a look at one team that I had been working with quite regularly and they were having a great deal of problems because they had a very controlling if you like business unit that they worked for to such a point where they would get a a job spec come to them that was already said this will take you three weeks we expected back then and then they get blamed that it didn't come back within three weeks and there was all sorts of problems and during that time of course business would come to I would change this and I would change that and I would change that so they couldn't get things done they had a problem and these people were team leads they'd never been trained as a scrum master although I took them through training and agile training and I used scrum heavily within that training they never really had that scrum master training that you'd get so I took over as the scrum master for the team on the agreement with the devos manager and he was thrilled with it he wanted to see why it worked see how he got around with these problems so I worked through a scrum with that and people learnt a lot and other teams would watch what was happening and listen to what was happening so it was another learning experience the next one was the scrum of scrums one thing that I got back from everybody is we don't know what the other teams are doing and I said but you're having a project meeting with businesses all different businesses once a week after two hours and everybody gets up and tells them all the different stories and bugs they're working on and all those sort of things and there's questions going back and forth and it just takes a little time and nobody understands it that isn't in that team themselves the person who isn't nobody who's not talking understands what is being discussed and it was a difficult time and there was nobody wanting to be there so I took over as the scrum of I felicitated that meeting facilitated facilitated that meeting and they were keen for me to do so because they weren't getting anywhere either and they thought okay well maybe you can do something with it so I did and for the week before I sent out this thing to everybody and I've already been through and training but I told them how to do it and I said this meeting will take 10 minutes and then it's finished I said you can stay there I've made it for a half an hour because there might be some discussions afterwards or where two people want to talk so we keep the room for a half an hour and because it was multi-city we had to have it in a room so that we could see other people on the screen so I've put in some rules about it I said the first thing is it's not like a team stand up so we're only talking about goals we don't want to hear a thing like a particular story or a story number or a task that you're doing or a particular bug we just want to know what goals you have for this sprint how are you tracking against those goals do you need any assistance or any technical person who might be on another team or are you going to meet them why not are you going to meet your goals and why not and that that was an interesting thing put in two other things I said there are no discussions in the stand up absolutely none no discussion whatsoever even if you have questions you can't ask them it's not the time for that you talk to them afterwards the only team members only the team members in this case only the devos managers get to speak and stand up everybody else is totally welcome to come anybody and everybody can come along and listen in on what's happening and that was there and mind behold the first scrum of scrums that we held finished in 10 minutes and I had everybody afterwards saying to me wow for the first time ever I know what all the other teams are doing I think technical disgust in there it was fantastic I now fully understand that what we went into is now about 20 minutes long because what we do is the scrum of scrums is 10 minutes and then at the end 10 minutes we can say right the scrum of scrums is finished those that need to go can go but otherwise we'll be here for another 10 minutes anybody got any further questions and there's other discussions that happen afterwards in a very relaxed atmosphere which is very good so 20 minutes on total marvellous that's still going it's fabulous the third thing number six I had to learn was shut up and smile yes it was all your idea the thing I've been trying to tell you to do for the past 12 to 18 months you've just come up with this wonderful idea pull that in and go for it this might be one of the senior developers might come up and suggest why don't we do this fabulous go and have a talk to your devos manager and see if they want to do that I think that's a great idea I'll support it and away you go it kind of worked I had to shut up because it's exactly what I've been trying to tell them to do so number seven how do you change the culture constantly it's the only way I strongly feel that constantly is the way you change that in that we had I was always talking about different things my day consists of walking around teams and talking to them all the time I'm always there we had an online discussion board and I'm always putting little new things up and something that I might have read last night or something from the training sessions or something that I'd seen and some other team in another location somewhere and the other thing that I tried to lean heavily was the psychological safety and that people can bring up things I made a mistake and I wanted people to celebrate that hey you made a mistake the importance of failure you've all heard of the statement of how vast learn fast when the people hear that you can't fail yes you can it's not about failing it's about learning it's the wrong focus to put about is the failings that we have is the importance of the learning you do and why fail fast I'm often asked well there's an old saying that goes if you find yourself in a hole the first thing you should do is stop digging and it relates to that as well if you find you're doing something wrong it's going to fail stop, stand back and say what are we learning out of this this isn't going to work do we need something to change and before we carry on or do we need to abandon this all together and do something else so that was quite constant going on the way all the way through now ownership number eight the last one here is something I couldn't get across it's always somebody else's problem I couldn't change that teams felt that they passed this on to the DevOps manager therefore it was no longer their problem it's wrong I relate this to let's say for example a team all had broken chairs so it was very difficult they couldn't sit on them for more than an hour before getting sore backs or whatever now quite rightly they might bring it up on the next stand-up meeting with the DevOps manager to please solve the problem of the broken chairs now what the team does at that point which they shouldn't do and what these teams did was they felt that they'd passed the problem on now is now up to the DevOps manager to fix the DevOps manager doesn't have any budget so they go to their their manager and they say hello manager our teams have got broken chairs they need new chairs there's nothing in my budget for furniture I tell you what I'll organise that for next year in the next year's budget there will be new furniture ability well and they wouldn't get back to the team it's always oh management doesn't understand management is terrible and everything else well it's not the management's problem management's probably got good chairs your scrum master probably has great chair it's the team's problem only the team have broken chairs the team's problem but they couldn't learn that they own that problem all the way until it's resolved or in some way or another they feel that they've got to they've passed on to somebody therefore it's their problem now it's not their problem so what four things made the biggest difference out of all of them training was the first one that really made a huge difference and I'd highly recommend that as step one get everybody onto the same page but nothing in isolation if I'd stopped at that they would've been back at what they were doing very quickly and the second one was teams no longer belong to the project they're now able to operate several projects they don't belong to a particular business area so we discussed that the teams control what they can control and ongoing permanent culture we've got a little saying with our job coaches in New Zealand and that even the all blacks need a coach now the all blacks are a rugby team that almost never lose they've won so many world cups and it's just it's not whether they'll win or lose it's how much they'll win by it's that type of team but they still have a coach even the all blacks have a coach so where I left them in the end at the end of last year later part of last year my business was taking off I needed to get out and operate my business full time which I'm doing now and it was also time for a change the teams would probably need somebody new now to come in with different ideas so I left them at that point now where did I let them I felt that they're not as advanced as other teams that I've had they're not as far along as what I've seen other teams but on the other hand they've come a long long bumpy road they probably come from further back the journey will never end that's true of all teams and all their job transformations but I met a lot of friends along the way friends that I know and I met them so this it was very difficult as a coach very difficult at times especially as a coach who doesn't need to be listened to it's just a very difficult it was a learning experience for me and I had this gardener's hype cycle that I related this to the gardener's hype cycle relates to IT hardware mainly but when you come in there's the technology trigger and you've got this peak of inflated expectations and I related this to the way we're putting in agile there is this trigger we're now doing agile here's this new agile coach where you go there's this peak of inflated expectations and it drops immediately to the trough of disillusionment it doesn't do what you immediately expected for the first day the slope of enlightenment happens over time now that will depend on what you're doing and that will depend on the team and the culture within Stats New Zealand that took a long time the slope was very slow and very took a while but it was a good slope it was consistent the slope I had with Stats LLC with the private sector teams was very steep and then you get to a plateau of productivity notice the plateau of productivity isn't up with that peak of inflated expectations it's somewhere in between so that's what I had to think of all the way through with what we were doing the other one is somebody from about 3,500-4,000 years ago wrote this quote specifically for me obviously when they knew so it's one that I actually added to my email signature when it is obvious that the goals cannot be reached don't adjust the goals adjust the action steps so Confucius was right about that and I had to keep that to my heart and I had to read it all the time so that's it for me thank you very much I'm sorry I'm not there to turn to your questions but you sent me on LinkedIn you sent me an email at steveatdragonsarm.com I'd love to hear from you and your experiences and your questions I'm always open okay I guess we should have a huge round of applause for Steve he could not be here but he still put in all the efforts to record the video