Many organisations execute IT transformations to be more efficient and effective. However, the context differs between organisations, and there is no blueprint to copy IT transformations across organisations. We need to listen to the signals from inside of the organisation, learn, and adapt. In this experience report, we detail our approach and learning for a DevOps transformation within a bank in The Netherlands. Our most valuable insight is to put people at the centre of the transformation since we work in a knowledge field.
1. INTRODUCTION
During the last two years, ABN AMRO, a large Dutch financial institution, formed a strategy and subsequent transformation approach to completely move their IT from a split between development and operations towards DevOps. The transformation is strengthened by a move to the public cloud and away from a managed service provider.
This report is a combination of two converging stories. We are two authors involved in the transformation program. Our perspectives came from these two angles: organisation-wide (Matthijs Dee) and inside of a development department which was the frontrunner in the program (João Rosa). As you can imagine, there were different priorities and viewpoints, and we want to share our experiences of this journey. Especially due to the complexity of the organisation, the current structure, the industry where the bank is bounded, and the dynamic market where the bank operates.
As a teaser and perhaps the most essential learning was always to be connected to people. Although different people have varying roles, the DevOps dynamic within a team changes (compared to the current status quo) and the bank can accelerate when taking into account the accumulated experiences. This learning, but also others, are explained in more detail in the course of this paper.
2. Background
ABN AMRO is a top 3 bank in The Netherlands, with a full banking service towards individuals, small and medium enterprises, and corporates. The bulk of the business in The Netherlands is based on Retail Banking services (e.g. accounts, savings, payments, and mortgages), but also follows its customers abroad.
After the financial crisis in 2008 hit, the Dutch activities of the bank were rescued by the government. As a consequence, ABN AMRO needed to integrate with the Dutch parts of Fortis Bank Nederland and rebuild a lot of key components that were sold to other parties (RBS and Santander). Right after the successful technical integration and rebuild, the bank needed to look at the competition and to make sure that it stayed on par with the ongoing digitisation of customer needs. Especially in the Retail Banking area where the online channels were expanding towards mobile more and more.
The bank has the ambition to be one of the frontrunners, both with the portfolio offer, as well as with the technical landscape. To achieve it, a DevOps transformation program was created to move the organisation to a DevOps way of working. The program is built upon the previous Agile transformation, and the end goal is to create autonomous DevOps teams, minimising the handovers in a value stream. The bank has circa 19.000 employees, and circa 6.500 employees within IT. As far as we are aware, it is one of the most significant DevOps transformation programs in Europe within a highly regulated financial industry.
ABN AMRO went through its Agile transformation between 2014 and 2017. The transformation resulted in around 550 agile teams which are called blocks. Blocks are organised in business-related Grids; Grids are a matrix organisation form, where there is a business component and an IT component, with different management and operational roles.
The DevOps program is called the Apollo program, and the whole theme is around outer space. The Apollo program has the ambition to guide the organisation to a new operating model. It is composed of several different parties that are part of the bank structure; the program assists the Grids in moving towards the new operating model. The new operating model contains various topics under the DevOps movement, mainly the merge of Grids and operations departments into the teams. With the merge, the scope of the teams changes, where it now has both development and operations tasks. At the same time, it affects how the Grids are structured, given that topics such as reliability engineering, functional maintenance or on-call duty needed to be considered in a broader scope than before. In the end, the Apollo program is forcing silos to be broken, which will reduce the number of handovers in the software development process.
3. Apollo Program, a DevOps Transformation Program
3.1 How the program came to be
At the beginning of 2018, the situation at ABN AMRO was already showing the beginning of a movement after Agile. Many development teams were experimenting with options to move away from the on-premise data centres and seek for opportunities in the public cloud (mainly Azure and AWS). Starting 2018 the number of teams experimenting was around five and grew rapidly to over 100 teams. With this growth, the management team of IT couldn’t and didn’t want to ignore the movement any longer and started to organise a program around this movement.
In the first period of the program, an inventory was made how to support this movement, but next to the 100 teams already experimenting, also to look at a scaling towards all teams in the organisation. Once this scope was set in stone and also management buy-in was achieved, the necessary building blocks needed to be organised. What are the financial implications? Do we need a reorganisation? Are the technical capabilities enabled? What is our change management approach towards leaders and operational teams? Are the processes and related controls adequate to support the combination of operations and development on team-level?
3.2 Initial steps to build the program
With the key questions in mind (organisation, enablement, financial implications, processes and controls, approach), the first step was to embed the movement to DevOps in the long-term strategic goals of ABN AMRO. For this purpose, a business case was devised, not only for DevOps and the productivity and financial benefits it would entail, but also incorporating other movements like the move to public cloud and revamping the offshore model. With this business case, the Executive Board and Executive Committee of ABN AMRO were convinced, and thus they captured the transformation in the bank-wide strategy.
Secondly, a program organisation was set-up to look into the other key topics in more detail:
- Organisational Design—Responsible to redesign all related processes with the change to DevOps to an operational level to provide guidance on team-level and create an HR approach to support the continuous learning and development of the related IT staff.
- DevOps Enablement—Ensure that the proper tooling and platforms are available to support the teams to be autonomous on their IT estate, spanning continuous integration and delivery (CI/CD), monitoring, infrastructure consumptions to security.
- Cloud Migration—Set-up a factory-based approach to support teams to rapidly move their IT estate to the strategically chosen public cloud.
- DevOps Execution—Devise an approach to transform the Grids, underlying teams and operations teams towards the DevOps operating model.
The focus of this experience report is on the 4th part of the Apollo program.
3.3 Creating a change approach, by learning
Benefitting from the result of the Agile transformation, 45 Grids were a key focus point to start the creation of our approach. Also taking into account the fact that all Grids are unique, it was understood that we couldn’t come up with a clear and crisp approach the first time around. We needed to achieve a notion and maturity in our approach, in such a way that we felt comfortable to start and rely on the availability of expert staff.
The key point in the set-up was the focus to start on a specific date. Through various planning and dependency discussions between the streams in the program, no one would make a hard statement on when they were ready. And why should they? No start of the change was planned. In this case, it helped shape the change approach, but also aligning all dependencies, a lot to stick to a strict milestone to start. In our case, that was 1st of April 2019.
To support the start, we sketched an approach covering all aspects of the change (see next chapter) where not all gaps were filled. At least it was known and understood that clarity would be given in time, and by working with placeholders, we could evolve the content over time.
On top of this, what also helped was the original push to scale towards a support program: the already over 100 teams that needed to change their way of working towards DevOps. Venturing outside of our data centres, also meant moving away from a managed service on infrastructure, operations and service management. Suddenly the teams needed to do all of this by themselves. Our primary focus and planning, therefore, went towards guiding those teams that were already either in production on public cloud, required to support teams or planning to go to production on the public cloud. This also meant to look at key experts that would guide these teams through the transformation, providing operational rules and guidelines, but also preventing that not every team creates their own truth or invents a wheel of their own.
3.4 Engagement with Apps and Digital Innovation Grid
Multiple people from the Apollo program did the initial engagement with Apps & Digital Innovation Grid (ADI Grid). At the time of my (João’s) arrival, there were mixed feelings; on the one hand, a kick-off session was held by the ADI Grid leadership team. Inclusive, one of the IT Leads dressed as a rocket man. It created a feeling that from that moment on the journey would be a smooth ride. On the other hand, the time between the event and the first interactions with the Grid members led to a fade of the momentum created by the kick-off; plus, different people engaging with the Grid gave slightly different messages and raised some questions about the effectiveness of the program.
Also, the envisioned Apollo support team was not in place. The concept of the Apollo support team is to have different specialists from areas such as software development, CI/CD, operations, security, monitoring, architecture and team coaching. The intention is that together we can be an extension of the Grid, to help them move to the DevOps operating model. In reality, of an envisioned team with around 8-10 people, only three people were appointed: two specialists in software engineering practices (such as software development, testing, CI/CD) and myself as a transformation facilitator. At that point, and with previous steps made by different people according to the initial plans from the program, the situation was chaotic; communication paths were crossed, there was a mismatch in the expectations, and most important the energy and willingness of people within the ADI Grid were decreasing.
Within our small group, these questions arose: can we proceed under this uncertainty? Can we manage the liminality of the situation? Looking back at my time within ABN AMRO, I discovered that not everyone fully understood the purpose of Apollo. Looking at myself, if I don’t understand the why or purpose of some subject, how can I contribute to it? I don’t like to follow a crowd for the sake of following. I need to understand the purpose. Applying the same principle, we decided, with advice, to stop the approach that was planned by the Apollo program. The cadence of workshops and topics didn’t flow, and more importantly, we didn’t have the traction with the ADI Grid.
3.5 Learn, regroup and pivot
I have some experience swimming, and I can clearly remember learning how to swim in the sea, after a few years swimming in a pool. I took for granted what I learned in one context (swimming in a pool) and trying to apply in another (swimming in the sea). The first wave took me down! I will always remember the first wave. And I compare that experience with my first encounter with ADI Grid making their DevOps journey with the Apollo program.
Back then, when the first wave took me down, I just sat down on the beach and replayed the events through my head. How can I swim in the sea? I did precisely the same in this situation. I decided to push back the original cadence and planning of the Apollo program, to give space for the people within the ADI Grid to understand the purpose of Apollo. Although the idea started with me, it wasn’t made in isolation. In the end, DevOps is about collaboration, and it would be strange to develop a related idea in any other way. I presented the idea to several stakeholders: the colleagues from the Apollo support team, the ADI Grid leadership team, and to the Apollo program (in the person of Matthijs Dee).
The plan consisted of a simple approach: listen to people, capture their experiences and ideas. From the meaningful conversations, trust was created, and a connection was made. Trust started to grow, and after that, we could discuss solutions that allowed us to move forward. It was applied to multiple levels; from a process perspective, rather than go with the traditional push model, I proposed a pull model. As a program, we were there to help, and we were glad to be integrated into the ADI Grid. The pull model had the central idea of listening to people. I applied it to several levels: to the people working within the ADI Grid, to the ADI GRID leadership team, to the people with the Apollo support team, and to the Apollo program.
For one month I listened to people. Their vision of the program, their opinion on what DevOps means, their fears of change. It fundamentally changed my perception of my role. Different than originally planned that I would be the subject matter expert and would help the ADI Grid move from A to B, I had the opportunity to coach people at all levels, and at the same time contribute with the design of a transformation program. I was excited!
It led to the next insight: if DevOps is about collaboration, autonomy, and trust, I can facilitate the co-creation of a DevOps journey for the ADI Grid that can be feasible with the guidelines of the DevOps operating model and the constraints that ABN AMRO is obliged to. This insight pivoted my approach and the program’s approach.
3.6 Find the pain points and connecting people
As part of the new approach, the goal was to find pain points within the teams and help to fix them. To do this, the Apollo support team decided to split: two colleagues with software engineering expertise moved towards the teams, as an extension of the team; and I started to collect feedback and connect people between teams, program, and other Grids. The approach is known as mission command and was introduced in Lean Enterprise [Humble et al.]. I find this approach useful, given that we can operate in mission command style. Rather than having a top-down approach, from the Apollo program towards the Grids and teams, we can manage it in an objective-driven fashion.
As Michiel Sens described it [Sens]: “(…) the aim is to move the authority for decision-making to where the information is. Please note, this does not mean that the top level should not make any important company-wide decisions at all; it merely means that the top level should maintain focus on the “bigger picture” and find (and implement) ways to facilitate the organisation in achieving its objectives, where it is the organisation itself that takes care of the execution.
So the transition is objective-driven—meaning that teams commit to a set of objectives—and necessary activities on how to achieve these objectives are defined by the teams themselves. As such, teams are supported by leadership so they are sufficiently staffed and they receive an articulated set of base principles to follow.”
Our day-to-day as a support team started to be more an alignment and information sharing; we operated at different levels within ABN AMRO, but we shared the same goal: help the ADI Grid move to the DevOps operating model. Under this goal, we set-up smaller milestones, where we could make the path in small steps towards the goal.
At that point in time, our Apollo support team started to scale. ABN AMRO started to appoint colleagues to different roles. It was time to reteam: in the DevOps spirit, I suggested to work as a pair for mentoring and knowledge sharing, which was inspired by the Extreme Programming (XP) pairing technique [Beck et al.]. In this way, the colleagues that joined the team could be introduced smoothly; we didn’t need a formal introduction. The trade-off was that we needed to take the time to give the appropriate context to the recently joined colleagues. On the plus side, the colleagues could quickly contribute with their field expertise, given that a colleague with more context is their pair. As the Apollo support team, we continued to have our rituals, such as the weekly sync meetings, or the meetings with the different teams. We used the weekly sync meetings to track our progress in supporting the ADI Grid move to the DevOps operating model. We used the time to discuss the challenges, impediments and successes within the ADI Grid.
3.7 Our initial learnings
One of my (João) first learnings was the expectations of the ADI Grid and the reality at that point in time. During the discussions with the ADI Grid leadership team, it became clear that we had an expectations mismatch: facilitating the ADI Grid to move to the DevOps operating model and the Grid’s expectations about having a blueprint with the steps to implement that change.
It led to our first conversation about the expectations; starting as a consultant, and their (ADI Grid leadership team) job is to make the consultant redundant as fast as possible. In my opinion, it is crucial to keep this in mind, because the consultant is overhead; as such, I try to maintain an objective perspective, because I’m aware that the ADI Grid has a purpose of fulfilling, and, as a program, we are disrupting their flow.
This statement led to mixed feelings within the ADI Grid leadership team: on the one hand, I managed the expectations as soon as I could, which makes the intentions clear; on the other hand, I needed to start to manage the approach differently. Given the initial impact of my statement, people began to wonder, why am I here, if they are in the driver seat?
Looking back, one year gone by, it was the turning point for me. My intentions were clear, and I communicated that to the different stakeholders. Also, I showed that I’m here to help and not to impose myself. It was critical to the success of the approach, although back then, I knew that I needed to manage the uncertainty, but I didn’t quite know with which practices it could work.
What was very important to conclude (for Matthijs), is that looking at a lot of content even though it were placeholders and staring blindly at a moment in time to start, engagement is key. We didn’t spend ample time with the leadership team and, maybe, more importantly, hampering the explanation towards the operational teams.
Secondly, open communication needs to be set-up between the program and the department under change. You need to make sure that the feedback from the department is directly channelled to the correct solution party, like a platform or tooling team or process owner. Sometimes you have this organised, or a solution is foreseen and planned, and sometimes you just missed something, and you need to put it on someone’s backlog and prioritise it.
Thirdly, embracing DevOps is never the endgame. There is always a use case or driver required (delivery of new value-added, ambition to move to the cloud, etc.). In that sense, put on your helmet and prepare for change. Adopting all the learnings, by performing our change approach, whilst also creating another change approach to, for instance, incorporating a mass migration, is in the best interest of the company and reaching the targets. Make sure that the team that spent a lot of time detailing out the approach is able to kill their darlings and move on.
3.8 From the initial learnings to a joint approach
These initial learnings, both from the ADI Grid and the program level, led me (João) to pivot the approach. On the one hand, I had the freedom to tailor the approach towards the ADI Grid context; on the other hand, I needed to build momentum and gain traction inside the ADI Grid.
To tackle these challenges and continuously improve on the learnings, the ADI Grid leadership team and I started to have meetings to explore the context of the ADI Grid; during the exploration, the leadership team selected the relevant transformation topics from the Apollo program. The meetings set-ups were inspired by how African and American tribes make decisions [Braun et al.]; it is called meetings as campfires. I drove the meetings, where space is created and held to share the opinions and feelings about the decisions at the table. We form groups around these honest interactions, using emotional and rational processes. Those decisions affect mainly people and their careers. It cannot be taken lightly, and the meetings as campfires helped in the decision-making process.
I used some techniques and tools to manage the meetings; both to address the social bonding and the content. Each meeting had a similar structure: started with check-in and ended with a check-out, practices from the Lewis method of Deep Democracy [Deep Democracy]. To address the content, Liberating Structures [Liberating Structures] exercises, such as 1-2-4-All and Wise Crowds, in combination with visual collaboration tools such as Impact Mapping [Impact Mapping] or EventStorming [EventStorming] are my preferred solution, avoiding the typical meeting based on a presentation. It enabled the group to share knowledge, ideas, and concerns, rather than just receive information.
Taking this route has been fruitful for the group. From a management perspective, some of the topics weren’t relevant for the ADI Grid context, and we just skipped those. Focus the energy on the relevant topics, to transform the current status quo into high-performance teams. However, I quickly learned that although we embraced meetings as campfires, we had the meetings in closed rooms for a while. It didn’t help with the goal to gain traction inside of the ADI Grid, because the conversations did not flow to the whole staff. It is vital to have open and transparent communication so people can understand the rationale and help move on the chosen direction.
The way to balance this was to hang the brown paper with the expected initiatives and decision points on the entrance of the floor where the majority of the teams are located; and at the same time, have some of these meetings near the brown paper where anyone could participate, either by listening or joining.
Figure 1. Brown paper (point-in-time) with the expected initiatives and decision points
3.9 Why the feedback cycles are essential, and when do they fail
DevOps movement builds on top of the Agile values, principles and practices. From Agile, feedback cycles are essential, and as an industry, we try to make them as short as possible. It is not different when we are in a transformation program. A well-known feedback tool is the retrospective. I used retrospectives to look back, share what we experiment and learn, adapt, and decide on how to move forward.
As the Apollo support team, we started to have monthly retrospectives after four months of working together. Looking back, I feel that I should have provided the structure at the start to create psychological safety, where the Apollo support team could speak up freely. I was focused on getting the ADI Grid into the flow of change, and I didn’t pick up the signals and invest enough energy with the struggles that the Apollo support team members were facing. The weekly syncs were not enough. After having this realisation, and with the help of Robert, the team coach within our Apollo support team, we set-up retrospectives to create a safe space where people could speak their mind. One of the decisions was to have catered lunch, where the team could have a more relaxed retrospective. It worked. People opened up and started to speak their mind. We shared our concerns and challenges, but also the experiments and outcomes. We created a sense of a community, and I felt good about it.
ADI Grid has an inclusive, open, and transparent culture. The Grid already had the feedback cycles built-in into their rituals, ranging from daily stand-ups, to town-hall meetings and product announcements. The Grid (both the leadership team and development teams) invited the Apollo support team to their meetings. I felt welcomed when they invited the Apollo support team for those. The feedback flows both ways, and I could get a sense of the bigger picture. However, the Apollo program was only one of the topics of the meeting’s agenda, and unfortunately, we couldn’t go into detail. As part of my role, I coached the leadership team to go into depth about the feedback with people. I observed some tension in meetings and a mismatch between words and actions and picked up some weak signals about people’s concerns. My main goal was to help them to reinforce the positive behaviour, using the town-hall meetings for that; and for the less positive behaviour that didn’t help with their culture, to use a 1-to-1 setting, where people value safety.
At the time, I missed some feedback inside of the ADI Grid. To recap, it is a Grid with around 180 people, working in five different business propositions; the tempo differs among them, and although there was feedback towards the DevOps journey, there also was a lack of consistent feedback loop inside of the ADI Grid. Given that, I proposed to get representatives of the different business propositions to start a group to share experiences, where we could learn from each other. The group should have people from the five different business propositions, representing the teams; we should also have a variety in the roles, given that diversity gives more insights. The group also included the leadership team because I intended to leave a structure that is lightweight and manageable. The group only had one feedback session and looking back (why it was only one session), I have some learnings: (1) the dynamics of the different teams vary. It is hard to get time in their busy agendas; (2) some people didn’t realise how the investment of time could payback since they were already advanced in their progress towards working in a DevOps fashion; and (3) with the end state in mind, making myself redundant, I told them that I would not include myself in this group. Looking back, this was not a right decision; although I intended to create space for the group to speak up, the fact that I was not there as a facilitator to manage the cadence of the feedback meetings, led to this initiative dying. I feel that I missed an opportunity to increase feedback. From a process perspective, these meetings need a dedicated facilitator, focusing on the interactions of the group. On the positive side, I observed that people, in one way or the other, found their way within the ADI Grid. I think that the fact that I (and for the matter of fact, the Apollo support team), sat down near the blocks helped gain and provide feedback. I was always willing to find time for a coffee and a chat, to discover how people and teams were doing.
Last but not least, based on my career experience, I set-up feedback sessions between the leadership team and the Apollo program, represented by key program managers. For those sessions, I took a facilitator role, where I created and held the space for people to share their thoughts. As a way to facilitate the meetings, I used post-it’s to capture the ideas, and at the same time, the topics that we parked. It is crucial to visualise (and agree on) relevant topics, but we don’t have the time to discuss (for different reasons). This visualisation tool is known as a parking lot. The parking lot helped me to facilitate the meetings, but at the same time to close the feedback loop in a structured way. Last but not least, having the parking lot concept, allows the group to feel that they are heard and allows them to prioritise the next topics to address. I held these meetings for over a quarter of the year, on a monthly basis, and it helped the program to identify the gaps since ADI Grid was the first Grid undergoing this DevOps journey.
3.10 How did I use shadowing to help scaling the Apollo program
As described at the beginning of this experience report, ABN AMRO has the ambition to move the operating model to a DevOps way of working. The bank started the program with the ADI Grid, to get boots on the ground, validating some of the design decisions. In an agile world, it is to inspect and adapt. But during my journey with the ADI Grid, the Apollo program started to scale and to achieve the goal of moving the bank’s current operating model to the new DevOps operating model. It translated into the scope of the Apollo program increasing, with more Grids under transformation. More people were hired to fulfil a role similar to mine. One of the discussions was about the way to scale. We had the feeling that we didn’t want a formal structure of reporting, which will give us yet another meeting. At the same time, I have knowledge that is valuable to the transformation facilitator community to use to their benefit, mainly to speed up into their new role.
With this challenge at hand, I started to apply the shadowing technique. Shadowing technique is well known for people that are trying to learn a new language. Using the same principle but applied to learn the ins and outs of a new role. For me, this was a great way to introduce people to the topic, and the daily routines; showing how I do my job, and what type of challenges that they can face. From my previous experiences, both from being onboarded to onboard someone, we used traditional methods: synchronous presentations about the different materials and ways of working to formal meetings to get to know people. The conventional methods are time-consuming, and somehow, intrusive. The workflow is broken, and in my perception, it feels like having sand in cogwheels.
After onboarding a few people, and using this time to reflect on, I believe that it is more effective, that people can see the day-to-day tasks, and at the same time have contact with the topics and materials. On top of that, I also hosted Ask Me Anything sessions, where people who were shadowing me could ask whatever they had on their minds. This requires me to be open and transparent, sharing my experiences. Looking back, I recommend using the shadowing technique as a way to help people to get acquainted with the organisation and the content. However, it requires courage, honesty, and transparency from the person being shadowed, and that is my main insight.
4. What We Learned
For me (João), I learned and changed personally. My main learning point was the ability to convey the same message across time. Explaining the purpose of Apollo taught me that people need someone on their side, to walk with them on a journey. At the same time, I learned how to navigate in an enterprise during a transformation. Reflecting on the past year, I can understand some of the behaviour that I witnessed and relate it to an organisation that is adopting a new way of working at scale. Using visual collaboration tools to manage the liminality was key to the success of the transformation at Apps & Digital Innovation Grid. Today I have a different resilience, which allows me to look at challenges in a different way. My leadership philosophy starts with my values; and it is inspired by XP [Beck et al.] values, namely honesty, transparency, and courage. Today I can say that courage is foundational because without it, I couldn’t challenge the status quo. And I reinforced a value: empathy. Being able to relate to people’s journeys, listening to understand rather than reply is a practice that I will keep using every day.
I (Matthijs) learned again that any complex problem has a fitting solution. It doesn’t need to be all known at the same time, but having proper milestones is key. If you see multiple people and departments struggling with this, dare to provide guidance. Also, if it isn’t something scientifically sound—you can steer along the way! Next to that, keep the focus on all levels in the organisation. I have been part of many transformations that only lived on paper. My mission was to make sure also on team level the transformation would stick. Only then you are able to be sure. Lastly, I would like to point out the fact that being agile also can lead to a lot of disappointment. Killing your darlings is something that you need to cope with because in every change you’re directly impacting blood, sweat and tears of, in my case, the work of a lot of team members.
5. Acknowledgements
João: I want to start by saying a big thank you to my wife and our daughter! Your patience and encouragement mean the world to me. For Ellis de Haan, Kenny Baas-Schwegler and Paul de Raaij, you pushed the quality of the report with your reviews. Also, to my colleagues at Xebia, with all the sparring conversations that we had, which helped me shape my thought process.
Matthijs: I would very much like to thank everyone who made the time to read through João and my thoughts. A very interesting process indeed. My gratitude goes out to João, who convinced me to start sharing my story so far. A small step for mankind, but a huge leap for me personally. Thanks Sir! And of course all the fantastic people at ABN AMRO, whom without I would have never gotten the opportunities to learn and grow in the last 13 or so years.
Last but not least, to Jutta Eckstein, our shepherd. Without your guidance, questions and amendments, we couldn’t do this report! Thanks!
REFERENCES
[Humble et al.] Jez Humble, Joanne Molesky and Barry O’Reilly, 2015. Lean Enterprise: How High Performance Organisations Innovate at Scale. O’Reilly.
[Sens] Michiel Sens, 2020. DevOps for Managers – A Practical Guide for Becoming a High-Performance Organization. Xebia Nederland BV.
[Beck et al.] Kent Beck with Cynthia Andres, 2004. Extreme Programming Explained – Embrace Change (2nd edition). Addison-Wesley.
[Braun et al.] Danielle Braun and Jitske Kramer, 2018. The Corporate Tribe. Routledge.
[Deep Democracy] Deep Democracy. 2020. [ONLINE] Available at: https://www.deepdemocracy.nl/. [Accessed 31st March 2020].
[Liberating Structures] Liberating Structures. 2020. [ONLINE] Available at: http://www.liberatingstructures.com/. [Accessed 31st March 2020].
[Impact Mapping] Impact Mapping. 2020. [ONLINE] Available at: https://www.impactmapping.org/. [Accessed 31st March 2020].
[EventStorming] EventStorming. 2020. [ONLINE] Available at: https://www.eventstorming.com/. [Accessed 31st March 2020].
