 So my name's Chris Gaines, I'm President and CEO of Scale Agile. That's the company that invests and develops safe with Dean Levinwell and his team. And some of you may be expecting Francis Kelly. He's not here today so he asked me to do this, he had a family commitment. And I was happy to come to Bangalore because I thought, great, I could watch India play Australia. And then you guys only had a three and a half day test, so that didn't help. So I missed the cricket, so I'm a bit disappointed about that. I'm from the UK, cricket rugby player, but I live now in Boulder, Colorado, which is where we developed SAFE. So today's talk is about accelerating value delivery with DevOps and the Scale Agile framework. So I'm going to spend a little bit of time talking about, I never have any luck with these. I'm going to be talking briefly about SAFE and if any of you need to go into any detail, we do have some of these at our booth, which is an introduction to SAFE. And in your bag, you also got this, which I'll have up shortly and you may want to refer to it as we go through, especially if you're at the back. But we'll talk about lean agile values and principles, which underpin SAFE. And then I'll go into the DevOps and the DevOps challenges. And then talk about the emerging, calmer and safer approach to DevOps that we're working on right now. And I'll share that with you. So a little bit about my history. I've spent 30 years in IT and some of these companies don't longer exist. Now that's not a reflection on me, but some of you may know Digital. This is a great company, super pioneering company at its time, but it's demise. I learned a lot there about serving customers. Some micro systems was my next company. That was a super company. We were the dot in dot com. Those of you who remember dot com. It was a great time to be at Sun. The emerging platform or the platform of choice for the internet at that time was Solaris with Oracle on Sun hardware. And that was it. And we were just taking orders off the fax machine. Remember fax machines? So it was a great time. So I rolled up the dot com and then came down with it on the bubble. And Sun ended up at Oracle and I had a good time there. Learned a lot about Larry Allison's view of how you do business and how you compete within the same company. So it was great. And he took ownership of Java and I'm delighted that he's sort of looked after Java. He hasn't looked after Solaris so well. Looks like we won't be progressing Solaris, but he has looked after Java. And then I joined Rally. A lot of my friends from those companies had joined startups and they would call me from their yachts and talk about how well they were doing. And I thought I'd better join a startup. So I went to Rally and I was about the 200th person who joined that company. And they grew it to about 550, went through IPO on the New York Stock Exchange. It was a lot of fun. And then they've just been recently bought by CA. And I'm now at Scaled Agile and enjoying my time there. But some of the things I've learned in this 30 years in these IT companies is that business agility is really hard. And any support you can give individuals within these companies who are big and dealing with big complex systems and developing big complex systems, they need all the help they can get. And it's all about people. It's all about transforming the way people work. And it's critical to provide individuals really good support. And by the way, I think to a person I've met working in this industry and the industries you're in, these are good people, really trying to do good work and trying to bring their best every day to work. It's hardly anyone I've worked with involved in the IT who's not been authentic and really trying to get things done. So, let's talk about SAFE. Now if any of you see anything like this on me, just let me know. Because the SAFE guy often gets some bullets. So just let me know if you see anything. As you know, the SAFE is a freely revealed knowledge base of integrated proven pattern for enterprise lean agile development and lean agile practices. It's knowledge for people building the world's most important system. And it's designed for the largest system. Our target audience for this is the Fortune 2000. The people who are really putting big systems together. And Dean has always said if people stop building complex systems, I won't have such a big framework. But these days with, you know, a mobile app having to support and install activity, security, large databases, different web services, pulling it all together with big data, et cetera, it gets complex. And the teams that we're working with are in their thousands. And the framework is designed to support them. Now it doesn't mean that people who have companies of 50, 60 or teams of 100 aren't using SAFE. But the design is for the largest companies and the largest systems. So apologies at the back if you can't see it. But you do have that picture in one of your, in the bag insert. So the core values, or before I go, SAFE synchronizes alignment and collaboration. And that's a key part of this. It is about collaboration. It's about people. It's about people having visibility and aligning to produce something of value. And supporting a large number of agile teams. And SAFE is built around, oops, oops, sorry. SAFE is built around teams. That's a key part of this, making teams successful. The other construct is the agile release strain. It's an organizing function for 50 to 120 people, 10 to 15 teams. And it's a key part of SAFE. But the core values of SAFE are around built-in quality. And you'll hear, you'll find lots of places where we're looking at continuous improvement. And that applies to the SAFE itself. It's about five years old, really, in terms of being a public published framework and big picture. And we're on version four, probably get to version 4.5 this year. But it is about continuous improvement, looking at how the framework can evolve. And if you go to the website, it's a live site. There are blogs and articles and guidance that are continually evolving. And don't forget, when you visit the site, each of these icons is alive. You can roll over it, click and get a guidance article and links to other material that are behind it. So, built-in quality, program execution, there's nothing without execution, alignment, as I said, and transparency. So that we have transparency across the teams, across the art, and across the value stream. So, nothing beats an agile team. Cross-functional has all the pieces to build something of value. So, they can divine, build, and test. Self-organizing, for the most part, self-managing. It applies the basic scientific approach of plan, do, check, adjust. And we'll see that continue right through. And it delivers value every two weeks. If it can't deliver value every two weeks, it's likely that the infrastructure or the team makeup is not quite correct. But it's been designed to do that. Now, he said nothing beats an agile team except a team of teams. And the art, the art aligns about, as I said, 50 to 125 practitioners to a common mission. And then they have cadence and synchronization across the program increments, which last about six to 12 weeks. We run our company on safe and we have a 13-week cadence. But other companies, the largest, sometimes do six, eight, 10, or 12-week PI. Now, we provide a vision and a roadmap and architectural guidance to the team. So, for example, we might say, you know, for single sign on, here's the architectural guidance for that and apply that consistently across the different value that's being created. So, this is how often that we work. We're in silo. We've got our own focus area and we're working within that area. Now, with the art, with the agile release train, what we're trying to do is have a group of people working together, collaborating, transparency, have the cross-functional skills within the art to produce a thing of value. So, we might have customer representatives, the business owners, product management, systems engineering, hardware, software, UX, testing, and those involved in deployment. When we get into the DevOps part of this, it's really important that the DevOps team and the representatives from DevOps are in the art. So, the demonstration of the full system every two weeks is a really important part of how we work in, say, demonstrating an integrated solution, an object, milestone of value, demo from the staging environment or its nearest proxy. Again, that's a key part that links the DevOps in that we're developing in an environment that's very similar or identical to the environment that we will be in production and that's a key part of what we encourage. So, the whole team gets together and demos every two weeks and it's a really good environment then to get everyone on the same page and see how progress is happening. A key part of every PI is the inspect and adapt. This is where we look for impediments within the team and try and understand them. Identify the problem in six stages. Identify a problem to solve and often the teams will have three, four, five, ten problems that they think and it's really important to get down to about one or two. I think within a PI it's not possible to work on more than one really if it's an agent impediment. I like to narrow it but often we end up with two. You apply root cause analysis in the five Ys to understand the root cause. Identify the biggest root cause using Pareto analysis, restate the problem for the biggest root cause and then if you're close start to brainstorm solutions. And then it's key then to put those improvement items and the activities associated with it into your backlog and work on them during the PI and that gives the sense of continuous improvement. The teams see us working on problems that are impeding them and they see solutions being applied. It's a really important part of safe and the art process. So we build a portfolio organized around value. I'm trying to get away from the camera but we identify and organize around value streams. We communicate the enterprise strategy. There's a connection between the enterprise to make sure the value is connected to the biggest value that the enterprise expects. So the strategic themes are very important connector. We empower decision makers with lean agile budgeting which is different from project cost accounting. And there's some really good articles on safe. If you go here and click on budgets you'll see a long article there that contrasts the two and explains the value of investing in value streams as opposed to projects. And that's a good starting point if you want to learn about that. And then we provide visibility and governance via Kanban. And that's a feature of safe. You'll see things like Scrum, Scrum XP, Kanban. These are proven patterns that work. And often when you look at safe you'll think well that's very complicated. But if you look at each piece of it you're probably already very familiar with them. And what Dean and the team have done is pull them together into one coordinated big picture. But each piece is probably familiar to you in some way. In April 2016 SimCorp's product division which is, we had nothing to do with this video but this is SimCorp's recent start up on safe. And this video is on YouTube last month. And you'll see how they started safe and went through some of these things. This is a short video I'll share that with you. Hopefully we can get the audio going. In April 2016 SimCorp's product division launched their first agile release train and began the journey towards becoming an agile organization. Let's check in and see how they're doing. So what the Scale Agile Framework does is it takes best practice for scaling agile to an enterprise level. And that practice is brought into the same framework and put into a kind of coherent model that can be rolled out quite simply in fact across large organizations. Scale Agile Framework also has an ingredients of lean in it as well as Scrum. Those two things combined with the document framework really is a game changer when you want to scale an enterprise scale. We get closer to the customers or develop products that the customers actually want to use and we can do it with a better quality and a better predictability of what we can actually deliver. When I talk to people who have tried it now for quite some time then I get the feeling it is really working. But they talk today about value creation and it's not just an abstract thing. It's real life and their experience in a different way of working allows them to create more value. I think this is a much better way of working, that's for sure. From my perspective I think we will probably start delivering software which is more usable from an intrusive perspective. The whole production mission has now started talking in the same language using the same concepts. I think the feedback we get from our product management is that they can demo this feature to find while we are developing it and what they name it while. That's why it's so important and this is what was one of the reasons why we changed our gel wear. It encourages all these continuous improvements so you got to learn something new and improve all the time. The main challenge has been forming a new organization that we took that decision in the spring that the going agile will also need to change the organization. Going away from a plan-driven and analytic approach to a more experimental approach where just get started, let's get going and then learn from it. The coming agile is perhaps the biggest challenge we will see also in the coming years because it's not done in half a year, that takes more time. And that's also tough on us and some of my people and myself to really become a servant leader to empower people, to empower teams, to make sure that they work across teams. This is what is a challenge for us. SimCorp have been doing a very ambitious job in the last year. They've gone from a heavily governed waterfall process and they've started to go agile all at once as it were. So they've been rolling out agile at the team level as well as looking at how to scale that using safe. And they're doing that across seven trains at roughly the same time. I think one of the key enablers that has enabled this in this organization is that senior management has been very favorable or driving the change here. So they have believed in the process, they believe that the productivity will kick in as soon as we have made the transformation. And that's really key. So the involvement from senior management is extremely important. We really have learned that it's necessary not to only work agile, but to become agile. It's about people and it's about change and it's also about engaging leadership. And you saw the struggle that George, the CTO, is going through as he starts to identify the different mindset he'll need. And he mentioned servant leadership. And this is a big challenge when you're doing these types of transformation that the leadership are one, engaged and two, go through that change in mindset. And it's difficult and one of the things we can have is management empathy as they go through that, but it will take a while. So as I said, he has to embrace a different mindset, a lean agile mindset and these are the two key elements of that for us. One, the house of lean value delivered in sustainably shortest lead time. And that sustainability is about the flow of work through the system. The core component is respect for people and culture. You can't do this without the respect for the people. It's about people transforming. It's about leadership engagement. It's about flow. It's about innovation. If you don't innovate, you won't survive. So it's key that is innovation and time for innovation within the work. And then it's about relentless improvement, a constant sense of danger, continuous improvement is a critical factor. And then underpinned by leadership engagement. If you don't have that leadership engagement, at some point there's going to be difficulties. And the key part and in all our training is obviously the agile manifesto. We believe that this is key for unlocking the intrinsic value of the knowledge workers within the organization. Individuals and interactions over processes and tools. Talking, collaborating is key. And then the working software over comprehensive documentation, customer collaboration, responding to change. This is always part of our training and a key part of the mindset that's needed to underpin SAFE. So we also have what we call SAFE's lean agile principles. There are nine of them and principles, Trump practices. If you're ever stuck, we always go back to these principles. And we're often thinking about decentralized decision making. Where should that decision be made? Is it one that should be centralized or is it one that the team should be making? We're always thinking about visualizing and limiting WIP, reducing back size and managing queue lengths. Because the flow of WIP through the system, through the art, is critical. I won't go through all of these, but if you'd like to study them and understand them, you can go to the website. So let's talk about DevOps then and some of the issues and how SAFE is planning to support this. So we've all been as users or as development teams, there are any ops staff here. We know this scenario where there is this divide, this challenge. Sometimes you'll see this diagram with a wall built between the two where there is ongoing dialogue and tension between the two groups. So this is the problem we're trying to solve. Now it's not easy because in development, we probably have been practicing some level of agility for a while. So we're used to creating change, wanting to deliver value in small batches. Whereas operations is working the other way. They're trying to have stable systems. They're trying to reduce the amount of change so they can keep the systems stable. And so this can look like a real challenge. What is DevOps? It's an agile approach to bridge the gap between software development and IT operations to deliver value more reliably. And this is why they should be part of the art and working with us as part of the team. So DevOps challenges, they often don't have automation for the test systems and the deployment systems that they need. Often you can be developing in one system and deploying in another, testing in another. And that can also cause issues. Large batches are produced to production and causing the Monday morning effect, which is that scramble to try and recover back to the last stable moment of the system. And then there's lack of communication. The ops can be quite close to what the users are saying and that feedback loop is not in place. And then lack of trust. There's that challenge always pushing against each other. So how many people have read this book, Phoenix Project? I would recommend this book to you. This is a really good read. Gene Kim and Kevin and George put together a really good novel. It's a novel, it's not a reference guide. It takes you through the life of a company and the DevOps challenges that they face. And one of the key quotes in there is about getting version control, automating as much as possible, getting a deployment pipeline where you can create tests and produce environments and then deploy code into them entirely on demand. And the deployment pipeline is a key part of DevOps. So let's just talk about safe approach to it. We call it a calmer and safer approach. Has these five elements of culture, automation, lean flow, keeping batch size is small, measuring value as it throws through the pipeline and recovery. And this is what we call the calmer approach. We've had a safer approach, now we're getting the calmer approach. It's good. So first up then is culture. Let's just talk a little bit about that. You can imagine that a cultural shift is needed. This is a different view of it. We had that wall view and that pushing view against each other. This is the same side of the one coin. It's a culture of shared responsibility. It's not one team in so much of this, more about collaboration and working together and shifting responsibility upstream. So planning together, verifying, packaging, release, configure, monitor, so that this phase, much earlier, working together and collaborating together. So another quick video about Bing's approach to this. And you'll hear them talk about some of the challenges they've had and they'll talk about test and the cultural change. When it comes to continuous delivery, testing is the most important thing. You can't have agility without testing. When we were shipping monthly, there were some tests and some of those tests were run and of the tests that ran, some of them passed and of the tests that passed, some of them actually targeted the code. We had multiple different test environments, some of which were working at given time, some of which never worked ever. Profile of the machines weren't the same, the configuration, the authentication, whatever. They weren't exactly the same. Tests running before checking some code that would take your machine, no kidding, three hours running tests on my local machine. Every developer would have a nightly build and if that failed, your day was probably almost lost because it would take four hours for you to build everything again. People were fighting over making sure that their stuff got released and they were being blocked by another team. It became unbearable to the developers because they were constantly dealing with a certain amount of flakiness. We didn't have the culture of fast shipping, for say. We had to kind of bring it out within ourselves. We said, we're going to run tests, they're always going to pass, or if they're not going to pass then we're going to get rid of them. There is no gray area. We will always run your tests. That was a complete change in the ownership model. It was difficult. It was a difficult time period. The big cultural shift was really taking direct responsibility for all of the code that you write and appreciating that the person who's in charge of the quality for our customers is you, you just have to work differently. Working incrementally, write tests as you write your feature and make sure that your feature is testable. The agility team implemented was automated process for everything. So the entire build process can now be automated in the cloud. The whole test suite happens in the cloud and it's important for any change that we submit to have integration tests that are completely automated. So what that means is each test needs to be extremely reliable otherwise the whole system would not work. So our testing reliability is about 99.98 right now. The tests run in the same system that our customers use. So there's no difference between our test infrastructure or our test environment and our customer's environment. Every time a test fails, we investigate. There is no free path in our test cases. We decided that any failed test was going to generate a blocking bug. If there were no blocking bugs, the code would go out the door. And if there was at least one blocking bug, then we wouldn't. So there was no emotion. There was no passion. There was no battles back and forth. There was one query that everyone could look at and see whether we had a shipable build. You don't want to be the guy who blocks shipping. You're blocking 600 people from getting their code out the door if you have a failing test. Everyone's in it together. It's all or nothing. Currently we have one branch. Everybody works on the same branch. It's checked in. It's checked in. We saw the number of change lists per week for developer go up. It almost doubled. Now we see them running so far out in front of us that we're struggling to keep up with their demands. So that's agility working properly. So from prototyping, to development, to validation, to deployment, to experimentation, to analysis, all those things are seeing revolutions now because of the work that we've done. We support all the different experiences, all the different markets, all the different languages. I mean, the permutation are just amazing and blowing. I don't think a lot of people know how much our test infrastructure was behind until we compare it to now and we have a much better way of joining things. So cultural change. People changing and going through that change process. And they also talked about automating the delivery pipeline. I think we'd agree, real value only occurs when the end users are successfully operating the solution. That's when real value occurs. So there are six items I'm just going to cover that really support that in terms of automation. Build and maintain a production equivalent staging environment. Seems obvious, but having an equivalent production staging environment for your demos so that you can catch errors early is critical. Maintaining development test environments that match as well and then deploying to staging every iteration so that you can test whether it's going to work as planned. And then putting everything under version control. It always pushes just to release something but not having those version numbers and then version control is critical. And then automating as much as possible including building the environment. And then start automating the actual deployment process. There's much automation as you can build in. Then you've got to achieve lean throw through the pipeline. So this is based on the work of Don Rynatson. Many people read that book. Okay, cool. I know a couple of people who finished it. It's a very dense but important piece of work. Don reminds us that around U-curve optimization which is a familiar part of lean and this is where you have this intersection of transaction costs and holding costs. So releasing one or two features has high transaction costs but low holding costs. Batching items has high holding costs but you've got a big batch. So in more detail, let me share that with you. So in this case we're looking at what are in the transaction costs. Well you've got your integration costs, your testing costs, your data conversion costs and if you have a small batch, the cost is high but if you batch together you can reduce that cost. And then your holding costs, you know, where you have very few features and stories going through but when you batch them together you risk then decay in value because the users don't get access to that value early enough and that can decay the value. You don't get fast feedback because you've batched them together and it takes a longer time to identify problems because of the size of the batch. So this transaction costs and holding costs you're looking for the sweet spot, the optimum, the place that is going to work the best for you and that's a key part of lean throw through the delivery pipeline. So let's have a look at this quick video. I think I've got one more and you'll see how transaction costs were reduced. One that was very manual and then one was very automated and it's based on Formula One. So that's a hammer. Let's watch. Change the glass. A Krillman polishes the windshield as Holland moves away just 67 seconds after he stops. So that's 67 seconds. Watch this one. That was 1.7 seconds. So they had architected a lot more in there. A lot more automation was in that second one. So measurement is key. Measuring the flow of value. So building applications with telemetry, collecting data so that you can collect data on business, application, infrastructure, the client level. Collect data about the deployment pipeline itself and then make sure you're meeting the needs of the different stakeholders and then make that measurement very visible. Display those measurements on big visible information radiators, BVIRs. So you can communicate what's happening. You can share that information readily and communicate critical alerts and then correlate that with what's happening when you're deploying, when you're releasing and then continuously improve that and make sure you're measuring the end value, the business value, as well as all the activities in between. It's a key part for people to understand what's going on and sharing that with the team is very important. So you're architect for recoverability too. So the final R. Canary leases. That's a play back to when we used to take canaries down the mine. And if the canary died, there was a warning that you needed to get out of the mine. And similar, you can put your system out there and have it tested before you give it to all of the users to test for that it's working as planned. And rehearsing failures using Chaos Monkey. This was developed by Netflix to test there Amazon web services capability. And it's now, which would try and create failures in their system so that they could learn from it and be prepared. And that's a set of software tools that are available open source. And then build the environment both for rollback, rollback to the latest viable moment, but also fix forward. And have that built into the system so you can fix forward on the next release. And then use feature toggles instead of feature branches. Instead of working on a branch which has the new feature, use a toggle to switch it on for testing or switch it off or switch it on for a few users to test it. Doing dark launches, putting the software out into the production environment well before release to see if it's causing any issues. And decouple components and use microservices as well. So that's karma, which is the five-step areas that we're going to be evolving and developing in safe to support DevOps. So just quickly talk about safe and business results. These results, the way it employs, 30 to 75% faster time to market, 50% defect reduction, and 20 to 50%. They're not our results. This isn't data from Scaled Agile. This is from case studies that are available on the framework. There's a growing list of them that are written by customers. They're not written by Scaled Agile. They really give the detail about how they've used them, how they've used safe and gained those business benefits. So finally, if you'd like to gain the knowledge, please, freely available, all the detail. There's a whole Wikipedia of information behind safe. Each of those elements is clickable, and we do have training which is also described at ScaledAge.com. Thanks very much for your patience. Thanks for joining us. Appreciate it. Thank you.