Good morning, everybody. As Gene said, my name's Em Campbell Pretty. My Twitter handle is @prettyagile. My blog is prettyagile.com.

I think, in fact I'm pretty sure I'm the least technical person at this conference. That could be because I've never worked in IT. In fact, I spent the better part of the last six months trying to work out exactly why Gene asked me to come and speak here. I figured that it probably had something to do with wanting to talk to people about transforming culture, because that's pretty much what I talk and blog about.

So imagine my surprise when a few weeks ago, I got on the phone to Gene and he tells me that the conference organizers want to hear DevOps stories. DevOps stories that have concrete practices in them, not just culture stuff. So I Googled DevOps and discovered that ... No, I literally Googled DevOps and discovered that DevOps was an umbrella term for a number of what I would call good technical practices.

So today I'm going to tell you my story about how a business person became passionate about good technical practices. So this story starts in a unnamed telco, thanks Gene, in Australia. It was 2007, and I was working in the reporting and analytics space, and I was also the business owner of the enterprise data warehouse. The enterprise data warehouse had been stood up as part of a enterprise-wide program to simplify our technology stack.

And in their wisdom, they decided that pretty much we would build this warehouse one field, one report at a time. And if you know anything about building data warehouses, that's not how you do it. So it went on like that for a little while, and the warehouse pretty much struggled to deliver, probably in part from the one field at a time approach, and some of it was really just a technical mess. To give you a flavor of the size of this technical mess, about one year into this program, I'm in the midst of a debate with the IT folk about the lack of performance of these handful of reports that had been delivered.

And to prove how poor the performance was, I had three of my guys sit down and execute reports and time how long they took. The next day, when I turn up at this meeting to prove my point, I was told that having three people simultaneously running reports on what was a huge teradata data warehouse was abusing the system. So it really wasn't going very well. So, around this time, I got a new manager.

He said to me that we're really never going to be successful trying to build a warehouse one field at a time, one report at a time. And we're always going to be fighting fires and arguing unless we do something really different. So, with his help, I spent the next nine months writing PowerPoint. There was no data warehouse building, there was just PowerPoint.

And we took that PowerPoint to the CIO, the CFO, and pretty much anyone who would listen. And eventually, pitched a $200 million three-year program to the CEO, and he said yes. So being the person who had been behind the bid, I said, "Well, obviously you need to let me lead this thing." I'm not sure that they were convinced that that was a great idea. I'd never run anything of quite that size before.

But eventually they gave in and let me take that lead role. So I became the business sponsor of the Enterprise Data Warehouse Enhancement Program, as we called it. And as part of that, I inherited an in-flight program of work, because it was being built on the enterprise data warehouse. So that project had a checkered history, as many things in this space did.

They had spent a year creating a business requirements document and then getting that signed off by every executive in the company. They'd spent another year getting the business case approved. It had gone up many times for approval. The IT folks were really nervous about their ability to deliver it, and in the end, they got enough funding to do the first 10 to eight streams of work over a 10-month period.

So clearly the right thing to do at that point was to kick off all 10 projects simultaneously and lock all the business people in workshops for about three months and write some requirements definition documents. So 400 pages of requirements definition documents later, we're in this phase where we have an army of techies writing system requirements specifications, and I get introduced into this process. And I'm a bit puzzled at this point because we have this 400 pages of documentation, but there doesn't seem to be any communication between these army of people writing the next level of specification and the business people who came up with the requirements in the first place. So I asked, "Does anyone have any questions?" And the IT general manager said, "I don't know, but I'll find out." And he comes back the next day with a spreadsheet.

The technical team had been writing their questions in a spreadsheet200 questions in a spreadsheet, and we had six days in which to answer those questions before we had to pass the documentation offshore to the guys who were going to build and test these requirements. So clearly, we answered all the questions we could in six weeks and moved on to give the documentation to the vendor. Eventually, just before the end of the financial year, one of these 10 projects actually deploys something to production. And at that point, we start UAT.

We spend six months in UAT, at which time we pass UAT, but to the best of my knowledge, that software's actually never been used in production. So, if you're me and you're about to kick off this huge program of work, you're going, "There's got to be a better way. There's got to be any other way. This is obviously not going to get me through a three-year program of work." The organization had decided to adopt agile.

They'd picked off their top 10 projects or applications that they were going to start with agile. The enterprise data warehouse wasn't one of them. So being the true angry business sponsor, I banged some tables and said, "This is unacceptable and we need to do something different." And the IT director had a target of having 10% of his projects agile in that year. He didn't have an agile project yet, so he said, "Excellent.

You guys should go and talk to the agile people." So we did. So we took my team and the IT leadership team on two days agile fundamentals training, and hey presto, we were agile. Well, so we thought anyway. Our first agile team had eight people onshore and eight people offshore, and not a single person who had ever done anything agile before.

The good news is that they actually did manage to deliver working software, and I got to go and present working software in the test environment to the C-suite stakeholders of the program. So the chief customer officer, chief operations officer, CFO, CIO, et cetera. So it's all going pretty good. And then we deployed to production.

Drag, drop, wait. So this was not good. And historically, what we would've done is gone and hunted down the vendor and asked them to please explain. The slight problem was we'd taken ownership of this, and we had this newly formed technical governance group that were making sure that everything was done right, but it still wasn't performing in production.

The great thing about having approached this from an agile perspective was that we had shown working software to the C-suite, so we really needed to find an answer to the problem. One of the guys, quite cleverly, took the batch schedule and mashed it through a social networking visualization tool. And we basically discover that we have 4,000 interdependent batch jobs. It takes about 24 hours for the batch to complete, and it didn't really matter what we delivered or how well we delivered it, nothing was ever going to perform on that box.

So the guys came up with a fix due to the pressure, I think, from the C-suite to show something that was working. They put a cube OLAP layer in between the warehouse and the presentation layer, and we have working software. This had been something that had been quite contentious for about five years. But agile drove a decision-making that was far more about business outcomes than about technical architectural purity.

So for the moment, we had a way forward, and obviously agile was going to be the answer for us. So we start spinning up agile teams of various shapes and sizes. I think the record was an agile team of 23 people. One of the IT guys had been through agile fundamentals training, had understood that pairing meant you needed two of everything.

So we had two of everything. And for me, it was a mixed scenario. I'd gone from a world in which I'd spent millions of dollars and got nothing, to a world in which I spent millions of dollars and got something. Not a very big something, but something.

So it's progressive and it's heading in the right direction, but it's probably not sustainable. The IT director tells me that the problem is agile. My agile coach tells me that the problem is the IT director's implementation of agile. He might've been onto something with that pairing stuff.

So I decide that I need to learn for myself. And on my coach's advice, I start reading Jim Highsmith's "Agile Project Management," and I become informed, and I start asking questions. In particular, what is our automated testing strategy? IT folk didn't like that very much, but decided, clearly, the thing they should do was ask me for more money to hire test automation experts.

Which they did, and well, they asked for money and I gave them the money. But they didn't hire anybody. In fact, for the next few months, I continued to go to program status meetings where there was no progress on the automated testing, but I got to hear every week about how the problem with the program was a lack of business engagement.Eventually, I was pretty much over this, so I took a leaf out of Lisa Atkins' book and took it to the team. We ran a program-wide retrospective using techniques from Esther Derby's and Diana Larsen's Agile Retrospectives books.

We asked the teams to reflect over the last couple of months leading up to their last release, what had gone wrong, what had gone right, and what were the things that the program needed to help them solve if they were going to be successful. I believe the question we asked was something like, "If we wanted to double our throughput, what would we need to do?" No idea was too bad or too big or too scary. Anything was up for grabs. When we aggregated the results, strangely enough, business engagement didn't make it to the top five.

In fact, really it was a raft of technical issues. In particular there, the environment stand up and test data provisioning. It was taking six to eight weeks to stand up an environment for a development team, and I've got these massive agile teams just spinning, waiting for these environments to be stood up. So this gives us the inspiration or catalyst to create a new team.

We called them the integration and build team. We took these mythical technical governance folk I mentioned a little bit earlier. Their role was essentially to inspect quality in and prevent a reoccurrence of the early issues with the warehouse. So we thought we might repurpose some of those guys to try and build a build quality in mentality.

And eventually, these automation specialists had turned up as well, so we threw them into the mix. And of course, the first mission for these guys was environment standup. Oh. Sorry.

So, their first job, environment stand up, first thing they needed to do was get a copy of the source code from the vendor. The second thing they needed to do was compare that source code to the code in production. And they found a 50% match rate. Suddenly, I'm understanding why nothing ever worked in that environment.

We were essentially just fixing forward all the time. As code was moved from one environment to the other, we were fixing that 50% match rate. So, first thing the guys actually ended up doing was reverse engineering the code base, which took quite some time. But eventually, they did actually manage to reverse engineer the code base, create the scripts to automatically stand up environments, and we took that eight weeks down to one day.

So we're pretty inspired at this point. There's also a changing of the guard that occurs then. The organization collapses the IT and business components of the data warehousing and business intelligence group into one organization. They create a new role, which is as the general manager of enterprise data warehouse strategic delivery, and they run a national search looking for somebody to take on this role.

They can't find anybody. I have a theory that the reputation of the warehouse was so well-known in the local job market that there was nobody willing to take that job on. So they come to me and say, "Em, you seem to be really passionate about this enterprise data warehouse stuff, and you seem to be really passionate about this agile stuff. Why don't you do it?" I say, "I don't think I'm qualified, guys.

I'm a business person." "It'll be fine. We'll give you all the support, anything you need. It'll be great." I have not seen those people since. The timing was quite good, though.

It was a few months after our, maybe a couple of months after our summer holidays, which I had spent in Bali, reading by the pool Dean Leffingwell's "Scaling Software Agility" of all things. And I'd been quite inspired by the idea of the agile release train. And then someone handed me an IT delivery team. So here was my opportunity.

We would take those disparate, weird-shaped teams and create one program, one team, one organization, one way of doing things in the agile release train. We would look to have an onshore presence as opposed to an offshore presence. And I had everyone involved in development or delivery pretty much under my organization. Unfortunately, I did not have ops.

Ops continued to be outsourced and offshored and outside my sphere of control. So from "Scaling Software Agility," we went down the path of using the Scaled Agile Framework. So that's the book behind the book that inspired the Scaled Agile Framework. And in fact, this was in a time before the Scaled Agile Framework was even called the Scaled Agile Framework.

I made the link between the integration and build team and the system team as it appeared in the Scaled Agile Framework. And I pitched to my management that the integration and build team or system team should also be part of my world. Instead, they were actually peeled back in or pushed back into that technical governance group. And it pretty much didn't matter what I did, that group had to stay separate.

So I figured, oh, well, they're still there. I still need help. So I would continue to try and set the agenda for what that team did.One of my guys, lean Kanban guy clearly, had mapped out the process it took to get a feature through our system. And he comes and brings this to me, and basically what it tells me is that it took about a third of the time of producing any feature was spent integrating and deploying that feature.

So we've come up with our next candidate for the system team, as they're now called, automating deployments. That didn't go so well either. Again, the system team worked agile, and they were doing their fortnightly or two weeks, because you guys don't have fortnightly, two weeks demonstrations of working software. And everyone was supposed to be on board, but when they tried to get people to use this, the devs did not feel at all engaged, wouldn't use it.

We tried to send people from the system team to spend time with the developers to help them. Didn't work. We tried PowerPoint, didn't work. Pretty much nothing worked.

Not at all helped by the fact the code was pretty buggy. So in one instance, a team spent four hours trying to add a comment to a script and ended up deploying it manually. So it really wasn't the greatest solution. In the midst of all of this, the lead engineer or lead developer for this team gets concerned that his contract hasn't been renewed yet and decides that he's out of here.

We did actually get approval to renew his contract about two days after he quit. Not much help to us. So I've lost him. This does turn out to be the catalyst to allow the system team to come and be part of the broader EDW team, so that was a nice silver lining.

The second bit that actually turned out to be quite lucky is when we went to replace this guy, we found a guy who had built a continuous integration rig for a data warehouse before, which is pretty rare. And he came from the school of clean code, and he was pretty horrified at what he found with the tool that had been built for automated deployment. So he spent a lot of his time putting in place continuous integration and automated deployment for the automated deployment tool. Pretty clever stuff.

And unfortunately, really what that meant is he actually rebuilt the whole thing. So we'd pretty much written off the first six months and the first attempt at this. But we did get to automated deployment, made a very pretty tool. The guys could access it remotely from their iPads, which made them all very happy.

And they reduced the time to deploy something on the weekends from a job that took three people all day to a job that one person could execute and pretty much ran themselves. So that was pretty cool. Didn't solve the problem with source code, though. So in way of context, data warehouse people don't normally come from the school of software development or programming.

Version control can quite commonly be a foreign concept. So we had to bring about quite a change at this point. In fact, with this particular group, developers were not trusted to check in code. Essentially what happened was, there was a guy in a team in Melbourne who would put his code in a holding space, send an email to India to tell them the code was there.

They'd see if it was all right. They'd send an email back to the guy in another team, also in Melbourne on the same floor, and ask him to check in the code. He'd do that. He'd send an email back to India, and then the other guy, the guy who initiated the request, would get it back and see if it met his needs, and of course it didn't.

So they would just go backwards and forwards between India for a little while, working out how to make that work. So it's quite a significant change. We're trying to go from a world in which you're not allowed to check in code to a world in which we want you to check in code very, very frequently. And at this point, it occurs to me that business change management is not something we see a lot in IT organizations.

I'm not suggesting that you need to go out and hire business change management specialists, but it does help to think about how you're going to implement change. So the reference we used was "Switch: How to Change Things When Things Are Hard." I could spend all day talking about this. I'm not going to. It's about 200 pages, very easy to read, could be called Change Management for Dummies, and certainly helped us move through that change.

So the team start talking about how they're going to make this change happen. This is what they call their Gene to Baker meetings, because they met Gene once, and she does meetings without PowerPoint, so they became all inspired and started running meetings without PowerPoint. And that was to work out how we were going to make this change. And essentially, we came up with three key steps.

The goal they decided was to move off SVN and onto Git, and they would do that by putting in place Git champions who would help their teams with the change. We would give the teams time to understand the tool before we put it into production. And there was another thing that completely escapes me at this point. However, the Git champions were pretty much the key.

Change actually went surprisingly well, to quote the new technical lead. Not to say that it was without challenges. We did have a few weeks after making the swap from SVN to Git. Somebody dealt with a merge conflict by deleting the master branch.I'm told that's what happens if you use an SVN technique on Git.

I don't know. I'm also told it was easily fixed because we were using Git, so that was good. So I left this group in May of this year. This is where we got to over the time I was with them.

That's my team with the complimentary mascot from Costco, the skeleton. So yeah, we increased the frequency of deployment, we reduced cycle time, significant reduction in defects, cost to deliver down significantly. And the things that I'm actually most proud of are the feedback we were getting from our sponsors or project owners and the feedback from the teams. So while the tech practices were part of this, it wasn't everything, and culture was a really huge part of this.

To understand where the sponsors were at, if you think about my story, I can't imagine anybody would've recommended the services of this organization when it started. So we say that we went from a baseline of about a net promoter score of about minus 100 to a net promoter score of plus 50. And in terms of the teams, we had a baseline of around minus 50, and when I left it was a plus 56. So that is, "Would you recommend working here to a friend or colleague?" And if you have more nines and tens than you do some of the other numbers, you end up with positive scores, is essentially how that works.

So culture was key. In the beginning, I had a group of 100 and something people who didn't know each other's names, and we spent a lot of time taking that group of 100 people and turning them into agile teams and then the team of teams that became the train. When I went and did my safe training, last year I think, Dean Leffingwell shows videos of the All Blacks doing a haka and says, "This is what a high-performing team looks like." And then he shows videos his clients have sent him that have done their own hakas. I thought that was pretty cool.

So when I got back home, I decided this is exactly what was needed to take my disparate team and make them a high-performing team. And we actually had-- well, I gave them a bit of a challenge. I said, "You got two weeks, come up with your team haka, and we're going to have a haka-off." So to give you a taste of the culture that was created, I thought I would share with you the haka from the system team, as was created about a year ago. Ladies and gentlemen.

When Em first said we were going to do the haka- Haka ... it may have come as a surprise to some of you. Haka. But- The system team have been doing this for centuries.

Centuries, people. We're delayed. Our fathers, and our father's fathers, our father's father's fathers, and our great, great, great grandmothers have all performed this haka. Automate.

Automate. Automate. Automate. Automate.

Automate. Normally done at midnight. Automate. Automate.

Automate. Every iteration. Automate. Automate.

A sacrifice. Automate. Automate. Poorly formatted source code.

Automate. Automate. Screaming for- Automate. Automate ...

the God of trails. Automate. Automate. I give you the system team haka.

Automate. Automate. Pair. Pair, pair, pair, pair, pair, pair, pair, pair.

Commit. Commit, commit, commit, commit, commit, commit, commit, commit, commit, commit, commit, commit. Integrate. Integrate.

Integrate. Integrate. Integrate. Integrating.

Deploy. Deploy. Deploy. On April Fool's Day.

Of the system team, it's rain in Brisbane. And that, I believe- We'll call a wrap. So just to clarify, this is not a group of wacky Australians. The main speaker there was a guy from Essex, with people from all over the world, and people from all sorts of different consultancies.

So that group was actually, I think, yeah, all but one was actually a contractor or a consultant from all sorts of large, well-known consultancies. So this isn't a special Australian thing. These were real people from all over the world. So as I said, I've left this group and I'm now out coaching around the world, and I now have a real problem.

Does anybody have the foggiest idea how to do this stuff with PeopleSoft? If so, please come and find me and tell me. And on that note, that's my story. Thank you, everyone.