How I helped ING create End-to-End autonomous teams

I usually share such highlights of my involvement with ING during their Agile Transformation, albeit not to this extent, with potential clients and recruiters when we’re discussing my background. This time I thought I’d openly share a bigger part of my experience and give an inside view of how I was involved with the transformation project. This post mainly describes some major events that took place within those months as well as my thoughts at that time. Enjoy!

N.B. Names were changed for obvious reasons and some drama added.

Part 1 — Getting there

Final thoughts

It’s late afternoon on January 1st 2018, and my newlywed wife and I are just finishing eating fish at an expensive restaurant in my hometown in Greece, my mother’s treat, who’s sitting opposite us with her elbows on the table and her fingers entwined.

“Are you sure this is going to work?” My wife asked me. “I’ve no idea, but it sure sounds like a good challenge! Plus, it can be a career changer, who knows? Anyway, I have to give it a try, even if it’s for a couple of months. Just to say that at least I tried.”. “I’ll miss you”, my wife replied.

It would be a 12-month contract and I didn’t know how often we would be able to see each other during that time. Nor did we know whether I would be able to travel back and forth every week, or the mechanics behind making this distant relationship work anyway.

My mother was just staring at us, without saying anything, trying to hide her motherly worry under her elderly smile. I’m sure that deep inside her, she was contemplating whether leaving a wife and changing countries was a good move for her son, and how things would work out between us. But she also knew that this wasn’t her decision to make, so she decided to keep silent.

A few minutes later, I jumped in a taxi that took me to the airport. I watched an indifferent movie on the flight, feeling somewhat miserable thinking “Who flies away from their beloved ones on new year’s?” I arrived at Charleroi at 23:55.

A few weeks earlier, whilst I was sitting at my desk at work, I had received a call from a Belgian recruiter asking me whether I would consider going to Brussels at ING. They would have this big thing going on and they would need some Agile Coaches to help. I tentatively accepted, thinking “why would they scout the UK for coaches? Surely Belgium must have a few…”. We went through some Skype interviews and in the end, they accepted me to start on the 2nd of January 2018.

Arrival

It was now past midnight, 2nd of January, and I was in a taxi with a driver that I was certain was mute; apart from a couple of nods, he hadn’t said a word since he picked me up. He maintained that attitude to the moment I slammed the taxi door at the end of my trip. I tried to cover my face with my elbow against the horizontal rain caused by the strong wind. Gee, what a great start…

The rest of the night wasn’t great either. My pre-paid apartment turned out to be a really dirty s-hole. When I tried to find a room at a nearby hotel, all of them were full, due to new year’s. Eventually, I managed to find one, only to realize a few minutes later that there was water leaking from the window due to the heavy rain. After all this good luck, a hand-picked (literally) kebab and a Belgian beer later, I managed to go to sleep at around 4:30 am, in order to wake up fresh 3 hours later at 7:30 am to go to my new workplace.

From the outside, ING’s offices at Cours Saint-Michel resembled an old soviet hospital, but boy was I in for a treat when I went in: complete and absolute renovation! Shining reception desks and funky seating areas. The orange lion with the strangely benevolent look was lit at almost every corner, you couldn’t miss it.

Every floor was named after a country, UK, Greece, the Netherlands, Spain, and others, and it had that country’s theme and colours through and through. The UK was closed due to renovation, which we cynically agreed later with my fellow colleagues that coincided nicely with Brexit. On each floor, you could find massive raising desks with big monitors and modern docking stations, a bar-style shared area with a big Nespresso machine with 3 cut-in-half Vespas used for seats, a lot of open space, airy meeting rooms, and a canteen in the basement. That canteen was easily in my top 3 highlights! Choice of grilled meat, poultry, fish, selection of at least 5 different meals every day, a dish of the day, salad bar, desserts station, and whatnot. I would be practicing my French a lot in that canteen in the months to come.

The need for Agility

ING started their [serious] Agile transformation journey at its Netherlands division in around 2016. This has been enforced but also supported by the top of the organization. ING had realized that Agile is the only way forward for a bank of its caliber, and thus invested a huge amount of money, time, staff, and resources into pulling this off.

But ING is also one of the major banks in Belgium, and Belgium has a completely different culture than ING’s motherland. Granted, half the country speaks (and are) Flemish (which is basically Dutch with a lighter accent), but other than that, they’re completely different people. For starters, Belgium has extremely powerful unions. This means that every change that happens in the corporate environment has to be approved by the unions first. And I am talking about changes even in senior management roles within a bank! Such is their power over there.

Nevertheless, ING had a vision of a united bank, the so-called “Unite 2020”, where they would ultimately merge their systems, staff, and processes, under one unique experience. Belgian ING was almost completely agnostic to Agile, so inevitably, it had to play catch up with the way that Dutch ING functioned.

In total, there were some 13 tribes at that time at ING. I worked in the Assisted Channels tribe consisting of around 350 people (rather big for even for an ING tribe), a Tribe Lead (like a mini CEO), three PALs (Product Area Lead), and around 35 squads. No Scrum Masters, just Product Owners, and Agile Coaches. The squads were meant to be self-organizing, to the point that they wouldn’t need a Scrum Master as per their newly crafted blueprint.

The Spotify model

A few years earlier, McKinsey had worked with ING to produce an Agile Transformation blueprint. When it came to implementing it to the Belgian side in late 2017, it resulted, among other things, in the “big-reconstruction” as employees called it: people were laid off and had to reapply for their positions, resulting in 25% reduction of staff that didn’t fit in the new world as the blueprint prescribed it. So, amongst the -necessary for change- urgency and excitement in the landscape, there was also fear.

The blueprint was largely inspired by the way that Spotify worked, including terms such as tribes, squads, chapters, and guilds, that is also widely adopted today by other companies. It was therefore aliased as the “Spotify model”. (This naming convention has been sparking conversations ever since on “whether Spotify is a company or a working model”, but that’s for another blog post).

The tribe

Assisted Channels was a tribe that produced software for consumption by the internal bank staff, including telephony systems with integrated CRM, and physical branches software to control ATMs.

My tribe was an x-border tribe or a cross-border tribe as we called it, which meant that some squads were located in Amsterdam, and some in Brussels. I’d have to work closely with the x-border Agile Coaches to coordinate our efforts, including traveling back and forth from Brussels to Amsterdam a couple of times per month for each of us, plus frequent offsites, sometimes halfway through, in Rotterdam.

We would also have to mentor more junior, internal ING Agile coaches over the next 12 months in order to bring them up to speed with Agile best practices, so that they could collaborate better with their Dutch counterparts and the new environment as we were about to build it. All this would be part of the 2020 vision for “One-Bank” and “Unite 2020” (I don’t think anyone would have imagined back then that a virus was about to trash any “2020” plans worldwide!).

The waterfall

In the Assisted Channels tribe, I worked specifically with the five CRM teams that were unsurprisingly named after their function: the Front team that dealt with UI development, the Back team that dealt with back-end development, the Test team that was responsible for testing, the Bug-fixing team that was responsible for fixing any bugs that appeared after the release, and the Business team that was preparing the customer journeys and upfront specifications. Yup, that’s right, it was all pure waterfall, no shame about it though. I would have to make that thing Agile, somehow, and my intention wasn’t to stop at just introducing a 15-minute stand-up and a planning session. I could smell there was unlocked potential there.

The year earlier, a big well-known consultancy (let’s call it Consulting Co) was hired to help the Assisted Channels area and deliver some software on time (and budget), something that ING had repeatedly struggled with. Consulting Co, not only delivered it but, -legend has it- it was the only part of the organization that had succeeded in delivering something on time. So, they were asked to carry on with the CRM implementation of the Assisted Channels tribe. Bright, hard-working guys, working for extremely long hours, Consulting Co had their own agenda and ways of doing things. Some of them joked that they were living in the office for months. That joke included a good portion of truth!

The five CRM teams’ composition was almost 50–50: 50% ING staff and 50% Consulting Co staff. Consulting Co was organizing all the various phases, from planning to delivery and testing. Yet, I was asked to somehow introduce Agile and support the mindset and cultural change to these teams where ING employees were only a fraction of. Within these teams, Consulting Co staff had no appetite nor will (or instruction anyway) to change their culture or promote any “Agile ways of working” in any way. That would prove to be a very tricky challenge for me over the next 4–5 months and I’d have to invent new ways to work around them (and with them) to help support ING’s Agile Transformation.

Part 2 — Action

The PAL (Product Area Lead)

I met my PAL (pun intended) Vins, five or six days after I joined the company, at the beginning of January. Our meetings would take place once and sometimes twice per week for an hour, in the form of debriefing and strategy alignment, and our communication and mutual understanding was great as far as I was concerned. Vins was definitely a man with a plan, and a strong proponent of Agile himself. In one of our first meetings, I described what I had seen so far.

“Vins”, I said, “I’m sure you know that an Agile Transformation implies a cultural and mindset change. I don’t think we can have these while Consulting Co is working with internal ING employees, under strict deadlines. I don’t think their remit is to change anyway. They’re here to deliver and that’s what they’re doing, in their own way. Additionally, we need to deliver the CRM and telephony systems on time by small increments. I don’t think it can happen, not in this setup at least. I think you’ll have to choose which one you want: cultural change or on-time delivery by any means?”

“Well, it’s not a matter of one or the other, Achilles”, Vins replied, “we need to do both”.

Huh, …how typical I thought. A senior manager who wants everything.

Needless to say, topics such as culture change vs on-time delivery kept being repeated over and over in our meetings.

The existing teams

Most of the time, I would attend the ING-Consulting Co combined meetings, about risks and issues, planning, RAG status, etc. I would almost always question problems such as resource allocation and the fact that testing and bug fixing was performed by separate teams that were in turn causing problems downstream. I suggested an alternative: “let’s include a Tester, an Ops, and a Business person in each team to make them more let’s say… autonomous?” Almost always the reply from Consulting Co’s senior staff was “this meeting is not about restructuring the teams”, or sometimes simply “we’re not doing this”. What could I say? They were the ones to deliver, they were heavily trusted, they were calling the shots. And rightfully so.

Partly instinctively and partly driven by sheer logic, I approached the (according to the diffusion of innovation theory) innovators of the Back and Ops teams and I asked, “Ok guys within the boundaries that we’ve been prescribed to work, what can we do to improve our process?”. I knew that if there was anyone that I could influence, it was them.

I made sure that we had such conversations in a very open forum-style and as often as we could. We started optimizing the mechanical stuff: ceremonies, stand-ups, learning about relative estimation techniques on user stories, what makes a good user story, and how to make actionable retrospectives. However, I would always seed the idea of autonomy: “…you see if we had a tester and a business guy in the team…”. The idea started to grow in their heads and I could feel they were up for some experimentation. If only someone with higher authority could allow them to do so!

The brick wall

In parallel, I kept repeating to Vins during our one-to-one sessions that if we wanted to proceed with any sort of autonomy and end to end accountability in the CRM teams, it would have to be him to pull the trigger into reshaping the teams, since, as far as I was concerned, they had reached their maximum level in terms of ceremonial practices. They were doing zombie-scrum perfectly:

• The waterfall project was cut down to pieces and fed to the teams sprint by sprint.
• The Front team took the UI stuff, the Back team all the back-end functionality, the Ops would arrange for environment provision and setup, the Bug fixing team would need to pick up any bugs produced by the Back team, and so on.
• Questions or clarifications on design and customer journeys had to wait for a sprint or two.
• Bugs and testing were offset by one or two sprints since they were happening after the development was finished.
• The Business team was working on the customer journeys and specs separately (and secretly?), and every now and then, when they had something new, they would surprise the POs by feeding their backlogs with new information, sometimes forcing re-prioritization, or changing scope.

All these with morning stand-ups, and user story estimation. No demos, since they didn’t have the ability to because of their setup, and very few retrospectives since there was hardly ever a time for that.

I, on the other hand, kept repeating to Vins, that If we were going to proceed further with Agile, we would have to promote the idea of autonomous teams. That way we could push accountability easier to our squads. However, I suggested that if there was anyone who should do this, that should be him. “Vins, I don’t have the authority, I’m not their boss, so I can’t do it for you. You will have to be the one to call it, not me”, I said. It seems that this idea got into Vins’ head, and after a while, it appeared that he was just looking for some good timing.

Random visitors

One day, during the Back squad’s morning stand-up, I noticed three new young guys in their mid-20s standing alongside the rest of the team, introducing themselves. “‘Hi, I am Ruben’, ‘I’m Max’, ‘I’m Thomas”, they went in turns “…and we were told by the IT Area Lead to come work with you guys”.

“So, what are you going to do?”, the Product owner asked.

“Erm… we don’t know. We were just told to come here and join you guys”, one of them said, smirking and shrugging at the same time.

“Ok then…” the Product owner said breaking a side look at me bewildered.

That did it. I was surprised as I was furious. How can someone just shove a bunch of guys in a team? Doesn’t he respect the fact that we’re trying to build some team consistency here? This just isn’t how it works!

I grabbed the Product Owner of the Back team after the stand-up to talk:

“What the hell man? Who are these guys and why are they attending your meeting?”, I asked him.

“Honestly, I have no idea man… It’s the first time I see them.”, the Product Owner replied. It appeared that we shared the same level of confusion at this point.

You see, what had happened is that the tribe was continuously hiring for people as they were understaffed. When they found them (internal transfer), they just sent them over and told them to join a team — any team. This team happened to be the Back team as it happened to have their stand up meeting that morning.

“No no…that’s plain wrong”, I said to the Product Owner. “We need to find something for them to do, they can’t just be part of this team. And do what?”

“I know man, this sucks”, the Product Owner replied.

So, I approached the three new guys after the stand-up. I found out that they were developers, hired to implement the integration between the CRM and the telephony systems. We realized that they weren’t a natural fit for any of the CRM teams as it stood as they would have to create something from scratch using a different technology. But for me, the solution was a no brainer. So, later that day, I approached the Product owner again and I asked him.

- Hey man, doesn’t Pierre in your team has a business background and was about to be a Product Owner a few months back?

- Yes, he wanted to be a Product Owner since forever but it didn’t work out as there was no squad for him to run. So, he’s been doing a bit of everything else ever since.

- Hmm…Let’s go and have a chat with him, shall we? I have something in my mind that might just work.

So, we found Pierre and asked him.

- “Hey Pierre, this is the situation. I am thinking that maybe we can create a squad out of these three guys, to develop the integration system between the CRM and the telephony system.”

- “That sounds reasonable”, Pierre agreed.

- “And, they’ll need a Product Owner, I added. Do…you have anyone in mind?” I said in a suggesting tone.

- “Well, me of course!” Pierre smiled.

- “Great, let’s get to it”, I said and patted his back.

And so it happened. This team had something in particular: these guys were developers, and testers, and DevOps engineers. They could (and wanted to) do a bit of everything. They wrote code, they did the analysis, they wrote tests, they knew TDD and used Git. They were also scrum-savvy. A few hours later, line managers and the rest of the teams were informed and gave their thumbs up. And just like that the first autonomous squad, amidst a struggling waterfall area, was spun-up!

However, I couldn’t declare victory yet, it would take me a little more than a willing Product Owner and a few cross-functioning individuals to progress with the rest of the teams.

The days and weeks went by, with me partly mentoring the internal Agile Coaches, helping the CRM teams with their zombie scrum practices, continuing planting Agility seeds in their heads whenever I could, synchronizing with the cross-border tribe Agile coaches and coaching the PALs and Tribe Lead on the Agile mindset. Most importantly, I was enjoying my lunch breaks at that amazing canteen!

Reshuffling the teams

I can’t remember what exactly triggered it, but in one of our meetings around five months in my contract, Vins said to me “You know what? How about at the end of the demo, I come out and say that we need to reshuffle the teams a little bit, eh? How would that work for you?”

“That…would…definitely help!”, I said, trying to control my enthusiasm. I was convinced that this very action was key to proceed with anything else that had to do with autonomy or end to end accountability in the squads. “You do that and leave the rest on me”, I added.

And so it happened. A couple of days later, at the end of a demo meeting, the PAL asked everyone to join us in the room. He gave us a long speech about his vision on product delivery, and in the end, he added: “…even if that means that we need to do a bit of reshuffle of our teams”. Yes! The red light had turned to green and we were back in business!

Going back a few weeks, I had put together a plan with pictures and descriptions on how the autonomous, end-to-end squads would look like in the CRM world. Whenever I shared this idea with the squad members, it seemed to go down quite well, despite the presence of Consulting Co. The main points of the plan were:

• The Product Owners would have to prioritize the new features to be built and agree on them weekly. They would have their own Product Owners feature backlog.
• Then, each team would be 100% responsible to decompose (create user stories), deliver, test, and release that feature.
• Each team would have its own release engineer (a dual role held by a developer or a tester). There would also be one head-release engineer for all teams, who would know what goes in and what goes out at the end of each sprint, just in case there were code clashes.
• At the end of each sprint, each team would present and record a live demo, and send an invite to the whole department to whoever might be interested to attend. If they couldn’t attend, the recording was also stored in the cloud and shared at the end of the session.
• Every month, we would hold “family demos” run by the combined CRM and telephony teams, that would demonstrate the complete CRM/telephony product as it shaped incrementally. These would alternate between Brussels and Amsterdam, with the help of video conferencing tools.

So I dug this plan up and emailed it to all five CRM squads, the Chapter Leads and the PAL. By that time, I had created a critical mass of followers of the autonomy mindset, including Chapter Leads, who acted as middle managers as well at that point in time.

In the following weeks, we agreed with the Chapter Leads to have an open discussion with the CRM squad members around skill sets, team autonomy, and accountability, and agree on who could join which team. It would have to be a mutual agreement to avoid discontent but we would also have to be reasonable on who joins which team. Each team should have UI and back end developers, someone from a business background, a tester, and an ops person at a minimum.

The teams selected avatar Salesforce names such as Cody, Appy, Astro, and Cloudy. They weren’t characterized by the nature of their development area anymore; they were doing a bit of everything. They would be delivering features from then on.

Not too bad after all

Shortly after the reshuffle, I remember one person saying “Well this isn’t so bad actually! We can do more stuff now that actually fits in a sprint, and we know how to handle bugs!” “Well, what did you expect? The end of the world?”, I replied with confidence.

I didn’t forget to check at every given opportunity on the squad members’ content of this new regime. I helped put some improvement feedback loops in the teams in the form of questionnaires and diagrams that measured factors such as personal aspirations, team collaboration, impediment resolution times, and others. The same questions were sent to the whole team at the end of each sprint, and a history log of improvement slowly evolved.

I was really proud of what I had managed to pull out and sustain; actual autonomous, end to end accountable teams, with minimum disruption and happy employees. That sounds like the dream of any transformation expert. Anyone I would tell about this in the weeks to come was staring at me with a look of “quoi?”. It seemed impossible given the culture and the time we were given.

I don’t know, maybe I got lucky. Maybe I persevered, who knows. In any case, I felt very satisfied with my achievement, and so seemed the squads that I worked with. If anything, it was a real eye-opener for them regarding their potential, as I had envisioned in the beginning.

Part 3 — Conclusion

It has been a little over two years since I left ING Brussels.

My contract, as well as most of the Agile coaches’ who were hired for this transformation, was prematurely canceled just shy of nine months after I joined. It was a decision based purely on funding and as we found out later, ING had hired more coaches that they could afford to help speed things up. This resulted in the premature termination of the contractors.

I don’t know the current state of ING Brussels, but as Agile Coaches, we raised a red flag to the Agile Transformation committee that with the amount of shakeup we caused to the company during this transformation, it would be prudent (if not crucial) to sustain it for a few more months, until it solidifies and becomes the new norm.

My takeaway

One of the key takeaways for me during this time was that if I had to select the most instrumental factor that helped my efforts was the continuous l̶o̶b̶b̶y̶i̶n̶g̶ conversations with the PAL, trying to influence him towards instructing the teams to reshuffle. For me, that was yet another proof that transformation comes from the top, the leadership.

I haven’t mentioned a few things that happened during my tenure at ING, some of them including forging strong friendships with other Agile coaches and staff along the way, experiencing the banks HQ in Amsterdam from the inside, learning about two different cultures that I had no idea before, and meeting some very bright and adept people. For me, it was indeed a career changer as I was exposed to a lot of things that increased my knowledge around Agile transformations and organizational change, that I am sure I will be using in the future as a case of success.