 Okay. Hello everybody. I'm Evan Botcher. I'm from Melbourne in Australia. Give a little intro to me. I'm just going to, if someone, my voice, I will tend to, I have trouble projecting right across the room. So if anyone can't hear me at the back, just give me a little wave. I'll try and speak up. A little intro to who I am. I'm from Melbourne in Australia. I'm a software developer. I'm not a CIS admin, although for the last four or five years I've spent more time with my hands in production and scripting deployments and those sort of things working closely with CIS admins and experienced engineers. Mostly I consult now to big organisations in Australia that are trying to improve their time to market, their agility and the way that their teams are structured to make sure they get a better time to market. I like to hike. It's my family and why I put that in there. I won't give the intro to ThoughtWorks. I think you've probably got a fair idea of where we're at, what sort of things we do. But I'm going to give you a little sort of personal journey back in time. This is me in 2001. I look a little bit different. I have the same wife. She doesn't look that different. I don't know how she does it. It's magic. It's crazy. But 2001 I started learning about agile software development and what we called agile. These are the sort of things I was reading, extreme programming. I was really fascinated by the technical practices, test-driven development, unit testing and continuous integration. All the things that at a team level made it possible to build better quality software. It wasn't until I joined ThoughtWorks in around 2006 that I learned how teams, the rest of the agile practices, the collective code ownership and emergent design and deferring, planning and detailed analysis until the time we needed and how that would help us respond more quickly to customers' needs and learn from our software as we're building it. So that was really great. But back then, in that time, we were really smuggling agile into organizations. The dominant theme in big organizations was the traditional program delivery, waterfall, if you like, but big multi-year, huge funded projects that strict the company of all the great people and delivered program outcomes. We'd go in and hide in a meeting room and run a little agile team. It felt really good. We'd build a team that had all the skills and capability in it to deliver on a really good product with a close relationship with the business. That was what we called agile then. Big organizations tried to replicate that at scale, a big organization. It kind of feels a bit like Conway's Game of Life. This is a, if anyone's not familiar, it's an algorithmic simulation of a simple game of life. This is what it felt like, a big burst of activity in an organization and then just little peering bits of activity and agile teams that would eventually get swallowed up by the large organizations. It's kind of fascinating to watch. I become quite mesmerized by it. It's a bit of a puzzle how you make that kind of big change last in a big organization. This is what it feels like sometimes to be in those big organizations. If you're in a team that's building a customer experience, you're interacting with the customer, you're building a mobile application, a really common scenario is we have these teams that are kind of what we consider to be a good agile team that have a direct channel to the customer and they're building an application. They can do it in really quick cycles because they're building an application, learning from the customer, doing testing with the customer, iterating on the product and then delivering it again. That's great, but as soon as they come to touch any part of the organization that's any deeper into the core, core billing of finance systems or product and pricing, change an ESB or even build some new infrastructure, they have to deal with the core of the organization that hasn't really adopted agility. That's really common. Working with a telecommunications company in Australia, a large public company in Australia, we found that they had built a world-class digital delivery capability that could deliver small changes to mobile apps or websites very quickly, but if they actually wanted to innovate in the product space, they had to deal with a deeply entrenched, siloed, central core organization very, very slow. That's difficult. One of the attributes we like about those teams is that they have all the skills in them that can make changes across the full stack, including the infrastructure. If it's a fully DevOps team, they've got people who can administer and run the systems that they're deploying, but in a large complex organization, you end up with the number of skills required to touch those core systems becomes very, very difficult. Who's heard of the Amazon Two-Pizza team? It's a familiar concept. Amazon described their product teams as you can only have the team to the upper bound of the team size. It's the number of people that you can feed with two pizzas. That's about creating teams that communicate and work together effectively. But if you had to have a team that represented your core billing system, product management, pricing, if it's insurance or something, it's underwriting, all these core systems, you would need a team that would probably eat about 40 pizzas. So it's no longer going to be an agile team shape. A lot of people have come to the idea that agile doesn't scale. But in 10 years at ThoughtWorks, I mean to say I've been around for a little while, I've seen some really great examples of organizations at a reasonable scale that have managed to take a different approach. They aren't as constrained by that, that need to have all the teams together. And I think there's two elements that have made a really significant difference. I want to talk a little bit about those. The first, in terms of the org structure, is that the teams that are delivering digital applications, they're actually the business. And so in some organizations, we no longer see this divide between the business and IT, and that really starts often around the product space, the channels, the touch points with the customer. So digital delivery becomes a part of our business. And the recent financial services organization, they actually took their entire, the teams that were considered to be the digital teams, and they actually handed them to the business and said, you work integrated in the business, delivering product ideas in small increments out into the market, testing with the market. So that's one thing where IT and the business no longer have a divide. And the second thing that's become, has been really successful is to take those shared capabilities, the things that an organization is built on top of, and make them into internal platforms. I'll give you a little bit more about what I mean by those platforms and how it relates to DevOps as well. And the playbook, the things, common elements that I've seen among successful organizations in this space are really these three attributes. The first is that teams stop using projects, the concept of a project to deliver change. Obviously that sounds stupid, you still need something to, you know, some method or some initiative to drive change, but projects in the traditional sense with a PMO and project managers and project teams are quite damaging to organizations. And so that accepted kind of best practice of having a project and recruiting team members to create a project team that then delivers to a timeline and kind of runs out of time at the end, ships something into production and hands over to support teams. That idea is starting to go, starting to lose favor. And so projects as a, as the primary method of delivery is going away. And I mean projects, if you think, if we talk about DevOps and as being that creating teams that have a responsibility for delivering and also running what they've delivered, so build, you build it, you run it, projects tend to deliver the anti DevOps. So the antidote is to create teams that stay together and stay working with a set of applications for a longer period of time. That requires you not to have projects in the traditional sense. The next part is to establish those internal platforms that I started to talk about. And I try and illustrate that with some really crude drawings up a whiteboard. I'm sorry I had the scrollings of a of a 10 year old. But I thought this is what I was how I was describing it to a customer on the whiteboard. I just took some snapshots of it and I thought maybe that would help. We start with the customer, the customers here on the left. That actually says customers in my handwriting. Good. Customers interact with digital products, mobile application, website, mobile site, kiosk application, whatever that kind of digital product is. And so architecturally you're interacting with digital products. And those digital products and the organizations that have adopted this approach are then built on top of a platform, a business platform which is those shared capabilities. And so I've got some examples finance and payments, product and pricing was very big in an organization. I was just working with customer, CRM and customer and the onboarding of customers and registration and identity. They're business capabilities that your organization has and they're a platform. We'll come back to talk about the APRs. And then you have foundational capabilities. I'm just calling them foundational capabilities to keep them separate. And that is things like having a platform to deploy your applications on. So these platforms are deployed on application hosting platform. You might have data as a service, as a platform that you can perform poor data into and then access that data for analytics. You might have delivery tool, you might have continuous delivery tools and continuous integration tools, source control. These are foundational capabilities that everything else is built on. And at this point you kind of say okay this is just a model of your organization. This is just enterprise architecture. But the difference when I say that these things are platforms that are like an internal product. And a couple of organizations I've worked with have said pretty much these, the teams that are associated with this platform are like an internal vendor. Like a software as a service vendor for this capability. And their responsibility is to deliver that capability via an API so that these digital teams can move as fast as they want building new product on top of those. So it's a, it is a subtly different philosophy and focus. And then when we get down into the infrastructure side we'll come back and talk to talk to how that's how that's been impacted. And the thing that the sort of dirty truth or the ugly truth is that most organizations have their shared capabilities but their complete boat anchors, they're just slowing the organization down. Because they don't provide a very compelling or productive experience. The team's trying to build product on top of your hosting platform or your or your core product and pricing platform. Right now it's a very slow experience. You have to create project structures that allow for change in the digital product and then wait weeks and weeks for changes to be made in the core product system and then for hosting to happen in weeks and weeks. So they're not they're not designed for a quality of service. So compelling. I've done this exercise before with teams where I get a blank gray box and some marker pens and paper and get people to draw what's compelling about their offering internally. They're thinking about internal customers who are going to use their system and why they should use that system. We're working with a document management platform within an insurance company and that that document management platform in order to make a change to a product you needed to change the document templates will be sent to customers and you needed to engage the project manager and then that work to change document template might take weeks to be scheduled into a queue to make a very small change to a template and you like 10 weeks later you've got your product change ready to go to go to market. That's not a compelling experience it's not helping us get our product to market quicker so it has to change to be more self-service for the for the for the business and for the product teams and then the bit about team like the soft skills that's the bit that affects people is that we want to create stable teams that operate the platforms and take and take responsibility for the plot for those platforms so for each of these products we have a product team that might be building a in a banking situation of building a mobile application to allow for loan origination we might have the platform team will have a team that that runs the finance and payments capability and they live with that for a long period of time you know maybe months maybe years and they take responsibility full responsibility for every feature that's on there and they take the operational responsibility in that DevOps way where they're on the pager and on the pager rotation for that so organizing in this way has helped these organizations say okay yeah we're going to create a boundary within which we'll do we'll do the DevOps shared responsibility so one of the things that's important there is we have a product owner and this is one of the challenges that that organizations have is when you've got an internal platform who is you know what is the product who's the product owner and how do they meet all the the requirements that are being placed on them the product owner on these platform teams they own the roadmap of features that are going to be available on this platform and they if that feature roadmap doesn't meet the requirements of the digital products that are being built on it that other people have to negotiate for for the priority but that product owner needs to be strong and say I'm building it I'm building a sales force like experience not a not just saying yes to every requirement comes in and the delivery team for a platform needs to have all the skills in it required to to deliver including being able to operate and troubleshoot and triage problems test the software showcase their design interfaces everything they need so so we're talking about a properly cross-functional delivery team and what happens when you when you build a team that's that's running like that is and in organizations that I've seen that are successful they increase the level of autonomy that those teams have so that those teams are encouraged to make their own technical decisions without having to go through some central design authority and governance that in order to run that platform an increased level of ownership of that of the outcome also comes with an ability to make your own decisions that might affect that will affect the application stability and just this is my go-to label for how we've done that in scale at numerous organizations is that the work that Spotify published around the the tribes and guilds chapters organizational structure and we've we've built platforms that are a tribe if you haven't read the Spotify material on how they structure their teams including that there's some quite good videos that describe how that works I highly recommend it it's a way of balancing the the independence of a team to make its own decisions with communities practice that allow teams to share what's working what's not what the best outcomes of the company so I want to whiz through I want to take all night but I want to talk about some of the changes that happen when you when you adopt a structure like this I want to talk about architecture a lot of these organizations that I go to have a start with a centralized enterprise architecture team solution architects and technical architects and infrastructure architects and all projects must go with a solution design and has to be signed off by those teams and that that just gets tipped completely on its head in a structure of platforms so clearly we just disband the architecture team and we push people the technical leaders out into the platform teams to help the the delivery teams make decisions job done or maybe I'll come back to that program management I said that we're not doing projects anymore projects and multi-year programs what's not quite true still have have to have an understanding of what work is being done and where spend is and what benefits are happening but these organizations it's not my area of specialty but they shrink their their overall PMO and they they attack a more smaller delivery tranches smaller bits of work that are fed into the into the platform teams to deliver this is blurred out but this is six months worth of planned work for a Australian Stock Exchange top 20 company in the financial services area and each of these pieces of work is a is a starts with a hypothesis this is a benefit that we think we'll get a set of experiments that will that will determine whether it should be funded and then when it moves into funding beyond this wall it's only ever funded for short periods of time so you're constantly getting opportunities to measure the whether the the delivery is working which works quite well there's a lot more on ThoughtWorks.com insights channel for for lean, lean governance integration and data that changes I said that that API is the essentially the front door the the product that these that a platform is providing and so making that a compelling API becomes the the measure of success and so you know high quality APIs that are discoverable and accessible that they're robust they survive through change and they're easy to integrate with that becomes the the measure by which your teams should work and there's also a big impact on data that we've managed in number of organizations to shift away from the traditional ETL based data warehousing and make the platforms responsible for high quality data infrastructure and operations that might be might be of interest to this group obviously I'll tell a little story about a financial services organization I was working with in Australia we we went to them and one of the first things I did in consulting with them was to go and ask them how they make a change to their production infrastructure and I was I went through a few scenarios and depending on the type of change they were you may have to involve the automation team the middleware team who own the application server configurations the mid-range team who own the operating system underlying that the the virtualization platform owned by the wind held team then if you need to change storage you need the storage team and the network you need networks both of which were outsourced the separate change management and release management teams and the enterprise monitoring team if you need to change the significant part of your service there's there's actually a few more security obviously and internal risk and each of those teams were might even sit in the same building but they did not communicate they were separate siloed parts of our organization that hated each other I've met teams that have a dev ops problem but I've never actually met one that has a dev ops ops ops ops ops ops ops problem quite that bad every one of those teams was acting like they weren't acting evil they were acting perfectly sane within the constraints that they had they were optimizing for what they what they had to deliver and what they needed to protect but nobody was measuring how long it took to stand up a new service and so we you know once it came to light how long it was in the months it would take to deploy a new service that was with the right support that was declared not good enough and so we started to build a new infrastructure platform infrastructure on demand that would exhibit what we consider would be a good platform for deploying on top of and then some of the key elements of that were that the the teams that are building products or platform business level platforms must be able to access things things through a self-service API and and not just that they could access the thing through an API and then have no control over it they must then be able to provision and and configure the service complete the complete stack and no no tickets and I put an Aster on there because there were still things that like you might need to do once every six months six or 12 months you could you could live with that but but essentially get getting rid of the idea of dealing with infrastructure teams via tickets and completely self-service and I don't need to tell you guys that that really drove a shift as soon as the first team this was in a financial services organization highly regulated but the first team who who gained access to AWS drove up the demand on the internal organization to the point where they needed to to react so these are the sort of technologies if I'm talking to stakeholders that they need to be looking at not it's obviously more than cloud foundry but but Paz and IS services both public public cloud and and potentially private cloud and make those those services available directly to the teams that that need to deliver on software on top of them not provide create some layer that takes a ticket and then uses the AWS you know console to spin something up manually that actually provide a compelling service by by procuring access directly to the cloud platforms but it's we found it's not enough that the teams delivery teams this you know in a larger organization will by by human nature still want a team to do things for them because there's a learning curve a steep learning curve to be able to effectively use some of these technologies and for us to you know expand on this I don't know if everyone's seen this that's an open source representation of kind of a a mapping of all of the things that are in the cloud native world there is a large there's a vast array of choices and there's a huge learning curve for a your typical enterprise development shop to learn how to use these things so I've got a subtle plug here for my colleague Keith this book what we set up for as part of the platform for hosting and and operations was consulting kits patterns and starter kits sample code sitting in repositories education materials that allowed the delivery teams in the organization to use the power that was going to be given to them when they had direct access to the cloud interfaces is interesting 18 months of working in a large financial services organization a team that we kicked off at the very start paved the very first path to production that was independent of all those 17s or eight or nine silos in the in the ops area and they they did that they built they built out with a very very small part of their application stack and they were able to deploy that they were deploying it twice a week which was unheard of in an organization that was still only deploying at best once a month and sometimes once a quarter and 18 months later I kind of caught up with them again to see see how they're going and they were on a on a weekly basis rebuilding their production cluster from scratch which you know fully patched up to the latest versions disposing of all their production servers and redeploying all their their entire application stack without any interruption of service and ensuring that everything was completely up to date to security vulnerabilities and anything else that was needed and that was completely unheard of in that organization patch management was a horrible horrible mess of changing servers inconsistently across different environments and so their their infrastructure's code approach completely changed or created an appetite for people to make use of their their platform now so it was a great success continuous delivery in the large organization I said that they they would only be deploying once every quarter the shift that comes with that platform model is we want those platforms we've actually made a constraint in two two of my clients a rule that said you can't deploy together but we're used to doing enterprise releases everybody goes into into SIP once we do lots and lots of end-to-end testing across the the applications and then everybody goes into production on one horrible day once a quarter and then they move to some of those applications would go every month but they would still a bulk of applications would go into assistance integration environment together and we actually said these these teams would have a platform that platform might be eight or ten applications but two platforms can't deploy together they can't rely on being deployed together so that so to drive that behavior around independence of deployment and and that actually is quite scary because you start to have to make architectural changes to your applications interfaces and dependencies between them and that takes time but they've managed to increment towards it which is great and then you have to walk through the the change that comes for the change management and release management functions that are working in a regulated financial market that are used to having careful stage deployments into into environments and and a centralized register of documentation and and approvals we're actually moving more of that responsibility out to the platform teams which actually then requires education of those teams as to why those controls are in place what's the purpose of segregation of duties what is our obligation to the regulators and and we made last organization I worked with I think called the enterprise deployment framework which sounds horrible sounds really big in enterprisey but it's actually just a set of pre-approved patterns and guidance and education on on what you would need to do in order to have a a path to production that was independent Oscar played it out I'll come back to to architecture really briefly really yeah I've said that we have these teams that are that are fully cross-functional teams they have their own architecture and design capability technical they can deploy and release on demand so you don't need a centralized architecture team anymore except that you do actually have a few things they need in order to help those teams align what they're building to an overall strategy it's kind of enterprise architecturey stuff but also to help meet the governor the compliance requirements so sometimes you need a centralized function to help teach teams and establish processes for recording architectural decisions deployment approvals and make the all that information available to the audience so that was one one area that was there I think I talk about these teams that have complete control over their own decision-making and technical design and how they even make use of cloud services and how they deploy they won organization in Australia at a dot-com and online business but at a reasonable scale they have seven platform teams they're all were completely independent they would meet the tech leads would meet once a week and discuss what they were what they were considering to be the best you know best outcomes but ultimately they they could develop whatever they wanted and so they pushed very much towards the right high high degree of of platform autonomy meant that they actually duplicated solutions that would solve the same problem in two or three different different ways and then share them show them together and then work out which one is best and then rework everything to kind of go with the latest new version so you had a high degree of innovation and experimentation and organizations tend to if they allow a little bit of this they get really scared of duplication everybody's doing things differently it doesn't you know it must be very expensive but actually actually a little bit of that has great benefits and if you come too far back to the left of consolidating and having central solutions that they quickly become a constraint become the boat anchors again so forcing everyone to use one application server technology because it would be cheaper it becomes the argument of the day so it's really there's something here that the teams and technical leaders can really monitor and they can tweak and sort of push the lever a little bit more towards allowing teams to do their own things and then when you see that there's a common solution you can actually pull that back and make it a platform offering that other teams can build on so I've seen a lot of that I'll wind up the three things that that I've kind of that these are the things that I'm passionate about right now this is the playbook that we're we're talking I'm talking to customers about it's kind of ending project and creating stable teams that have full responsibility cradle to grave for platforms which are a platform for your business to do innovation on top of so I hope that all makes it just brought up my test how do we sell to the business about like because project then we have my plan so when I can stop paying the money and see the results but in product I have no it's only money all the times and you didn't even guarantee that you will see I will see the results so how do you sell to the the same results and that's period right into it the same results so there's a couple of things there one you can turn you can sell a lot of this thinking based on the cost of delay so like the the programs the big big big programs that we see generally you know are very slow very long long to deliver they're not creating an environment in which the digital teams can experiment around product and engage directly with the customer and and organizations like the insurance the financial services company I was working with they are scared very scared I won't swear to that they are going to be disrupted by by someone who has a direct interaction with the customer and can respond really quickly to their need so you need to create a structure that allows really quick product innovation to where you interact with the customer and then put a veneer over the slower moving legacy systems that they've got so so there's a big big business case around that to to allow for those that digital innovation the program and the project versus product our funding model is something that that people need a lot of help to get over products and my naive I'm a technical technologist not a not an accountant but there are a lot of it's driven by the the convenience of separating out capital expenditure and operational expenditure you can see that that kind of approaches kind of created these divisions all across the place but it doesn't it doesn't benefit the outcome so there's a lot of work to help people understand how they can do a different style of funding this stuff works basically a management consultant like the McKinsey or do you also or differently create digital products or what kind of space do you want to buy yes traditionally we are more around software delivery in a new using modern software engineering techniques so we do more of a delivery delivery shop for many years we've done we've done consulting around as a as a part of our business around everything from organizational structures to agile software to you know delivery in our league so it's a portion of our business is the consulting part the answer about saying you know giving the idea to your customer that they might be frightened of how other competitors act on the market even new ones that they don't know about yet they know that they have been disruptive in other markets like amazon all right so it can happen and there's this tendency of justifying putting in new ways of doing the work that needs to be done enjoy the DevOps from a business perspective telling them why is it good for the business and then there is this this other way of doing it telling them why is this good to survive do you have a feeling that actually companies or customers change their mind of this not asking so much about the business anymore but asking what can you do with us to help us survive in a market that changes faster and faster and faster and actually have fear of people coming up from somewhere else and doing things better than the last one we have gone is there is there a change or are they still only looking at what is the quite only doing better I think we have more conversations now around with organizations that are recognizing that they're too big they have too much legacy and they're too slow and they need a way to to survive like actually like that survival the conversation comes up more you'll see there's a slide or a picture I think it's HBR that shows the the average lifetime of a of a of a company maybe it's a S&P top 500 company or how long how long they're going to be there before they you know and it's it is dropping companies live for 50 years and now they live for three years and so so everyone's quite aware of how at risk they are and sometimes the biggest the biggest organizations for all the quickest I'd like to use the electric casting so in a government that we have all these companies set for years technology is not there there's no market for it nobody wants to buy it and then suddenly they see oh all around us people start buying electric cast from other people from other from other manufacturers now suddenly they change they don't argue in the market they don't argue with technology anymore they just say that oh once we start we're going to make it better but you see them being scared to hell there's also a real a real strong theme that organizations want to not be a want to be a technology business not many I don't see too many organizations at scale that actually achieve it but the words are there the intent is there that they that they need to to not have an IT department as a cost center that actually need to be a technology organization and I think what we talk about is taking part like the early parts is taking those customer touch points and putting them in the business that making teams that look like what we love just agile teams in the mid-2000s part of that business unit I think you have an interesting concept about the PMO and the sort of a capital costing structure being ineffective however what I would observe is let's say you have a bank they want to put out some great app like slowly higher up or whatever and once the app is out there they just basically go into maintenance and it will effectively like change the color of the territory so how does that fit when you're saying something with your idea about creating stable teams it seems that you're not sure the world is still in the project what are you looking at the future of what what does that work well I think it's I think not many organizations are ready to abandon that kind of we'll do this project and then switch it into maintenance so they're not ready but if you've deployed an application you're a bank and you're not working on its features continuously then how can you compete against the disruptors that are going to have the new features every couple of months they're working with a sorry I know of one bank I've talked to them which is not it's not a traditional bank at all it's a less than 500 person company now has a banking license in Australia completely online company came from the pause market they're going to they're going to create a really compelling experience around dealing with the bank that the big incumbents can't can't deal with and so if they're thinking they deploy an application and then that's okay they leave that for a three-year depreciation cycle before they invest in it again that's not going to work but it's not my area especially tonight you know that's and I heard that Gordon Goldman Sachs just threw it on my bank essentially as you described me because they want a piece of that mark cool I think that's all the time we have thank you so much