journey to #SLSP WAY OF WORK (6/?) - Transformation
All previous activities gradually filled our landscape and prepared us for a significant leap forward - the organisation-wide transformation of our way of work. We eliminated the vast majority of pain points we had in IT-business relations. I am proud to say we (as IT) were able to fulfil our commitments for delivery. But (there is always a BUT) we felt the organisation needs to change to behave more like an IT company with a banking licence. Our BoD nominated seven people to define the new way of work, and our CEO Peter Krutil created the statement for us:
Change your way of work in a way to ensure SLSP is a technology company with a banking licence, not afraid to use common sense, and empowers employees as problem solvers, not machine parts. At the same time, we praise our employees and customers as our most significant value, and we demonstrate it daily.
The team was (in alphabetical order): Juraj Barta , Norbert Hovan?ák , Branislav Jarábek , Jozef Laurincik MBA , Slavek Mynar , Zuzana Poláková , myself and Michal Vanov?an . We all did perceive that change in our organisation is inevitable. Inspiration came from success stories about agile transformations from companies that have already undergone this kind of transformation, like Lloyds, Nordea, or RBS. We talked about google sprints and other possible ways of working more agilely. And we often felt like we needed to shake the organisation, but at the same time, we were afraid of changing too much at once. Finally, we created a list of things we would like to change:
We quickly understood that agile principles are the way forward (what a surprise :D ). But the devil lies in the details, and we tried to cover major areas and, at the same time, to be as reasonable as possible. Why? We could draw agile as the only way of work for the whole bank, but would it make sense, and would it bring something positive to all units? For example, daily stand-ups on the call centre? Sprints in the back office? Product owner for the core-banking system?
We admitted that our design would be flawed, however hard we tried. We want to make the change, but we expect the new organisational model will not be final; it will evolve.
New principles
We defined principles for the new organisation:
We drew a new org chart and proposed new agile units = LABS. LAB has a Product owner, scrum master and IT Lead, business people, analysts, developers and testers. The original IT teams were split into those relevant to Labs and the others. The key was simple - if the team is providing 'services' to a single business unit changed to Lab, then IT guys are part of the Lab - typically George or loans-related teams. If the team provides services to more business units, it becomes part of the new 'Shared IT Services' unit - like the core banking team, integration team or team managing a common development platform. Rest was moved into the business Labs.
One of the biggest challenges for me was explaining to IT guys the need for their move into labs; I am sure I could have done it better. I received numerous questions about losing influence in the organisation because I would lose management control over many people. But it was the right thing to do then, and it is still the right thing to do now.
Business understands IT
I have tried to make business people understand what we are in IT doing for quite a long time, with different levels of success. Few guys could understand it's more complex than just writing a few lines of code; others did not absorb the full complexity of balancing CTB/RTB, development, fixing, improving, refactoring and differences in skillsets needed for different activities.
Moving direct IT responsibilities into the Labs forced POs to cover it end to end quickly. Somebody could expect life to be easier because product owners can decide what developers will work on every day or week. But IT reality hit them hard - estimations, planning, coordination with different teams, actual capacities for implementing change vs efforts needed for bug fixing of production incidents - well, it took much work for them to understand and somehow manage this level of complexity while focusing on business benefits. They received as much support as possible, Labs had a skilled IT manager dedicated to helping them adopt, and although it was not perfect, it worked. We prepared various 'dry runs' - simulations of real-life scenarios new teams will be facing, and this, with intensive communication with IT managers, helped them with the transition.
领英推荐
Challenges
Guess what happened one week after Labs reorganisation was approved on the BoD level? Covid hit us, and we were forced to work from home. Imagine designing the new Way of work based on collocation, with newly created teams sitting in different places, with very limited ways of cooperation (as MS Teams were not in place yet). But a crisis is the best way to improve really fast, and in this case, Covid was really THE driver for the digital transformation of our communication. We as all other companies surviving the Covid lockdowns are now able to work remotely without affecting performance too much, although collocation is the preffered way of work not only for Labs
How did people react? Some people were unhappy with moving into Labs; some left company and others moved back to the 'old' way of working in the Shared IT Services. Big challenge is the team of scrum masters. Typical scrum master coming from company with single product does not understand the complexity of a bank and it results in a very high turnover.
How to get more IT people by lowering count of IT people
In traditional organisation it's quite difficult to explain that in IT at the size of 200 people you are not able to find 5 more people to implement THE ONE SINGLE change as fast as possible. After we split all IT guys with relevant business knowledge into Labs (and thus lowered IT headcount) we made it clear to all Product owners no more people are available. The only way to increase capacity (outside of bodyshopping) can be achieved by reshuffling existing headcount in Labs. And POs got it and started to reshuffle business positions into IT, which lead to increase of total IT people count on the bank level at the cost of business people.
MBR & QBR
One of the many challenges we are facing is coordination and transparent communication of activities teams are working on. Creation of standalone teams with independent backlogs leads to need to inform other teams about planned impacts to their backlogs. We introduced 2 major meetings - Monthly business review for alignment of basic issues and typically capacities, and Quarterly business review to inform wider group of people about achievements and new topics teams are working on
Summary
Transformation is such a complex story it makes it very difficult to explain it in an article like this. I hope at least basic elements are clear.
Overall (from my perspective) transformation makes sense and it helped us in #SLSP to improve engagement of employees. Pressure in organisation coming from unrealistic expectations is much lower. New way of work requires a huge amount of coordination and alignment and brings high level of transparency
Next part will be about our development platform and our approach to upgrade the branch frontend while driving at full speed
Previous article from this series:
Senior Program Manager & BA Chapter Lead (Erste Digital GmbH) | Speaker, Conference Moderator/Chairman, Agile Coach & Executive Consultant for Project/Program/Change Management/Digital/Architecture (Freelance/Contract)
1 年Excellent article, thanks for sharing the insights!