Does an industry like investment banking, with its myriad controls and regulations, need more governance? Can agile be a good fit in such an environment?
When I was invited to talk about governance and the prevailing myth that governance is anti-agile, the first thing I thought about was the title. Hence, the title "Agile Governance is Not an Oxymoron." Throughout this course, I will illustrate how they can go hand-in-hand. Take me, for instance. A long time ago, when I had a lot more hair and was much younger, when I was put into the corporate machinery, I started to think in a waterfall way, constrained by silos, throwing the ball over to production support or the business. That was my day-to-day existence, and I would always think, "An idle mind is the devil's workshop." But with the onset of our agile transformation, it metamorphosized my thought process and approach. Now, I can proudly claim that an idle mind is an agile workshop. I will illustrate how this reflects in our journey.
On a side note, as you go along the journey, there is a correlation, though I only have one data point to prove it: wisdom is inversely proportional to the hair on your head. I will open this to your thoughts.
Societe Generale, as you have heard, is a 150-year-old bank. It is an investment bank and a universal bank, with three areas of operations: retail, corporate investment banking, and international and global investment banking. We have 150,000 associates, and we are in 67 countries. We aim to be the trusted partner for all our clients. We transform economies and cultures; that is the mission of Societe Generale. The four key things that resonate with all our associates are commitment, responsibility, innovation, and team spirit. Those are the core values we believe in.
This is a slide that most of you may have seen with the picture from Henrik Kniberg. Business agility or agile governance itself is a fine balancing act. There is a great chance that you can fall into the chaos of letting go, like the Wild West. On the other hand, if you overdo it, there is also a greater chance that you will micromanage, and it will be seen as bureaucracy. So, I would say caution and question ahead.
In our strategic plan, agility is one of the key pillars, in addition to an open banking architecture and using the cloud. We aim to be the digital bank of the future, with agile as a cornerstone. Our journey in the agile landscape started about seven years ago. In 2011, we started moving from lean and waterfall to more agile practices, and on the journey, we moved towards continuous delivery and continuous integration. 2017 presented us with an opportunity with a reorg for IT to be more closely aligned with the businesses, structured along the business lines. That is when we started the agile-at-scale journey to ensure that we deliver value to our businesses in a much more collocated and co-constructive way. By 2020, we aim to complete this journey, which will transform close to 8,000 IT associates and more than a thousand business associates.
Why agile? To increase value to the business, to improve efficiency and profitability, and to attract and retain talent. We aim to be the go-to place for agility in the investment banking space and create a culture of innovation through co-construction. What inspired us was the much-aligned (or maligned) Spotify model. We took inspiration from the SAFe framework, and we thought we would call it "Spotty Safe," but it did not sound right. So, we looked inward to our own needs, and it is definitely the Societe Generale way of agile at scale that we embarked upon.
In any transformation, you need to design the target operating model. This is a simplified version of our target operating model. The terms you will recognize: feature teams form the units at the lowest level, which group into tribes. You form chapters and horizontal management across the teams. You have leagues, which are either your business analyst league, your UX/UI league, or your production support league. Across tribes and IT units, you have guilds, which are more voluntary sharing of best practices and synergies. Every team would aspire to reach this target operating model. In the past, they were mostly IT application-centric, and now they become more business value chain-centric. Every team would be required to go through this journey and reach this target operating model. As a reminder, unlike some other banks that have embarked on this journey, the transformation is only complete when there is a good degree of maturity on both the continuous delivery practices and agile-at-scale practices. It is not complete when the team is formed; it is complete after the team is formed, and the journey continues.
What is the impact of agile at scale? There is a great degree of change that we undergo. There is an operating model change where we need to showcase the splitting of responsibilities between development and the business. We are also changing how our large programs are steered. We move to a capacity-based model where product owners have full control over the capacity of the IT teams. There are role changes, and HR is one area where we have a great degree of impact. My colleague Sumanth will talk about that tomorrow, so look forward to his speech. The way we do finance, I just talked about capacity-based modeling management. There is definitely a cultural and mindset change, and all of this is enabled by a robust change management structure and our coaches.
Talking about program governance, it is crucial that we started with a well-structured program covering all aspects of governance. The target operating model design that you just saw is the foundation. The coaches, the agile Center, and the agile program itself helped co-create and construct this operating model, which is then implemented by a team that tracks how this operating model is being implemented on the ground. There are periodic assessments, coaching, and enablement happening. The important thing to remember is that it is a live model; it is not set in stone. We do correct our course. For example, there were about 60 practices prescribed at the beginning of the model, and then we listened to feedback and pared it down to about 30 crucial ones, so it is light on the people implementing it. Again, to ensure that we do not fall into bureaucracy and micromanagement, this needs to evolve to the needs of the organization. There is a different stream called the HR and culture stream, where you talk about upscaling, role transformations, career planning, and learning paths; you will hear about all of that from Sumanth's speech tomorrow. Change management and communication, as the name suggests, you have to ensure that you take people along the journey; you have to give them the "why" upfront.
There are definitely things that we should be doing better, to admit transparently. There is going to be an impact on your processes and tools. In the past, maybe you were used to running large-scale programs, but now there are going to be smaller and tightly controlled budgets. The tools that track all of these need to change. We plan to have light sync tools across the agile release train. There is going to be a brand-new capacity-based management tool. The erstwhile time-tracking systems will evolve to cater to the agile-at-scale model. Lastly, there is a global coordination stream across the program, which ensures that there is the same flavor of agile at scale, no matter where you go, across businesses and geographies, people talk the same language; they have the same set of practices. That is something that will resonate well across the globe.
Like I mentioned before, every team has to undergo the transformation, and there are three steps for every tribe and feature team to come into the journey. They start with what is known as the framing phase of the transformation. You come out with your business vision, how you will align to the business, and the value you will generate. You work with the coach and form your target state, what practices you will achieve at what stage of the journey. Once it has been approved, you move on to the implementation phase, and there is a set of practices that you continuously improve and mature upon. All along, you get help from the agile coach, both craftsmanship and flow coaches, to help on the journey. Lastly, once you present your MVP, or Minimum Viable Product, to the program, there is an assessment. You do not have to be perfect on all the practices, but you need to show a roadmap towards how you are going to reach the target state of greater maturity along both axes: on the x-axis, the continuous delivery practices, the technical track, and on the y-axis, the business alignment. If you can imagine a journey plotting upwards, that is what this is depicting. There are three steps to success for every team, and at this point, we are 50% along the way.
The impact on the business cannot be ignored. The business is also becoming agile. An illustrative example is a product owner who has a major role in how the transformation is happening. They are the full owners of the backlog, and they share the vision and objectives with the IT teams. This is a key transformation, and it is definitely giving us good results. Also, as I mentioned, there are brand-new roles that we create, brand-new titles. There is an upscaling program that is going to transform people from regular developers to full-stack developers, people who move from production support into the feature teams and can become either analysts or developers. All that integration is happening. There is a leadership mindset change as well. There is an Up Mind program that we created with coaches; it is going to cover mostly everybody in the organization. We are also embarking on this management read-out tour, which Sandeep, one of our coaches, is going to help us with.
Finally, this is what our dashboard looks like, and for secrecy, it is a little hazy, but I will walk you through it. We track deployment, the progress that the entire organization is embarking upon. We track the number of feature teams and the percentage of staff that is transforming. We track the satisfaction of the business, the product owner, and the product management team, but we also track the satisfaction of the IT teams that are on the journey. There is something called visibility, which means how well the business anticipates and how visible the backlog is to the business. At the organization level, the value that we gain from the transformation is also around the span of control and the role transformation. One simple measure is: do we go to the market to hire those skills, or do we internally transform and upscale them? Production quality and stability are important. We need to demonstrate that there is good improvement in stability and that the number of defects is being reduced. Also, the technical debt: there are measures to measure the technical debt and the efficient use of the tools in what is known as the CD factory and the pipeline. Last but not least is the value that we demonstrate to the business on time to market. This is anywhere between two weeks to four weeks for most of the teams. Predictability means how well the feature team delivers what has been committed. One of the cornerstones is the open banking architecture and the move towards more microservices and APIs. These are business APIs that we attract, and those are the ones that create the maximum value and impact. So, the number of APIs produced, and more importantly, the number of APIs reused to create brand-new products or services. All in all, there is governance at all levels. We have ways to pull the data from feature team levels to chapter levels to tribe levels. The key is to ensure that we do not overburden the teams. The teams are happy practicing their backlog prioritizations and retrospectives with the product owners, but behind the scenes, a lot of data is being gathered. We do not overburden the teams with filling out forms or spreadsheets. Therein lies the caution: that in spite of this looking quite heavy, you need to make sure that it is not overburdening the teams and give them the autonomy that they need.
To sum it up, we have covered all the angles on the agile-at-scale program. There is a structured program with lots of objectives and indicators. It is an adapting live model, which adapts to the needs of the organization. There is the transversality of the shared services. It reinforces a deep cultural mindset change, and lastly, it is a global transformation using the cloud and APIs. We all have a role to play, both IT leaders and business leaders. Our goals need to move from outputs to customer delight. We need to ensure that our managers become enablers, not controllers. We have to focus on sustainability as opposed to cost-cutting. Lastly, the entire organization needs to evolve from a hierarchical organization to a collaborative one. In summary, there is scaling ahead, but caution: it is not for everybody. Do not try to fit the model or transformation into teams that do not need to transform. Fail fast, adapt, and evolve. There was a case where we felt that a transformation was not going in the right direction, so we decided to go back to the table and restart it. Governance is the key to agility. It is not an oxymoron in the agile space. Lastly, may the agile force be with you, and I think this goes very well with our brand-new slogan: "The future is you." Thank you so much. Thank you, Bala.