 We've got a double act coming up next from Etienne Zaninotto and Peter Britten. So Etienne is Program Director of the Agile Scale Transformation with Societés General Investment Banking. Prior to this appointment Etienne has led several various transformation teams and programmes within the Investment Banking Front Office and the Risk Department, lastly a COO of the Front Office CBA desk. Peter Britten is the Vice President of Fidelity and Architecture Chapter Area Leader for Technology and Strategy within the Fidelity Personal Investing Business Unit. Within that unit Peter has overall responsibility for the technology, architectural strategies and solutions architectures operationalised within the Domains, Tribes, Squads and Functional Areas which are the constituent components of the Personal Investment Agile Operating Model. Peter is a member of the Enterprise Technology Advisory Group. The TAG whose primary responsibility is execution of the Fidelity CIO Council Agenda combined with the establishment of broad technology strategies and standards across Fidelity. The TAG is comprised of all of the CTOs and Heads of Architecture. And as I say the presentation today will be on Scaling Agile Lessons Learned. Gentlemen, welcome to both of you. I will hand over to whoever is going first but a warm welcome from the Open Group virtually please for Etienne and Peter. Okay, hello everyone. Nice to talk to you today and thank you to invite me for this testimony of the transformation that we are still following at the investment banking of Société Générale. So today I will do a quick introduction. Then I will explain the transformation that we've made to move to an agile scale model and then a few lessons learned I want to share with you. Quickly first, who are we? Société Générale, I don't know if it's a French bank but the investment banking of Société Générale is made of around 22 people in 70 countries and within these environments we've decided to go for an agile scale transformation in 2017. I will just explain the history after a while but the agile scale transformation was done at the level of the support functions as you can see on the slide. We have the different business lines of the investment banking, you have the market activity, the financing, global transaction banking, security services, private banking and asset management and all the support functions that we call the IT department, the technology and the support functions that are called the other support functions that are in the banking called the back offices were the scope of this transformation. So we were talking about a transformation initially on IT, 7,000 people, we were talking about 7,000 people for the IT departments. First of all we need to recall why we went to this transformation because we did not go toward this long journey just because the other did, we thought that we had four main drivers. First of all we thought that it was a good way to enhance the value delivered to the business. Second we think that this model, the agile scale model is more effective to deliver either facing business or inside the IT department itself. Third it's important to have in mind that today we are in a competitive environment and we compete with the companies that are not banks to attract the new talents and today you need to have a model which is interested for the new talent to get new donors in the bank, top level new donors and of course we think that this model is a fit for purpose for innovation which is of course very important and more and more important today. If we take a step back we can go back to the agile manifesto just to recall on what we have based our target operating model. Here are the four value drivers of the agile, I think most of you know them. What we have done internally before to design the target operating model, we said okay how do we translate these values into things that will help us draft our operating model. So we've said first of all we want a business alignment of the super function and in particular on the IT to the business. Second we want all the decision to be valued driven which is something which is not obvious in the banking company. Of course we want to favor decentralized decision-making process and Société Générale has had an history of quite cascaded decision-making process. We want and we need a collective commitment and to do so we need 100% transparency of the activity of the IT and the support functions and of course we will work we will put everyone in iterative cycles which is the the basic of the agility. These are the following the principles we followed to draft our operating model. If we look at the journey we followed we did not start in 2017. Agility at Société Générale started we started by Dolin at the beginning of 2011 we started to have some project in agile. On IT departments on the operation side they continued to follow the lean management principles. On the IT we started in 2011 by this project in agile. We launched a very ambitious program in 2014 that we called a continuous delivery program to enable the platform to put in production the deliveries that we had that were more and more agile and more and more rapid and we've decided to go for an agile transformation in 2017. Then we started this transformation it's three years back and after one year one year and a half we switched to an organizational agility this is what I will present you today because agile at scale alone within the IT environment does not suffice. We have to embed that in a decision-making process which is compatible with agility and this is what we call organizational agility. So as you see the agile at scale program at Société Générale Investment Monkey was more a bottom-up program than a top-down program. It came from the IT then it has impacted all the support functions and through the organizational agility it is now impacting the whole chain of the activities. Okay so what is it about? It's about culture and mindset. It's about organization and governance and it's about methods and tooling. First of all we had to change the mindset of people around what is IT developments. We had to switch from a client-supplier-wish relationship to shared accountability mechanisms. We had to regroup two worlds that were completely independent the world of the project and the world of the production to have a full ownership by the business of a service which encompasses everything production and of course new investments and we had to switch to a project view or long term planning to iterative objectives and to a mechanism much more much more iterative. Then we had to adapt the organization itself to welcome an agile way of working. First of all we had to change what we call the GBSU the support unit governance so as to enable a delegation at every level of the organization. I will talk about it just after a while. Then we had to switch our way to steer activities. We are we are switching it's not yet finalized we are well advanced it's not yet finalized. We switch to a no-care approach. We want people to define properly and disclose their objectives rather than to indotify the outputs that they want. Then we had to change entirely the way we manage the demands to ensure that the BUN issue and support unit initiatives are prioritized and steered according to their value and their contribution to the strategy of course. And last element this can work at the condition that we the the resources are not resources are not a mechanism for adjustments. I have a new project I will adopt new resources. If you do that it does not work you go back to a project approach where you think that when you can pay you can have something which is of course not the reality on the ground. So we've switched to a capacity management approach and now we define the capacity at the beginning of the year and within this fixed capacity the business stakeholders they have to choose what they want they want to do. To do so we have to adapt entirely our tooling suites so as to have tooling to manage our OKR from the top of the investment banking because the OKR are impacting the business from the top of the investment banking to the tribes. We had to change our portfolio management tool. We had to extend and to reshuffle the way we were using the execution tool which is Gira in our context and we had to implement a tool which is giving a full transparency of on our costs which is called Apsio in our context. This is the all the environment of the of the transformation. In this context we what did we do? We first aligned the IT organization and the support function also IT and operations with the business value chains. We moved from a silo organization between tech and ops to an industrial digital service platform where you have the service platform serving the businesses that I mentioned just before. So you will find in the gray box you find the different activities the different support functions and these support functions are of course completely aligned with the business functions. We speeded a little bit on this one. We've put the client at the heart of our governance model and we we have we've we've nominated many POs from the business to help us to drive our activity. I will not spend time on this one because I want you to understand not this one but the following. If I go back to the governance what we did is what we call Russian Dole approach. This Russian Dole approach is a mechanism whereby the objectives are set at the IS level. This is what you see here. The GBSU support functions then you have the support unit then you have the tribe then you have the team. Each of the governance level they have their own OKR. They have what we call the emblematic KPIs which are the elements to follow the production, the quality of what is developed etc etc and they follow line per line a few what we call a few major initiatives. We could talk about APICS if we would talk in Nigel Warding but it was difficult to have this understood within the company by seven thousand people so we prefer to use the term initiative but take that as an APIC. At their level at the level of the GBSU support unit they only follow a few major initiatives then at the support unit major initiative as well and at tribe level they have a few major initiatives and this is what is the most important. They are delegations to manage a big part of their budget which is delivered through delegated initiatives and then of course at team level they manage their team backlog. So this cascading mechanism enables the delegation that I've talked about just before. So once we've done that we have the different layers. We have the cascading and delegation and how do we operate operationally speaking. We went for a model that we called at the beginning a spotty safe model. It's a mix of Spotify. We've redesigned all the teams in tribes, tribes made of roughly 100 people and made of several we don't call them squads we call them feature teams as you can see. So we went for a Spotify model and when we have a transversal big project we apply safe mechanisms. So first of all let's stop at the organization in terms of operating model. So with 7000 people we have roughly 70 tribes. It's a little bit less but roughly 70 tribes. All these tribes are split into feature teams made of seven to nine people. They are all aligned with what we call a product and they are referring to a product owner. Really an element which is key in our in our deployment is the fact that we have insisted to have the product owner from the business. There is no professional product owner in our model. So it's not Spotify by the book. Our decision was to say if we want a product owner to cover all aspects of what a feature team is supposed to deliver from new projects to the production, to the support etc etc they have to be in front of the business so they have to belong to the business. So in our model the product owner spends 20 to 25 percent of his time with the tribe and the rest of his time is dedicated to his real work. So first of all to work the business we have the product owner and second to steer the activity of a tribe it's done via a concept that we've taken out from from SAFE which is the concept of PMT, a product management team because we notice that in our environment in the banking environment we were not able to have a product owner leading a tribe of 100 people. We need different skills etc it's not possible to have only one person. So we put a few people together from the front office some trader responsible of desk people like that people from the back offices etc we put them together and we organize their work so that together with the tribe manager they can steer the priorities of the tribe. So the tribe is a Spotify tribe with vertical feature teams. Last element I want you to keep in mind in our model we don't have vertical management anymore of course we have the tribe manager who's the manager of the tribe but we have switched the management horizontally so it's the chapters that you have here that are managers of the people in the tribes and this is very important because when you do that you enable the feature team to be really autonomous and you have no intermediary between the business and the guys in the feature team. We need to speed up a little bit sorry I'm a little late so you have the key roles here but I will not have time to go through these key roles I have mentioned the two main from the business the product management team which is from the business and the PO and of course in terms of management the prime manager and the chapter manager just one word maybe to say that how do we manage the architecture consistency we have a league an architecture league which is organized which is a upper to several tribes and that's the same for the production aspects and this is this enables to manage all the priorities all the developments that are coming to a tribe directly that are flowing to a tribe this is how do we synchronize the activity we have a demand an initiative coming and if it can go to one feature team we call that the single feature team model so it's purely Spotify you have something coming to a product you have a product owner deciding the privatization etc it goes into the feature team but it does not work if you need to if you have initiatives that are cross tribes or that are complicated to deliver and in this case we have two models on the right hand side we can put in place when we have a lot of feature teams we put in place safe trains to coordinate the activity of all the feature teams working for given initiatives of course these feature teams they belong to a given tribe but they put together their forces to deliver something in the context of a safe train and of course you can have in all the intermediate level that you can imagine because between one feature team and a train off we have trains up to a 15 16 18 feature teams in the middle you can have initiative where you need a few feature teams to be coordinated in in this case we do what we call the light sync which is a kind of a scrum of scrum or sing or sing like that sorry to speed up because we are almost done with this model so spotty safe model applied to it organizational agility applied to the whole organization and to have all the processes compatible with an agenda scale model we found very excellent objectives in terms of business and it satisfaction in terms of time to market even if the time to market is always difficult to assess we have a very good time to market and where the dramatic increase of the time to market and we had a lot of efficiency gains as well because this model for sure reduces the number of intermediate layer the pyramidal aspect of the organization etc last the feedbacks and the lessons that you would like to share with you we are quite happy with the transformation that we've made we are already at 80 percent of the tribes are transformed today the whole organization has been transformed we think we've managed to do that around on more than seven thousand people because we had a structured program with a holistic approach from the beginning we did not launch initiatives of agility even if before to launch the program we had two of them but once we've decided to go we had a structured program then we've defined a set of clear objective of indicators of the benefits of the agility we have more than 17 indicators that are followed to see the progress of the of our organization and we started bottom up as I shown you by DIT but with the organizational agility we connected with the top-down approach so we think that there is does not matter if it's bottom-up or top-down approach we need what is important is to embark the business from the start we we did not do a top-down transformation but we embarked the business with the POS and the PMTs from the start the other element is that we don't have a one single model we have adapted the different model to build our own target operating model with people from a Société Générale working on the different patterns etc we have as I've shown you very quickly transform all the steering processes this is what we call the organizational agility all the steering process and it's a big part of the transformation and of course we this had an impact a huge impact on the people so we build a very important HR stream to accompany the deep managerial and cultural change in the investment banking I think I'm a little bit late sorry for that that's great Etienne thank you that that's fine I'm going to assume that Peter will take over and we are doing the the Q&A for this in a panel session after Peter's presentation so don't go away Etienne we have questions for you on the panel thank you thank you over to you Peter thanks everyone for all the you know financial services is a financial services firm in the US about you know nine trillion US dollars of assets on the management about 45 000 associates and the personal investing business unit really is the business unit that deals with the B2C part of the organization what I'm going to do is actually click down a little bit on on how we adapt it you know agile architecture as a part of our transformation so what's quite fascinating is and probably not unusual is a lot of the elements that Etienne spoke to very similar to our own transformational journey interestingly enough and I wasn't aware of this before we started actually in 2017 but that was as a result of a number of previous incremental attempts where we didn't actually do a holistic mashup of the business and technology we had elements like capability teams you know we were doing agile in technology but there wasn't the real comprehensive mashup between the business and technology along all of the the roles and responsibilities so you know we have come into 2017 with that learning and then we made a decision in about August of 2017 that we couldn't be half agile as a business unit so the personal investing business unit consists of about 19 000 associates 14 000 of those associates are in regional centers call centers and branches 5000 are what we call home office so this transformation is really in home office and that consisted of about 2500 associates in what we might call core business functions and then another 2500 in technology and so when I say mashup it was really taking 5000 people and fully integrating them into again interestingly enough the Spotify model and we made a decision actually that we would flash cut the organization and we feel we felt we had enough learnings so we you know we notified the organization in in August of 2017 educated the organization in September of 2017 that we were going to do this and what it meant and then in October November and December of 2017 we literally in three ways flash cut the entire organization into a set of domains domains simply align to the elements of our strategy tribes squads and then as Etienne mentioned before we likewise have chapters that are orthogonal to the tribe and squad structure so for example architecture is a chapter I'm an architecture chapter area leader I'm sitting below me or architecture chapter leaders and they are get aligned specifically with domains tribes and squads and that's where they live in those cross functional teams rationale for the transformation you heard a bit of that from Etienne very similar delivering faster value to our customers and really energizing and engaging associates much more holistically empowering our dedicated teams and then and then for us and you'll see this in subsequent slide we really recognize that there are some fundamental cultural changes we wanted to make in the organization as it's related to delivering customer value faster and that was related to a model of leadership that was much more empowering and multiplying and then of course you know to stimulate innovation I would say that you know because we had some prior experiences with this and I'm sure you know others have too I heard Brian mentioned that a little bit and probably Etienne the fundamental chasm we were trying to cross was the you know the semantic gap between technologies use of agile and the business seeing agile as a primary contributor to delivering value delivering value to customers very quickly and then alignment between IT investment and overall business strategy and so for us the whole issue of mindset was very very fundamental to what we were we were getting after self-directing teams absolutely it's part of this whole notion of empowering we wanted deeper collaboration that wasn't simply ad hoc and episodic but actually was baked into BAU you know business as usual standard modus operandi you know Brian focused a lot on the value stream and we wanted that those combined teams to really have clarity regarding the specific customer outcomes that were associated with the business strategy and then we wanted to integrate to a continuous learning improvement model into the organization so apart from you know instantiation of the Spotify model the associated tooling you know we we likewise use OKPR model OKR model with you know what we call OKPI's so we can measure in a very quantitative manner what's actually happening and we use what was formerly called agile craft it's now called JIRA line to deal with the holistic structure of initiative ethics etc and more importantly we like JIRA line because it links directly into JIRA so that there can be a very direct click down into the actual work being done by squads spring stories etc etc and there's no need to actually manually look at that but the other thing we've integrated is we've taken 20% of every week so we call Tuesday's learning days and you know all members of the organization are actually allowed to use that day either collaboratively or otherwise for specific areas of continuous learning so fundamental changes that we wanted to make in the culture this didn't exist before and then you know as I mentioned before for us really driving some leadership principles with holistic accountability right I think you know Etienne mentioned this also but we wanted to be very explicit about those principles and those principles actually are broad based fidelity financial services leadership principles but they're also baked in of course to personal investing so what happened after the personal investing business unit began this transformational journey Abby Johnson who is the chairperson of the company about eight or nine months and she made the decision that all of fidelity all of the other business units would would go into this this transformation this type of transformation on the right side of the slide you can see for us part of what we did in that flash cut model I mentioned in three months is we actually had everybody reapply for their jobs and so you went through a 360 review you went through face-to-face interview and then there was your profile regarding what you've contributed previously and what we were really looking for were really individuals who you know demonstrated multiplying behaviors as you see here and we were quite frankly trying to you know minimize I would say diminishes quite frankly right because we felt that this was really critical to actually operationalizing the transformation on the ground very similar you know Spotify model tribe squads chapters we do have center of excellence and those for us are constructs that are intended to look ahead in areas that we feel are complementary to our overall strategy and we what we use those those center of excellence is to accelerate the overall validation strategy standards that will subsequently then be utilized within the domains tribes and squads so for example within my architecture chapter area I actually have an architecture center of excellence their their current focus has been over the last 12 months we utilize amazon web services and they were front running for us along with an enterprise you know cloud computing organization our instantiation of azure because we want today a multi-cloud you know multi-cloud strategy chapters fundamentally you know there are squad members with similar expertise ie architects and they drive consistency and what good looks like into those chapters I will say that within our instantiation of the Spotify model we actually use squad leaders so the hierarchy is domain tribes squad squad leaders and then chapters and they provide the orthogonal resource so that a squad leader actually functions as the individual who is accountable for leveraging all of the resources within that squad to deliver the appropriate feature function that would be you know the component of what the tribe was was trying to deliver and of course what the domain is delivering now as part of our evolution we're seeing more and more that those squad leaders actually need to be either complemented with or they need competencies of product management competencies and that's that's part of an evolution that we're currently in the midst of sevens of excellence I think I've talked a bit about that so I'm not going to say much more and then you know chapter leaders they basically are responsible for the you know literally the care feeding and career development of members within that chapter and you know from an architecture perspective I hear some of the things that they're specifically you know responsible for in terms of the technical role of the architect their design skills their programming skills communication skills etc one of the things we found was that once we had actually instantiated this model we needed to make sure that there was clarity of vocabulary and semantics even though many of our colleagues who primarily were you know focused on on the business had had contact with architecture we needed now to be very very very clear about roles responsibility and meaning and so I'm a really big fan of the you know the two Peters the Eppels and Peter Cripps and they've got a very nice model in their book that speaks about what what does an architect actually do what is actually architecting and what is architecture and so we use this this particular model so that domain leaders tribe leaders squad leaders and chapter members have a very consistent vocabulary and understanding of the role responsibilities and activities of the architects and the architecture chapter members within you know within the constructs we also you know again go back to the notion of being very clear about collaborative behavior leadership behavior mindset we've articulated very you know very clearly the engagement principles upon which we along which we practice architecture right and again you know Brian in his first presentation on business architecture mentioned a number of these things right staying in the business context focusing on outcomes layering the conversation we you know we use the C4 model for simplifying architectural artifacts so that all of the constituent stakeholders in the collaboration you understand what's what's going on and then and then other elements of how we actually practice architecture but our fundamental learning is that we would like to infuse architectural thinking into all roles within the model clearly not everyone is an architect but we want architectural thinking infused because we think it's it's very fundamental to you know how one effectively leverages you know the model I think that that Brian showed right in terms of the business model the business strategy the associate business model right the business architecture and we view architecture as a necessary complement to that business architecture so we want architectural thinking infused in in all of the associates within the collaboration and then you know to go even further we get very explicit about what we mean by end to end architectural solution and you know great presentation first presentation today for Brian around business architecture we are particularly because of our key objectives around the evolution you know for financial services right which is clearly being driven by what we call the digital natives digital giants digital dragons there is the recognition that the experience that they deliver um really provides customers with a coherent set of journeys and those journeys are usually very strongly correlated across the various tasks within the journey vis-a-vis the customer's desired outcome so you know we want it to be really really explicit about that and so what you see in this slide is how we've is how we've articulated um we're three years in I think you know a lot of the okpi's or okr's have proven that our initial aspirations and objectives are being realized and so we are now in a phase where we are evolving our overall architectural strategy so for example we made a deliberate decision in the early days of the strategy not to perturb a number of the horizontal components right and so those components would be things like existing platforms or aggregations of capabilities that behaved like platforms and or underlying data architecture we have now been pushing along in those dimensions specifically with respect to data as we I would say drive very hard now for what we feel is the fundamental infrastructure pivot of the underlying architecture I mean I have a hypothesis that says everything below the experience layer will commoditize and the rationale for that is is really quite simple um you know I think that the CSP is the cloud service providers are providing managed services and fundamental technology capabilities are very very rapid rate and therefore there's the ability to leverage all of that to you know build architectures that in many cases you know we have to build very complex systems to actualize and so we recognize that a truly digital experience requires a fundamental data strategy right and Andres and Horowitz have got a very nice paper on emerging architectures for data infrastructure for modern-day infrastructure and they articulate three three particular models right they call one a multimodal model an analytical and ML model and an operational model and the multimodal model is a convergence of that analytic model and the operational model and so you know we are pushing very aggressively in that direction and and you know versus and the way we thought about data architectures before we think that there is a much more holistic perspective around business and technology you know clearly security cyber security legal risk costs and governments that need to be a part of that overall strategy and then manifested in the actual architecture itself as policies automated policies and not manual policies and procedures and so we've got a you know complementary data governance construct that's associated with that part of you know our transformation with all of the elements that you would would expect around accountability quality life cycle management etc etc and this slide is just really a model of how we've organized to to to actually you know accomplish those objectives you'll notice that when John read the introduction he mentioned this tag group and that's a grouping of all of the chief architect CTOs and firm and that has a working group called the tag data council by the way that construct is we do not have an enterprise architecture organization the firm previously had one our you know we operate in a fully federated IT model and what that means is that all CIOs report directly to the presidents of business units we do not have an enterprise CIO we have an enterprise CTO and they're dotted line to that individual and then we use the this tag construct to create coherence across all of the architectural activities going going on in the various business units and the rationale for that is we wanted much more control and prioritization driven out of the business units and no out of the center of the organization and then the final piece I think this is my second to last slide is that we we've now you know one of the most I think perturbing things to me is if you if you get into a conversation about platforms you can spend close to a year trying to define what is a platform and we would know different with respect to that but we recognize that you know for us quite frankly it's an aggregation of logical capabilities and the logic around the capabilities are what's the intended use of those capabilities and because of the kinds of managed services that are available now in cloud we want to we view this as a very critical construct in our architecture and so we wanted to be really really highly opinionated about this so that you know there wasn't a lot of swirl so this is now a big push in terms of our evolution going from really you know undefined and ambiguous to really being very clearly defined highly aligned capabilities very very clear product management around those platforms and then you know holistic platforms enabling end-to-end transformation with very tight alignment and clarity around their contribution within a value stream this is a generic model actually came from McKinsey paper that we use when we think of our platform ecosystem and then the connection to architecture is the following it's actually the last bullet on the left lower left there is you know once you get to this you know notion of platforms and and and you know hopefully one is addressing the issue of duplicative capabilities right and then the issue really then becomes what we call this city planning function which is we've extended our architectural accountability to now look across domains recall i'm talking about a single business unit and so the business strategy for that business unit personal investing is actually quite coherent and so we want the you know corresponding architectural strategy and its output to be coherent across the domains tribes and squads and so we've extended the architectural practice to actually include this notion of city planning so a set of my architecture chapter leaders with some tribe leaders now form this city planning function and their role is to make sure to ensure that we're thinking holistically across domains across tribes about our platform ecosystem and the associated capability and that's a that is actually an in-flight part of our evolution even as we speak that's it