This post is repost from the past and is surprisingly in English, I will also later on post this post in Swedish. In my former life, sorry, employment, I worked at a large bank where I initiated and oversaw an agile transformation for 1.5 years. It is worth noting that my experiences are not only about working with agile, but more about change in general.

First some background, Handelsbanken was founded in 1871 and have branches in Scandinavia, Netherlands, and UK. It is one of the most stable banks in the world, and have had great financial and customer satisfaction metrics over the last twenty years. It has over 16 000 employees, and I was part of the IT organization where there were approx. 1500–1600 employees, depending on how you count.

The company had its own unique project model which was rooted hard in the organization with roles and process. I believe the model was established about 20 years ago. The company had roughly 80–120 project running in parallel. The organization was a classic organization with two silos, IT on one side and business in the other. The business side was clear that IT was too slow and could not adapt to change quick enough, and IT believed that the business side could not decide what to do or was changing their mind too fast.

When a project was launched, the project picked resources from different competence functions like development, test, design and so on. There was a start and stop mentality where people were shuffled around and was part of many projects at the same time. It was hard to get a feeling where we were going, as the strategy was either too abstract or completely lacking.

What I described above is often the case in many organizations and is not unique for this particular bank. Would you say that you could relate to this at your organization?

When I first started my employment at the bank, one of my assignments was to empower my colleagues to create product and services that were based on our customer needs. To achieve this, I knew that we had to be nimble and responsive in order to quickly sense and respond to our customers and the market. I knew that we needed to work differently, but probably the most important aspect was that we needed a new culture and mindset.

So, what did I learn through this journey?

• Make use of current company values and principles (If you see they fit)
• Active support of the top management that helps drive a unified future vision
• Create a strong diverse team who can work, drive and support the change
• Think big but start small and work iterative
• To change the living system, the organization, you will need to involve every function in the company.
• Make sure you involve external resources to get a second opinion. But the change needs to be done by the employees. You cannot outsource the change to others
• Educate and train people for the future. This includes both employees and managers.
• Act as a coach. Listen and communicate as much as you can in every channel and media that is possible
• Be humble and have a human perspective to the change. Change is about humans, and it often takes time to change a behaviour
• Listen to yourself and be careful of your mind and body

Make use of current company values and principles

Where I worked, there was a strong and unique culture already established. What we valued was autonomy, coaching and empowerment leadership style with lots of trust for the colleagues. We often talked and acted on behalf of the customer, a genuine customer-centric organization in many ways. The hierarchy was there, but the line to top management was short. The culture was quite ”Swedish” with lots of common sense and a welcoming atmosphere.

So, when I started at the bank, I quickly realized that the values and principles were very ”agile” from the start. I was really amazed.

Focus on the customer, autonomy, strong product ownership, network, and team based (at the branch offices), trust in the colleagues, small iterative changes and continuous learning, no sales targets or bonuses, no budgeting(!), not too far to the top management, small central function, simple metrics (cost, revenue & customer satisfaction) and follow up on team level.

All these principles and values were created by Jan Wallander, the CEO in the seventies and is documented in the internal manifesto which is still the same (with some changes during the recent years).

1. So my first tip is to make use of the current company culture, values, and principles and try to use them in your favour. The change will go much smoother if you can relate your changes to the core of the company. For example, where I worked we talked a lot about the branches as autonomous units with lots of self-management, this really mapped well to small agile autonomous teams working with digital services.

Make sure top management really wants this and are aligned

If you have read Kotter’s book about change management, Kotter describes three important things;

1. Full support from top management
2. Management is aligned about the vision, goals, and metrics
3. The change needs to be important, a burning platform

When we started our journey, it wasn’t clear to many in the organization why we were doing this. We, who worked most actively with the change and the management, had a full or aligned picture of what we wanted to accomplish. I had full respect for our management to not have the full picture and still be fully aligned, this is complex and there were numerous new things related to the way of work and agile.

You must be able to learn along the way, take small steps, and adjust when it doesn’t work.

Another thing that was hard was that the management had a hard time committing to just this change, everything is important and there is always a fire to put out.

2. My second tip. You really need to be extra sure the management is aligned with the vision and goals. If you don’t have that on paper, I would say that you should back off until you have the right conditions and expectations. We didn’t have this and made the road quite bumpy and hard to communicate.

Create a diverse and strong team that will work with the change

In our case, we created a team called Team Change that actively and proactively worked with the change. The team would support the organization with a new way of working. The team was diverse, and we had resources from finance, project management, agile, development & design and in total we were about 5–8 people.

Some worked full time and some not. Some were employees and some were consultants. The team had the same setup as agile development teams where we tried to work agile, iterative and transparent. One good thing with this way of work was that we did what we asked everyone else to do. To be the change. It was also good that we had a diverse group from the organisation, to change something is much easier if you have people that knows how it works today.

3. My third tip is to create a strong team with different competencies and from different parts of the organisation with a spice of external input. When we started, we didn’t have the full range of competencies that you normally would see in an organization. At first, we didn’t have the competence of HR, business and operations for example. When looking back, I would have involved business and HR much more than we did. They would be a such a key partner in this transformation.

An agile transformation is not something that involves IT, it’s really a transformation that will change the company from the ground up. Early on, I understood this, and I often described our journey as a culture or business transformation that would change the people, culture, values, and way of work for many (even if many did not believe me or understand me).

Think big, start small and learn fast

Chunka Mui wrote the above words, and as with product and innovation, organizational change is the same. I still remember how it all started, we asked our management if we could do just one experiment. A funny anecdote, when we asked for an experiment, one of the managers in the management said ”we don’t do experiments at the bank”. But when I rephrased it that we wanted to try something to learn, it wasn’t a problem. I’ve heard this before, nobody wants to buy a failure.

Our experiment was approved, a small development team with different competencies, all very autonomous with work they could all handle by themselves. The team got financed for a year with only a bullet point list of what needed to be done. No pre studies, no long documented requirements.

We made sure the team received the support needed to work in an agile way and becoming a highly efficient, adaptable and autonomous team. We could quickly see (and learn) what worked well and what we needed to improve.

From this small experiment, the small team expanded in to more and more teams. We had a current project that we reshaped to an agile team. The project was really just a form to handle planning, prioritization and people. We already had these teams up and running, and we only had to add an agile mindset and way of work.

At the same time did we told the organization to start striving to start working more agile. Everyone can try and see what works for them. We tried not to be too descriptive (which some thought was hard). This lead to an organic growth of change and after about a year we had about 20 teams, both component and feature teams.

4. My fourth tip is really to start with something small. Start with a small experiment, and be sure to know what you are testing. Make sure that you can support the team so that you don’t leave them out on the field on their own. This will create a great case that you can show to the rest of the organization. Our first agile team was a real success that we could show what worked, how they worked, how they were located and so on. Show instead of telling. Then use this case to communicate in all forums and channels that you have have in reach.

Everyone has to change, including the management

One of the hardships with a large agile transformation is that everyone needs to be a part of the journey. First you’ll need to get all the organizational functions like finance, project management office, HR, business, operations, QA, business analysis, design, and communication and so on. As I mentioned earlier, this is something that will affect the whole company. I’ve seen the same struggles within many other organizations. It often starts on the IT side of the organization, but then change hits the glass ceiling. HR doesn’t understand that this is about leadership, people, and values. The business doesn’t understand that this about business agility and innovation. We had the same challenges in our organization.

One interesting thing I learned from this was that management and the managers are part of the change. Often managers and leaders make sure others should (must) change. But in our journey I quickly realized that the managers also needed to change their mindset, their way of work and how they related and lead others. This makes it harder, as the common reaction is stress, hardship, anger, and fear as roles change and sometime some people lose mandate and power.

We also learned quickly that this kind of change needed new competence that we didn’t have. We sought help from external agile and transformation competence, who helped us and supported us throughout our journey. We started with making an as-is evaluation of our capacity and organization to see where we were strong and where we had obstacles. It really helped to have a baseline, so we could see where to prioritize our coming work. External help is also vital to get an external perspective on things and can really help add oxygen to the organization. An important part in the communication was that we had to own the change by ourselves, we didn’t want the transformation to stop or, even worse, go back when the consultant left the building. We worked actively to balance working groups in an external and internal perspective and made sure we had an extensive training program in place. A plan for hiring the right competence was made, and we always thought about training the trainer, just so we could establish the change in our governance model.

5. So, my fifth tip is to make sure the whole organization is represented and proactively working with the transformation. From development teams, transformation teams to management. Make sure that you listen and speak to everyone that have questions and need help. Everyone needs to be on onboard for this to succeed.

6. My sixth tip is to make use of external help to get inspiration, a second opinion, new competence and someone who can ask those hard questions and add new oxygen to the organization.

Competence, way of work and training

We quickly realized that we needed training and education throughout the organization. We had used an external company for a long time, who ran an agile course a few times a year for people who were interested. We decided early on that we needed to run this training internally, both so we could adapt the course to our needs, and so we could have our trainers running the course.

We created, with help from our consultants, an extensive agile training program for our employees and our managers.

• Agile crash course in agile (2 hour session)
• Basic agile for team members (2 days)
• We had training courses for specific roles like team coaches (scrum masters) and agile product owners (from 1–3 days)
• We established support for leaders and managers with agile leadership (2–3 days)
• We also created competence (guild) networks for different roles like user experience, development, testing, product owners, UX writers and so on where they could meet and exchange experience and knowledge. The network sessions were synced, so they ran on every 2nd or 4th week on Tuesdays, we did this, so everyone from the team was away on the same time and day.
• When a new team was established, we supported the team hands on with coaching for 1–3 months, depending on the size and the agile maturity of the team members. This was vital to get everyone onboard and could give direct help and feedback. The coaches helped with everything from Kanban and Scrum and how to run impact mapping sessions, or supporting leadership and how to sync with projects.

7. My seventh tip is to give the organization the competence and skills for a new way to work. This includes values, principles, and methods. As I mentioned prior, make it real and create a learning program, from short introductions to longer trainings depending on the role. Make sure that you get HR or similar function that handle training onboard as quickly as possible. Make sure to include the managers, get them to attend an introduction to agile and how they need to handle leadership and management in the new way of work (yes, it is different).

I would really stress that competence and training is vital. This is why I believe that this work need to be a function to handle all the work and activities that is related to it. The best thing is to make this function handle all training related to this new way of work and involve people and leadership, finance, business, innovation, product development, design, and developers. The area is huge and really need lots of time and people.

Also, make sure that you plan early on for a ”train-the-trainer” program and show people how they can transform from ”old” to “new” roles.

Listen and communicate

Oh boy, if you had any idea how much time I spent walking through the organization and listen, talked and discussed, wrote and educated. I would say that this what I did most of my time during 1.5 years I was there. This included ”why are we doing this” and ”what is it” to ”how do I do this”. It’s essential to be out in the organization and listen, discuss with people about their thoughts and questions. Initially, there were plenty of things that we could not answer. I believe it’s OK to say ”we don’t know, but we will solve it together”. To be vulnerable and ask for help is OK. This will create a stronger sense for what we are trying to do and more engagement from everyone.

8. My eight tip is to first have a simple common vision (see above). If you have this in place it will be so much easier to communicate the why, who, what and how. Make sure you are out and listen and communicate with your colleagues. And make sure there is time for, and communication competence in the transformation team. It’s hard and takes time to write editorial content for the intranet, set communication plans, create training material, videos, and FAQs.

9. My ninth tip is to work like a designer, create solutions that solve human problems. Be humble, have an understanding that the transformation and change is about people. The better you understand human needs and wants, the easier it will be to ”design the change”. All change is about creating a change of human behaviour, so by having empathy of the people you change for, the better the solution will be. To work as a designer today, you will need to be good at communication (see above) and a true facilitator. Create a shared understanding and facilitate the change process in small iterative steps to maximize the learning.

10. My tenth tip is to listen to yourself and how you feel. It is so easy that when you have a dream, you will finally burn up in the chase for it. Don’t. In this journey, I learned a lot about myself. I learned that I have a large need to be by myself, reflect and have my own time. A simple trick for this was that I started to block time in my calendar where I could reflect and just work on my own. That really helped me clear my mind and set my priorities better (and make me a better person…).

Epilogue — so what happened next?

So, what happened next? Wise people say that change never ends, and you will never be finished. After 1.5 years I decided to leave my assignment and let others, better than me, take over. We made sure we recruited a great change agent who had this transformation as her sole purpose (at the same time as I worked with this transformation I also worked with scaling our design team, which was, when I think about it, a really optimistic idea…). We also started to scale Team Change and merge some other related change related teams like our physical workplace, education, portfolio management, finance, HR, and leadership and DevOps & operations etc.

There is today a focus to make the organization more agile, quick and responsive where all functions in the organization are involved.

My (and our) 10 biggest mistakes

So, here is a summary of the mistakes I, and we did and what I learnt (remember, failing is an option, and it will make you learn new things).

1. We did not succeed in creating a common and sufficient clear vision at the beginning of the transformation, which made our work hard to communicate and drive efforts and activities.
2. We did not have an enough breadth in our competence, in our management group and in Team Change. We did solve this after a while and got business, HR, finance, operations onboard after a while.
3. We did not create enough feeling of a ”burning platform” or a clear ”why”. We could hear from time to time that ”it already works fine”.
4. We couldn’t engage the whole organization at the beginning. Many thought that this change only was about IT (which it is not).
5. We were not clear in what conditions and help we needed. We were too nice to add things to our backlog which we didn’t have time or competence to fix.
6. We had a hard time communicating our vision and roadmap when we didn’t have a clear and common vision at the beginning.
7. We did not have a platform, time or competence to communicate all the things we did and wanted others to do. Our intranet did not really support this kind of two-way communication, and our colleagues were not used to use wiki-based information. This lead to plenty of meetings and presentations, which took lots of time.
8. We quickly got stuck in numerous small things that ate up our time and created less impact.
9. We could not visualize an enough clear roadmap for management och the organization. This lead to some functions in the organization started their own initiatives.
10. Occasionally, we pushed a bit too hard on some functions, which made them frustrated, afraid and angry. When we changed many things how we should work, we quickly ”hit the ceiling”-moment which affected these functions. When we wanted to change things related to their function too fast, we got to a dead end.

Even if I see the above list as mistakes, I also see them as things that I learned something from. This journey was incredible and exciting, both for me and for the organization. I am extremely proud when I saw my colleagues come to work, happy, engaged and ready to create outstanding products and services.

This journey has made me a bigger person, and I am forever thankful for having the pleasure to work with all my colleagues who made this journey possible.

Please note that this is my own personal thoughts and views about working with (agile) change in a large enterprise.