It’s 2015, and ING is about to start an exciting transformation in the Netherlands. A new Agile Way of Working is introduced and this also requires a challenging cultural change. In the new organization, the Product Owner, Chapter Lead and Agile Coach form a virtual leadership team supporting squads. In this experience report the journey of one of these virtual teams is followed. It is a journey with ups and downs, full of learnings about how an Agile leadership team, should and should not facilitate the optimal performance of people and squads.
1. INTRODUCTION
It’s 4 o’clock on Monday, November 2nd, 2015 when I enter the meeting room on the fifth floor of the ING office in Leeuwarden, the Netherlands. When I look around I see the faces of people who are all new to me. These are the Product Owners and Chapter Leads of four squads I’m going to work with as an Agile Coach. “Welcome to our ‘POCL’ meeting,” one them says, “I guess from now on we can call this meeting a POCLAC as we finally have an Agile Coach with us!” After I have introduced myself, I sit back and take a deep breath. I start observing the meeting to see if I can identify room for improvement.
The meeting did not impress me. Although ING introduced a company-wide Agile transformation a few months ago and the people in the meeting represented roles that were in line with the new Agile Way of Working, I still saw a traditional management team meeting. The agenda of the meeting didn’t seem to be clear, resulting in an unstructured conversation from topic to topic and from person to person. I was wondering about the alignment between this meeting and the squads. The meeting seemed to be the place where important decisions were made, but I couldn’t see if the squad members had any influence on or even a connection with these decisions. Was this group of Agile leaders serving the squads, or mainly serving themselves? I realized that we had an interesting journey ahead of us.
That journey, from the very beginning in 2015 until the moment I left the department in October 2017, is the subject of this experience report. It’s a journey that reveals many challenges, ups and downs. Bringing the right people together doesn’t always create the right team. It takes effort and determination to find the most optimal ways for showing true leadership. How do you make sure people with different backgrounds serve one common goal? What is needed for the leadership to connect with the needs of the squads? How do they grow? Some answers to these questions can only be found in retrospect.
The journey in this experience report is described from the perspective of the Agile Coach. I, the Agile Coach, was part of the leadership team, and thus part of all its failures and successes. I have learnt how important it is to create, and stay focused on a shared goal in an Agile leadership team. It was valuable to increase the autonomy of the squads, even though I was surprised by the results of our approach. Furthermore, my experiences in this Agile leadership team reminded me, again, to keep evaluating. I believe these learnings are worth sharing. I do not intend to present the learnings as best practices though. What is a good practice in the context of this particular leadership team in this specific department at ING, may not be a good practice in another context. Taking that into consideration, the learnings may be helpful for others who also try to optimize the leadership approach for a new, Agile context.
2. One agile way of working at ING
In June 2015, ING Domestic Bank in The Netherlands introduced a new Agile Way of Working across the entire organization. With this new way of working ING wanted to achieve three main goals:
- Shorter time to market to respond faster to changing client needs
- Fewer obstacles and handovers to empower and give space to individuals and teams
- More motivated, passionate and self-starting employees
ING has looked at other successful companies for inspiration when defining their own Agile Way of Working. Companies like Netflix, Zappos and Spotify provided valuable guidance for an evolution of structures, rules and processes required for ING to regain the flexibility to remain relevant in the long run.
The Agile Way of Working of ING contains various elements. In this experience report I will explain a selection of those elements, based on what is most relevant to understand the main storyline.
2.1 Squads, Chapters and Tribes
An important starting-point of the Agile Way of Working was Jeff Bezos’ two-pizza rule: your meeting may not exceed the number of people you can feed with two pizzas. With more people, the number of connections will rise exponentially. The more connections, the slower everything proceeds. That is why ING decided to base the new organizational structure on small teams containing no more than nine people. These teams are called “Squads”. Squads are BusDevOps (or a subset of these disciplines), self-organising and cross-functional. They can be feature oriented, component oriented, or commercially oriented, depending on their purpose.
The personal development and the development of craftsmanship of squad members are organized in a “Chapter”. Chapters are formal groups of a maximum of 10 people with the same job role / expertise deciding on how things need to be done regarding their area of expertise; for example a data analytics chapter, a user experience chapter or a frontend engineering chapter. Chapters are also the hierarchical line to squad members.
The coordination between the self-organising and cross-functional squads takes place in “Tribes”. A tribe is a collection of squads organised around the same purpose (product or service), such as Mortgages, Business Lending or Private Banking. Squads within a tribe are collaboratively working on a joint problem or working on a shared topic. The overall ownership for a tribe, that ideally does not exceed a total number 150 people, is with the Tribe Lead (TL).
2.2 Main roles at squad level
The Agile Way of Working created a flat organisation at ING. Regular direct contact between the Tribe Lead and squad members was not uncommon, however, squad members had the most frequent contact with three other roles: the Product Owner (PO), Chapter Lead (CL) and Agile Coach (AC).
The Product Owner is a role that is held by one of the squad’s members, on top of her responsibilities as e.g. a Customer Journey Expert (someone who combines marketing, product management and / or business expertise) or a Development Engineer. The Product Owner owns and shares the product / IT asset vision.
The Chapter Lead’s tasks are twofold: she contributes to the delivery of value as a member of a squad, and she is the hierarchical manager of the members of a chapter. The Chapter Lead ensures the chapter members have appropriate competencies and skills by continuous improvement of their skills and the area of expertise as a whole. Furthermore she determines the way of working in her chapter and implements the use of standards for the area of expertise together with the chapter members.
The Agile Coach is allocated to a tribe from the Center of Expertise Agile Coaches, and acts as a ‘tribe-independent consultant’. Agile Coaches help to create a high-performing tribe by challenging, coaching and inspiring in terms of content, culture and process on all levels based on the Agile Way of Working. The number of Agile Coaches within a tribe depends on the Agile maturity of a tribe.
Figure 1. The key elements of the One Agile Way of Working at ING
2.3 The POCLAC as a new Agile leadership team
ING realized that the introduction of a companywide Agile Way of Working could not be done without a cultural transition. An important source of inspiration for this cultural transition were the ideas of Daniel Pink. In his book “Drive”1 he concluded that purpose, mastery and autonomy are the main motivators for people in modern, complex businesses. Before the introduction of the Agile Way of Working, the purpose, mastery and autonomy of employees were implicitly handled in a traditional management structure with team and department managers. The ownership of the development of all three motivators could be with a single manager. In the Agile Way of Working the responsibility for the purpose, mastery and autonomy on squad level was explicitly split between three new roles: the Product Owner (PO), Chapter Lead (CL) and Agile Coach (AC). These three roles replaced the traditional manager as a new leadership team facilitating the needs of the squads: the POCLAC.
The POCLAC is a coalition, which usually meets once a week or once a Sprint, at which the Product Owner, Chapter Leads and Agile Coach of each squad discuss the developments in a squad. POCLAC meetings are a way to work on optimum squad capacity and competency development. As the meetings are at squad level, they may involve more than one Chapter Lead.
Figure 2. The roles and responsibilities of the POCLAC
3. The journey of an agile leadership team
3.1 Background: Introducing the leadership team and its scope
The journey in this experience report took place in the tribe Daily Banking Services at ING in the Netherlands. This was a large tribe, consisting of over 30 cross-functional squads located in two locations. The scope of the POCLAC in this experience report entailed four squads of approximately nine people, all focusing on building, maintaining and improving the customer journeys of current accounts, such as “open a new current account”, “change a current account”, “close a current account” and “life events impacting current accounts”. When the journey of the POCLAC started in 2015, these four squads were typical component teams: two squads were formed around the frontend components of the customer journeys and two squads were formed around the middleware components. All squads connected to backend systems maintained in other squads/tribes.
Every squad had their own Product Owner. The squad members were part of six different chapters: two IT chapters and four business chapters. With one Agile Coach, this makes the total size of the POCLAC eleven people, on paper. In practice the leadership team was usually smaller. This will be explained in the next section.
3.2 POCLAC structure improvements
Adding more structure to the POCLAC meeting was the first improvement I decided to make after I had done my observations in the meeting. Fortunately my arrival had created a “natural momentum” for a change. The other POCLAC members showed interest in what the new role of Agile Coach could bring and were open to suggestions. An extra motivation for improvement was given by the Tribe Lead, who made the formation of effective POCLACs one of his key focus areas for the improvement of the Agile Way of Working in his tribe.
We started to look into a few practical things:
- What is the scope of our POCLAC?
We choose to continue to combine multiple squads as there’s added value in sharing knowledge and experiences.
- Who is part of the POCLAC, and who is not?
On paper the POCLAC consisted of eleven people. We found out that some Chapter Leads from the business side only represented one chapter member in the squads. We agreed that two business Chapter Leads could represent these chapter members as well, reducing the size of the leadership team to nine members.
- How do we structure our meetings?
I introduced a fixed meeting structure. To make sure this structure was understood and followed, the description presented below was added to the meeting invite in Outlook. Additionally we agreed that I would chair the conversation during the meeting.
During my first weeks as an Agile Coach in the POCLAC, we mainly focused on these practical improvements. We didn’t explicitly plan team building activities to grow as a leadership team. As a result, we saw improvements in the effectiveness of our conversations, but we were not yet a team. A significant reorganisation of the composition of the squads turned out to be the trigger we needed to make a next step.
3.3 Turning point: from component teams to feature teams
There can be many different triggers for groups to become teams. Often these are negative triggers: tough times forcing people to fight for their positions and find a common goal. In the journey of the POCLAC the turning point that marks a new phase for the leadership team is a positive one.
In the tribe Daily Banking Services another Agile Coach had initiated a discussion about the component-based purposes of the squads. According to the LESS framework, “a pure feature team organization is ideal from the value-delivery and organizational-flexibility perspective”2. Most key players in the tribe were willing to try out a feature-based purpose of squads. The squads that focused on the customer journeys of current accounts seemed to be the best place to try this out first. “Open a new current account”, “change a current account”, “close a current account” and “life events impacting current accounts” were good feature-based purposes. We only had to create an optimal mix of frontend and middleware engineers in the squads to form a “long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one”2.
As the overall product scope of the squads and the people available for the squads didn’t change, the POCLAC had the autonomy in the tribe to reorganize the current accounts squads. I made the Product Owners and Chapter Leads aware of an important principle: the new squads are likely to be more successful if the members are involved in the squad reorganization. When everyone agreed to follow this principle I proposed a reorganization approach based on self-selection3, within a set of rules and preconditions defined by the POCLAC. The self-selection process was a success: it not only ensured a good start for all four squads, it also presented the POCLAC as a true leadership team for the first time. Squad members saw the POCLAC working together in creating the optimal delivery conditions for them. Also, for the first time the POCLAC saw themselves as a team serving a common goal.
3.4 Value autonomy
The autonomy of the squads and the individual squad members had to be valued in order to achieve the Agility that the ING Way of Working aimed for. The POCLAC was aware of that: autonomy always was one of the key themes, although we had to learn what that meant for us. It was very tempting to help squads by finding a solution for them immediately, instead of helping the squads to find a solution themselves. The POCLAC meeting turned out to be a perfect way to challenge each other’s point of view and align our message to the squads. In this way we could prevent a situation in which a Product Owner starts problem solving while a Chapter Lead helps the squad to find a solution themselves. This lead to a conversation as presented below:
Product Owner: “it seems that I don’t have frontend capacity during the holiday of Jane. The frontend skills of John are being developed by Jane, but John is not yet able to work alone during her holiday. Both engineers are in your chapter, please help.”
Chapter Lead: “I’m not sure we actually have a problem here. This might be happening in other squads too, without us knowing about it. I propose that John first reaches out to his colleagues of the same chapter who are working in other squads to see if they can be his backup during the holiday of Jane, before we do anything.”
3.5 Collaboration improvements
The POCLAC had a shared goal: facilitate an optimal performance of the squads. That didn’t mean that the interests of Agile Coach, Chapter Lead and Product Owner were always aligned. Sometimes the short term delivery needs of the Product Owner could conflict with the long term Mastery development strategy of the Chapter Lead, as shown in the conversation below:
Product Owner: “To get this new feature live as soon as possible, I really need more Tibco skills. John and Jane have these skills, so they are now fully applying those skills. Of course it’s temporary.”
Chapter Lead: “I disagree. It’s important for their future as an engineer, aligned with the future of ING, that John and Jane develop their Java skills. Their personal development is seriously harmed if they cannot use Java. Moreover, we both know that ‘temporary’ isn’t that temporary. We need to find another solution.”
Who is right here? Both the Product Owner and the Chapter Lead try to serve the needs and goals of ING, but they’re looking at a different timespan. The POCLAC meeting helped to make these conflicting interests explicit and allowed us to find a common approach before the conflicting interests could harm the productivity of the involved squad members. As an Agile Coach I could help the Product Owner and Chapter Lead to challenge each other constructively and explore alternative solutions. In this specific case we eventually could agree on exploring opportunities to hire temporary external capacity to meet the timelines for the new feature while meeting the development needs of the engineers as well.
We had to learn how combining the different focus areas of the three roles could strengthen the effectiveness of our leadership. The way we improved our hiring process is a good example of the positive results of the collaboration in the POCLAC. At the start of our journey the hiring process was almost entirely done by the Chapter Leads. Moreover, there was hardly any connection between business and IT Chapter Leads. Soon we started to discuss how to match the skills of new people with the need of the Product Owner’s backlog and the mastery gaps identified by the squad members. Later we also saw the benefits of collaboration in the hiring process itself. At the end of the journey, interviews were always done in couples (i.e. business Chapter Lead + IT Chapter Lead or Chapter Lead + Product Owner). “I’m going to interview two candidates on Tuesday for squad X and Y, who is going to join me?” became a standard question in the POCLAC.
3.6 Reality check: how do we grow?
In 2017 a new, challenging program was launched that raised the bar for the delivery of the four squads. At that time we knew that the POCLAC was well recognized as an effective Agile leadership team based on feedback we regularly received from colleagues working elsewhere in the tribe. We realized though that we had to take a next step in our development as an Agile leadership team. This marked a new phase for the POCLAC characterized by uncertainty: about the performance of the squads and about our own performance. We came to an uncomfortable conclusion: we had taken our way of working for granted for too long, while many aspects around us kept changing. As the Agile Coach in the POCLAC I felt responsible for the lack of time we had spent on the evaluation of the performance of the squads and the POCLAC.
Triggered by the decision to add extra people to the squads to cater for the needs of the new program, we first assessed to what extent the squad composition still supported optimal performance of the squads. The squad composition had remained mostly stable since the reorganisation of the squads to feature teams. We agreed that this reflection had to be a thorough approach and that the squad members had to be involved, just like we did when the squads were formed a year earlier. Also similar to a year earlier it was my role to advise the leadership team on what steps to take to make the process successful.
First we did our own reflection during an offsite, focused on our three areas of interest: Autonomy, Mastery and Purpose. Then we planned a session with all squad members, where we summarized our approach and outcomes and facilitated interactive ways for the squad members to respond, reflect themselves and come up with ideas for improvement. In the session we stated that the responses and ideas provided by the squad members would be used as input for the final decision making, done by the POCLAC. Of course also the final decisions would be openly communicated to the squads. One of the most important decisions we eventually took was the reshuffle of a few squad members to other squads to optimize the squad composition again for the delivery of the new program. We also decided on the skill set required for the new people and to which squad the new people had to be added.
This reflection process revealed something interesting. We were disappointed by the limited amount of ideas that was brought in by the squad members. When we asked them why that was the case, we were heavily criticized on how we dealt with their autonomy. Although we believed that we were respecting the autonomy of the squads, the perception of the squad members seemed to be very different. Multiple squad members stated that a new self-selection process would have been a much better idea. All our efforts to value the autonomy of the squads had created a different autonomy-standard, but we did not realize at that time how successful we had been in creating a new Agile culture based on autonomy.
3.7 Growth opportunities for the POCLAC
In 2017 squad members expected different behaviour from the POCLAC than at the beginning of the journey. The beginning the POCLAC was seen as a traditional management team that one could not influence. Complaints about the performance of the leadership team were rarely shared openly. In 2017 squad members more explicitly asked for openness and involvement. When the expectations were not met, an immediate comparison was made with the old management teams from pre-Agile times. Finding the right response to this POCLAC perception continued to be a struggle for us. We approached the squad members and asked them what should be done by the POCLAC to create a more open atmosphere. We shared as much information as we could, while we continued to explain that in some cases meeting topics could not be shared right away. We also became more flexible in the representation of POCLAC members when they were absent in the meetings. Product Owners and Chapter Leads were free to ask a squad member to represent him/her. This helped a little: when a squad member saw what happened in the meeting, they gained a better understanding of the work of the POCLAC. Still, we never managed to change the perception entirely.
We also evaluated the effectiveness of the POCLAC meetings. Complaints of the Chapter Leads triggered a change in the meeting structure. In the original meeting structure, we made a round from Product Owner to Product Owner and asked them the standard questions. When there was time left in the meeting, the Chapter Lead and Agile Coach could bring in additional topics. This worked well for a long time, but later this started to have impact on the perceived hierarchy between the roles. The structure gave the Chapter Leads the feeling that they were less important. To avoid that from happening, the Chapter Leads proposed to be less strict in who speaks first. Instead we made a round from squad to squad and discussed Autonomy, Mastery and Purpose questions in a more random order per squad.
We realized that most conversations during the meetings were focused on solving problems. To make sure that we would not forget to celebrate our successes I brought in one extra question in the meeting structure: “looking back at squad X in the past week, what made you proud?” It was a small adjustment with significant impact on the atmosphere in the leadership team.
3.8 The end of the journey
In October 2017 I started a new Agile coaching assignment at ING and my part in the journey of the Agile leadership team described in this experience report ended. That doesn’t mean that this POCLAC stopped though. I found a replacement, and the others continued their journey. Looking back at the two years that I was part of the journey, I’m proud of what has been achieved. We managed to facilitate the need for Purpose, Mastery and Autonomy of the squads better in 2017 than at the beginning in 2015. The knowledge that we gained about leadership in a new Agile culture makes me even more proud. The learnings of the first two years of the journey form the foundation of the growth of the Agile leadership team in the next two years. New challenges for this leadership team will appear, but I feel confident that their growth will continue.
There are many other POCLACs at ING. Looking back at the journey described in this experience report, I realize now how important it is to share experiences between POCLACs and learn from mistakes. The challenges that I faced were not unique, nor were the solutions, although back then I sometimes thought they were. Finding solutions becomes more difficult if you don’t know what has been tried before by others. Therefore after I left the Daily Banking tribe I decided to more actively facilitate knowledge sharing about working in POCLACs in the community of Agile Coaches at ING. I shared this story to trigger valuable conversations with my peers. Furthermore I developed a workshop based on the challenges I faced in my Agile leadership team journey. With this I aim to increase the awareness of the importance of the POCLAC and help others to improve the effectiveness of their leadership. Time will tell to what results that will lead.
4. What We Learned
The journey of the Agile leadership team in this experience report reveals many learnings. Below I will list the key learnings of my experience:
- Stay focused on your shared goal and be explicit about it. This helps to agree on the next action, especially when you’re facing a conflict of interests.
- Be prepared for the moment that your culture actually changes. An Agile leadership team has a lot of impact on the Agile culture on the work floor. That means that the Agile leadership team has to stay aligned with that culture
- Know who you work for and respect them. Always ask yourself: what is the impact on the autonomy of the people when I do this?
- Never stop evaluating. Don’t wait to take action. Just an experiment could be fine to improve, even if you think you’re doing well already
- The agenda of your meeting matters. A lot. It has major impact on the conversation that you’re having and the decisions that you’re taking
5. Acknowledgements
First of all I would like to thank and acknowledge the Product Owners and Chapter Leads who were part of the journey I described in this experience report. It has been a pleasure to be on this journey together. Without you there would not be a story to share!
Furthermore I would like to thank Denise Verburg for providing me with useful resources and feedback. I am also thankful for the feedback I received from my peers: the Agile Coaches working at ING. Lastly, I would like to say a big thank you to my shepherd Chris Edwards for his guidance and feedback during the writing process.
REFERENCES
1 Pink, Daniel H. “Drive – The Surprising Truth About What Motivates Us” Penguin Putnam Inc, 2011
2 https://less.works/less/structure/feature-teams.html
3 Together with Maurice van Wijk I have given a presentation about this self-selection process (“One small step for man, one giant leap for Agility & Autonomy”) at XP2017: https://www.agilealliance.org/xp2017/
