One Agile Way of Working model

One Agile Way of Working
Tribe / Squad approach: how IT and business

work together in delivery
Document version control
Version Date Author | Reviewer Status
0.9 June 2016 Approved by Project Management Framework –

P.H.M. Jacobs ‘the model that works’ (DB NL only)
to close ECB CAS item
1.0 Beta October 2016 Author: Beta version

Unify IT, contact person Ben
Vos Ben.Vos@ing.nl
In collaboration with:
Jael Schuyer, David Bogaerts,
Ruben Jannink, Leonoor
Koomen, Peter Brouwer,
Dennis Wit, Gijsbert Boon,
Werner Vaarwerk, Gijs
Valbracht and Marcel Mertens
1.0 December 2016 Author: Unify IT Including processed feedback on

the Beta version
In collaboration with:
The Global Agile Community &
Jael Schuyer, David Bogaerts,
Ruben Jannink, Peter Brouwer,
Dennis Wit, Henk Venema,
Francesco Sferlazza and
Gijsbert Boon
1.1(1) April 2017 Author: Unify IT Including processed feedback on

(June 2017) the 1.0 version, revised portfolio
Additional collaboration with: management (chapter 3), IT Health,
GTO: Tapio Schrey Distributed Tribes / Squads
BE: Dimitri Leemans, Anne
Marie Zeghers, Yves Seynaeve Small update to version 1.11 to
COO IT Risk: Debra de Jong, align with One Agile Way of
Jan Slagt Working framework
1.2 August 2017 Author: Unify IT Including processed feedback on

the 1.1 version, improved
Additional collaboration with: distributed Tribes / Squads
Paul Wolhoff, Martijn Knaven, principles, good practice ‘Multiple
Jarl Meijer, Eelco Stoelinga Squad IT assets’
1.3 December 2017 Author: Unify IT Including processed feedback on

the 1.2 version, shortened setting
Additional collaboration with: the scene, revised portfolio
Jeroen Prins, Annemiek management (chap. 3), product /
Quirijns, Henk Coppens, Paul service approach, Kanban,
Wolhoff Temporary Delivery Alliance
One Agile Way of Working • Delivery • Reference model • Version 1.3 • December 2017 2
Preface
The context of this document

This document is part of a bigger One Agile Way of Working (OAWoW) framework which starts with our
principles and believes (why do we need OAWoW), written down in ‘ING: One Agile Way of Working’
(please note that internal network access is required).
The scope of this document is to support the OAWoW specifically for delivery, regardless whether
they are purely business based, IT based (IT enabling Tribes) or Tribes where business and IT closely
work together in delivery. How it relates to the other documents in the framework is plotted in the
following picture:
The content of this document

This document describes a working model (we call it a reference model) for delivery on how we
translate ING’s Vision and Strategy into business value, how we manage, prioritise, share and improve
the work to be done for that, how we organize ourselves for optimal collaboration between both
business and IT as well as within IT and the standardized tooling (IT4IT) that supports / enables the
OAWoW. The reference model provides the following elements:
 the definition and scope of the OAWoW model;
 the binding principles (Agile, Lean, Continuous Delivery and BusDevOps);
 the way we work regarding change, maintenance and support;
 the preferred organisation and its roles / responsibilities;
 the relationship with the IT processes.
It is based on the experience, knowledge and current good practices across IT at ING and designed in
collaboration with the Global Agile Community.
How to use this document

The model describes the “what” in an instrumental way: the flow of bringing work to teams, the roles,
responsibilities, events, and artefacts in order to:
provide a common taxonomy and understanding on how the Business and IT work in
collaboration, that should be used unambiguously across and between all different entities
within ING. From this perspective it must be seen as a prescription to enable us working together.
And as a result of that it must be implemented as such.
Nevertheless, as it is based on several good practices in large and complex ING entities, the
implementation should never be done dogmatically. It should always be implemented in a way that it
contributes to our objectives.
Index
Setting the scene 5

Introduction 5
Background 5
Market Standards 5
How to read this document? 6
One Agile Way of Working for delivery 7

Fundamentals 7
The workflow 8
Organisation and roles view 9
Distributed Tribes / Squads in a Global Organisation 14
IT Health 16
IT Processes 17
From ING’s Vision and Strategy to Themes 18

Flow 18
Events 20
Artefacts 22
From Themes to Epics 23

Flow 23
Events 25
Artefacts 26
From Epics to Features 29

Flow 29
Events 31
Artefacts 31
From Features to Stories 32

Flow 32
Events 34
Artefacts 35
From Stories to Value 37

Flow 37
Events 39
Artefacts 39
Setting the scene
Introduction
In our journey towards OAWoW for delivery, ING is not starting from scratch. In the recent past, several
ING entities already implemented some variance of working Agile, which were causing challenges in
global collaboration. This chapter provides a summary of these challenges as well as market standards
that are underpinning the OAWoW.
Background
Until 2010, project and program management was based on the waterfall model and Prince II, and was
applied at a large scale as a project and program management framework. Then since 2010, different
entities at ING adopted a new method for software development based on Agile. Resulting in the
following:
 Different stages of transitioning towards Enterprise Agility
 Adoption of multiple flavours of Agile and ways of working
 Initiatives that require multiple teams to collaborate face persevering unaligned autonomy
However, for global collaboration a common ground regarding the way we work Agile is needed. Due
to this, the initiative of creating OAWoW and implementing it in a centralized way was introduced.
An comprehensive background including; (1) the history describing ING’s shift from waterfall and Prince
II to Agile@ING and (2) the detailed key challenges is provided in Appendix A.
Market Standards
The OAWoW for delivery is founded on multiple Market Standards such as the Agile Manifesto, DevOps,
Lean and Continuous Delivery. In this paragraph we list these sources with a brief explanation. We
provide a reference for more detailed information and highlight the key principles for this reference
model.
Agile Agile is all about early delivery of business value. This is done by working incremental
and iteratively in self-organizing stable teams, with fast feedback, fast learning and
continuous improvement built into the way of working.
www.agilemanifesto.org
We work and behave according to the Agile Manifesto and the 12 Agile Principles
as they are valid on all levels of our work
DevOps The practice of IT operations engineers and IT development engineers collaborating in
one team for the entire service lifecycle, including design, development, test, change
and production configuration, monitoring and support.
www.wikipedia.org
We strive for reaching Enterprise Agility which goes beyond the principle of DevOps
We are organised in autonomous “BusDevOps” (or BizDevOps) teams where
Business and IT collaborate on delivering business value and are responsible for
E2E delivery of and management of business applications
Lean Lean principles are at the core of Agile and Scrum. They include: identify value and
reduce waste, map the value stream, create flow, establish pull and seek perfection.
www.lean.org
OAWoW is also based on principles from Lean; that quality is non-negotiable and is
built in through short feedback loops, that we never deliberately add to technical
debt and that we continuously look for ways to improve our WoW
Continuous Continuous Delivery is the ability to get changes of all types—including new features,
Delivery configuration changes, bug fixes and experiments—into production, or into the hands
of users, safely and quickly in a sustainable way. It usually results in automating the
build, test and deployment of software.
www.continuousdelivery.com
Continuous Delivery Pipeline provides central tooling and generic deployment

automation. This enables global code sharing and did already some of the heavy
lifting regarding deployment automation in a generic way, re-usable for everyone
In the remainder of this document we will not explain Agile, but rather explain how we have
incorporated large parts of these concepts into our reference model for OAWoW. For more information
on each of these concepts please also refer to Appendix B.
How to read this document?
This document provides the reference model for the OAWoW for delivery. It has been structured
according to a layered approach (based on breakdown of work and cascading down principle of the
OAWoW) to describe how ING’s Vision and Strategy leads to customer value along prioritised Themes,
Epics, Features and Stories. It is a model referring to several other documents that are explaining
concepts and good practices of the OAWoW in more detail.
The second chapter of this document provides the general basics of the OAWoW. For example, it
explains how ING’s Vision and Strategy can be translated into different working units and the preferred
organisation and its roles.
Due to the layered approach of the OAWoW, chapters three and higher are describing a specific part of
the OAWoW with its related events and artefacts. For example, the chapter describing ‘From Stories to
Value’ explains how teams work at daily basis (with daily stand-ups) to deliver Stories that are
contributing to ING’s Vision and Strategy.
The goal was to describe the model in the most generic way. Regardless whether you are in a purely
business environment or heavily involved in IT: everybody should in the end be able to work with it.
Nevertheless there is specific content which is mainly relevant for involvement in or collaboration with
IT. This content is marked with a grey block and can be skipped by readers who are not interested in
this IT based content.
One Agile Way of Working for delivery
In this chapter, we introduce the fundamentals of the OAWoW within ING. We describe how work (i.e.
Themes, Epics, Features and Stories) is initiated. The global organisation that is needed to support the
OAWoW within the delivery organisation is explained. Next, how to keep a ‘healthy’ run of the IT
landscape is described. Finally, the impact on being and proving to be ‘in control’ by processes is
explained.
Fundamentals
We strongly believe that having a unified WoW all over the (ING) world is crucial to accelerate in our
service delivery and to facilitate global collaboration. To get the best understanding what this way of
working is all about, we first want to
zoom in on two key principles of an
Agile way of working: aligned
autonomy and iterative & incremental
approach.
Autonomy is strived for by minimising

dependencies and enabling teams to
realise output quickly, stimulate
creativity and empower teams to
define ‘how’ to deliver value and come
up with new insights and innovative
ideas.
Alignment is key to ensure that Spotify Engineering Culture, Henrik Kniberg

Source: https://spotifylabscom.files.wordpress.com/2014/03/spotify-
teams’ successes contribute to the
engineering-culture-part1.jpeg
Vision and Strategy of ING (opposed to
doing whatever they think is best,
which could be the case in an autonomous situation). Alignment is therefore key to ensure a certain
degree of autonomy. Alignment is ensured by creating transparency on who is doing what (e.g.
preventing double work) and learn from each other (e.g. realising good practice standardisation).
Teams deliver value through regular

cadences of work, known as Sprints or
iterations. A Sprint is a time-boxed event
of typically two weeks without
intermediate gaps. By focusing on the
repetition of abbreviated work cycles as
well as the functional product they yield,
Agile methodology is described as
“iterative” and “incremental.”
An incremental process is one in which a

product is built and delivered in pieces. It
can start as a simple experiment /
prototype in which you try to prove whether What is Agile?, Henrik Kniberg
the proposed end product will deliver Source: http://blog.crisp.se/wp-
content/uploads/2013/08/20130820-What-is-Agile.pdf
business value. With a positive result, the
actual product will be delivered in pieces, or
increments, representing a complete subset of functionality, which is ready to go to production for a
closed user group a.k.a. Minimum Viable Product (MVP).
Teams use these MVPs to collect the maximum amount
of validated feedback from customers with the least
effort.
An iterative process makes progress through successive

refinement. A team takes the first cut at a product,
knowing it is incomplete or weak in some areas. The
team then iteratively refines those areas until the Minimum Viable Products, Henrik Kniberg
product is satisfactory. With each iteration, the product Source: http://blog.crisp.se/author/
is improved through the addition of functional and / or henrikkniberg
non-functional value.
The workflow
In the end ING’s Vision and Strategy lead to a Portfolio of Themes which connect the dots between
Strategy and execution. Hence, a Theme represents an area that supports the strategic vision. They
can be either derived from a strategic transformation program or have a more ambition / guidance
character (we want to grow X, speed up Y, lower Z). Themes are
typically representing one to five year(s) and should always be judged
on the added value (i.e. (impact on) (part of) a product or service for an
end-consumer). This value is usually translated in so called Objectives
and Key Results (OKRs). They help to be ambitious and transparent,
force to think, improve communication, provide focus and enable
measurement. This OKR methodology distinguishes between Objectives
which are qualitative and aspirational goals; and Key Results which are
quantitative and SMART indicators of the extent to which the Objectives
are realised (see Appendix C).
A Theme is broken down in multiple Epics: large scale bank deliverables

that are delivered in one to four quarters based on the OKRs. In the
realisation, multiple teams are orchestrated, managing multiple
stakeholders with their change requirements.
An Epic can be broken down in one or more Features. A Feature reflects

part of the Epic’s value (both functional and non-functional) for a
stakeholder that could be delivered within multiple (typically one to six)
Sprints. The shorter the better, as only in complex situations longer
Features should exist. The value, impact on the current situation and
acceptance criteria should be clear.
Epics or Features have to be refined to Story level. Stories usually consist of how a team will deliver
the value and are explicitly defined by teams themselves. They have to be small enough to be picked
up and delivered within one Sprint.
Stories can be cut up into Tasks, carried out either jointly or individually, but always within one day of a
Sprint. Eventually, Story execution is about development, maintenance and support of our products
and services.
The workflow as described above is the top-down cascade of translating ING’s Strategy and Vision into
customer value. Bottom–up on each and every level there is a constant flow of feedback loops to
share new ideas or insights to suggest new or adjustments to Features / Epics bottom-up and even
adjust the value-proposition. This top-down and bottom-up workflow will be described more in detail in
chapters three to seven.
Although it is described as if all the work is directly related to value-contribution, there should be room
for innovation. In the end, innovations can lead to major improvements on the (delivery of the) value
and as a result of that innovations should be embraced. How this could be implemented in our WoW
will be described in a future version of the reference model.
Organisation and roles view
In order to support our ability to respond on rapidly changing market demands

the OAWoW requires an organisation in which individuals and teams work
cross-border close together with direct communication, less handovers and / or
less tollgates and own E2E delivery of products or services and as a result of
that of business value (see for a more detailed explanation on this ‘Product vs.
Project’).
We looked at other organisations that have been successful in adopting an

Agile WoW such as Spotify, Netflix and Google. As a result, at ING we decided to
organize ourselves into Tribes, Chapters and Squads.
We use the following motto to reach aligned autonomy:
“Squad over I, Tribe over Squad, Entity over Tribe, Company over Entity,
Customer over Company”
An entity, being a country or domain(s) (e.g. DiBa, Bank Infra, etc.) is organised
in Tribes, in a way that it best supports the execution of Epics. The Tribe consists
of multiple Squads and Chapters, which are composed in a way to best execute
Features / Stories. A key objective of this type of organisation is to collaborate
on a global scale, being a global Digital Bank.
This paragraph provides a description of the Tribes / Squads organisation and its roles (see Appendix D
for the corresponding reporting lines). For some of the engineering roles, Global Engineering Profiles
are created to ensure a standardised approach towards assessing and calibrating the capabilities of
our engineers, which can be found at the Global Engineering Profiles platform.
2.3.1 Squad
Squads are high performing teams consisting of 7 ± 2 persons who provide the execution power to the
OAWoW. High performing teams continuously improve their primary working processes. They:
 are BusDevOps (or a subset of these disciplines) and
cross-functional;
 can be Feature-oriented, component oriented, or
commercially oriented, depending on their purpose;
 aim to reduce handovers / tollgates as much as possible;
 are self-organising, as they choose how best to
accomplish their work, rather than being directed by others outside the Squad;
 use Scrum or Kanban as Agile methodologies to support optimising flexibility, creativity and
productivity. In practice, Scrum is suitable for almost all Squads. However, there are
circumstances in which working with a fixed Sprint length is not feasible. This can be the case
when it is impossible to predict when work needs to start, or when it is impossible (not hard,
but impossible) to predict how long work will take to finish. In these circumstances, a Kanban
approach can be helpful.
Squads deliver products iteratively and incrementally, maximising opportunities for fast feedback.
Prerequisite of such an incremental delivery of a product is to ensure that a potentially useful version
of a working product is always available. In other words, Squads have the end-to-end responsibility
(incl. risk management), to deliver a specific product and corresponding value.
The composition of a Squad depends on the expertise that is required to deliver on the Squad’s
purpose. In most Squads, the required expertise remains stable over longer periods of time, allowing
for a stable Squad composition of time. Below, find a list of roles that are often part of Squads which
are organized in BusDevOps context.
Roles at Squad level

Product Owner (PO) is a role that is held by one of the Squad’s members, on top of his or her
responsibilities as e.g. Customer Journey Expert or as an engineer. The Product Owner owns and shares
the product / IT asset vision and:
 maximises business value through ordering and prioritization of the Product Backlog;
 is responsible for the ‘what’ in a Squad, hence ensures that functional and non-functional
requirements are addressed for all stakeholders. The non-functional requirements include but
are not limited to: security, resilience, performance, contractual, legal and compliance
requirements and obligations;
 is for his / her span of control a delegated asset owner, risk manager, and in case of a non-
generic IT asset, data owner;
 can occasionally be the PO of more than one Squads, for example in case of a big IT asset. See
good practice document of multiple Squad IT assets (please note that internal network access
is required).
(IT) Development Engineers deliver business value across the entire end-to-end application chain in
their Squad. The Development Engineer understands the total stack and contributes to all activities on
the Sprint / Product Backlog.
(IT) Operations Engineers will actively run, monitor, manage and study application(s) in the scope of
the Squad, incl. deployment management.
The Scrum Master’s role is derived from the original role of Scrum Master as described in the
Sutherland’s Scrum Guide. However, the context and guiding principles of the OAWoW are broader. The
Scrum Master:
 ensures that the Scrum events in the context of other OAWoW events are understood and
engrained within the Squad;
 ensuring that the Squad adheres to the guiding principles of the One Way of Working, its
practices, and rules.
As stated before the role of Scrum Master can be rotating amongst the Squad members or even
distributed over the Squad members. This is usually the case in a very mature Squad. In less mature
Squads, the role is usually picked up by one of the Squad members.
The Customer Journey Expert:

 combines marketing, product management and / or business expertise;
 will mainly take the role of an end-consumer representative;
 ensures that the end-consumers’ experience is recognised by the Squad;
 is often able to approve the change and will, in case of an existing product, also takes care of
the further development of a product by initiating new Epics, Features and Stories;
 could take the role of the PO.
Optional Squad roles (not exhaustive):
The User Experience (UX) Expert combines marketing and user interface design expertise. He / she is
creates wireframes, mock-ups and simple prototypes and recommend improvements to applications
based on user feedback.
The Data Analyst combines marketing and data management expertise. He / she is responsible for
data analysis / research and for translating both internal and external data into valuable insights for
other members of the Squad.
The Data Scientist combines IT and data management expertise. He / she develops algorithms to
apply to external and internal data to predict customer needs and / or developments in markets,
industries and the wider financial landscape.
2.3.2 Tribe
A Tribe is a collection of Squads with a Tribe Lead, organised around a

relatively stable purpose (product or service) for at least two to three
years. This means that Squads within a Tribe are collaboratively working
on a joint problem or working on a shared topic. The Tribe enables and
supports Squads in achieving their goals. Within a Tribe, different insights
are shared (content wise and on the Way of Working) in order to come up
with good practices.
Roles at Tribe level

The Tribe Lead has overall ownership of the Tribe and could be supported
by the IT Area Leads, (C)POs and Chapter Leads to the following activities:
 establish a clear Tribe purpose and vision;
 set priorities within the Tribe;
 ensure optimal staffing within the given budget;
 take the asset and if applicable data ownership, as he / she guarantees the functionality and
quality of all (changes to) applications and related data;
 take ownership of risk and privacy compliancy, mitigation of business and operational risks;
 define test and deployment strategy of the Tribe.
The Central Product Owner (CPO) maintains contact with external stakeholders of the Tribe and takes
care of alignment within the Tribe. The CPO coordinates PO activities and consumer demands. The
implementation of the CPO role depends on the complexity, resulting in two situations:
1. In a straightforward situation (with many aligned stakeholders within the Tribe), the Tribe Lead
takes the role of CPO.
2. In a complex situation (with many unaligned stakeholders within the Tribe), the Tribe Lead
appoints (a) separate CPO(s).
In Tribes with a substantial IT involvement (more than 4 / 5 IT Chapters) the Tribe Lead is assisted by an
IT Area Lead. In collaboration with the Tribe Lead and (C)POs, the IT Area Lead:
 helps the Tribe Lead to define the Tribe’s IT direction;
 is the leader of the IT Chapter Leads and as a result of that, leads the development and
maturity of IT professionals;
 has the accountability of the IT Custodian at Tribe level (all IT assets of the Tribe);
 is accountable for IT continuity and non-functional requirements compliance on behalf of the
Tribe Lead.
The Agile Coach is assigned to a Tribe from a Center of Expertise, to be able to act as a ‘Tribe-
independent consultant’. The number of Agile Coaches within a Tribe depends on the Agile maturity of
a Tribe. At the starting-phase, one Agile Coach per three Squads is imaginable. He / she creates a high-
performing Tribe by challenging, coaching and inspiring Squads and their environment in terms of
content, culture and process based on the OAWoW.
2.3.3 Chapter
A Chapter is the ‘hierarchical’ line of Squad members, as personal development and craftsmanship is
organised. They are formal “groups” of 8-10 people with the same
job-role / expertise deciding on how things need to be done (often
within a Tribe), regarding their area of expertise.
Role at Chapter level

The Chapter Lead’s role is twofold, he / she:
 (foremost) performs content tasks, which can, depending
on the necessity, vary from coding up to contract
management in case of vendor software;
 is the hierarchical manager of the members of a Chapter;
o plans/coaches/assesses and professionalises the
Chapter members;
o ensures the Chapter members have appropriate competencies and skills by continuous
improvement of their skills and the area of expertise as a whole;
o determines the way of working in his Chapter and implements the use of standards for
the area of expertise together with the Chapter members.
2.3.4 Center of Expertise (optional)
Centers of Expertise (CoEs) are organizational units within ING that are composed of individuals with
specialized, often scarce, expertise that cannot be fully distributed to the Tribes. A CoE can
(temporarily) assign specific expertise to (local) Entity, Tribes or Squads.
Roles at Center of Expertise level

CoEs are steered by a Center of Expertise Lead, he / she:
 steers on the “how”;
 can report to a Tribe Lead or (local) Leadership.
Members of a Center of Expertise,

 are executing specialized tasks as temporary members of Squads to enable their E2E delivery;
 are allocated by the Center of Expertise Lead;
 may be allocated to support in multiple Squads in parallel.
2.3.5 Community (optional)
Whenever there are multiple people with the same interests and passion (e.g. technology, services /
products, etc.), they have the tendency to discuss topics within this shared interest area. An excellent
mechanism for that is setting up a community, by providing them a platform where they can get or
push information, moderated by volunteers who will streamline the information exchange along the
‘house rules’. Within these communities; people can exchange experiences, ask help, discuss latest
market developments, etc. They are free for everybody to join and to contribute to.
Whenever setting up or transforming an entity to the OAWoW it, besides the organisational design, is
good to also have an overview on what communities could contribute to your entities’ Tribes / Squads
Way of Working. Although a sustainable community is not pushed by management, but rather is
driven by the people with the shared interest, management can support this strongly by facilitating
this via granting investments needed to drive the community (by providing tooling, time, etc.)
2.3.6 Guild (optional)
A Guild is a group of super experts / goeroes within a community, which can be consulted whenever a
decision has to be made in their particular area of expertise (regarding standards and guidelines, new
developments to be followed or further investigated, etc.). For instance, Chapter (Lead) members from
various Tribes or countries with a common expertise or interest can set up a Guild (e.g. not installed by
management). The Guild members preferably meet on a regular basis to discuss the latest
developments of their expertise with respect to usability and feasibility within ING. Although Guilds are
part of communities, they should have a more formal and institutional character and be accepted /
seen as a relevant stakeholder.
2.3.7 Additional roles
Next, to the roles within the Squads, Tribes and Chapters, there are additional roles depending on the
composition of the Tribe and the complexity of the total organisation. Some of these roles:
The enterprise architecture is documented in Reference Architectures and Architecture cookbooks that
are shared in the organisation. These emerge and evolve over time. For a further deep dive in the
Architectural process, please read the Enterprise Architecture TOM (please note that internal network
access is required). An Enterprise Architect:
 draws up the cross-domain long-term vision and business & IT-roadmap based on the market,
industry trends, business strategy, feedback and observations from the Tribes;
 assesses Themes on their impact and alignment with the long-term architectural roadmap. In
this assessment, they should take into account the different points of architectural view, like
process, application, information, tooling & infra architecture.
Within the guidance given by the Enterprise Architect, the Domain Architect:
 evolves the architecture in a Domain roadmap with attention on the demarcation between
building blocks and performance of the value chain;
 oversees IT dependencies within his / her Domain;
 advises Feature Engineers and / or Squads with the planning and delivery of Epics and
Features, compliant with his / her roadmap.
A local Portfolio manager represents an entity’s Tribes in the global QBR process, he / she usually is:
 the linking pin between Road managers and Tribe leads;
 taking care of commitments towards Transformation Programs;
 providing the delta in case of over demand;
 facilitating the discussions on how to close the gap.
A Road manager facilitates and coordinates (a) Theme(s) executed via a roadmap as part of a
program approach (see chapter 3). He/she acts on various levels:
Expert level:
 is accountable for the execution of big, complex, critical programs consisting of more Themes;
 is assisted by and responsible for several Road managers;
 is the counterpart for the MBB;
Competent level:
 supports the expert Road manager or is solely accountable for the execution of a less complex
and / or critical program;
 creates the roadmap of a Theme and its Epics;
 coordinates and facilitates the execution between Squads (incl. release management) of the
relevant Tribes;
 takes care of all adjacent activities, like commercial rollout, regulatory / risk compliance, etc.
 sets up the Temporary Delivery Alliance.
For Epics within a complex IT landscape, the Feature Engineer:

 collaborates with the POs (and Squads) to translate Epics into Features and Stories;
 decomposes, coordinates and delivers these Features together with the Squads within the
Tribe;
 can be placed inside Squads, but can also operate at Tribe level.
Distributed Tribes / Squads in a Global Organisation
In the previous paragraph, a generic Tribe / Squad organisation model is drawn. In a global acting
organisation, where we strive for maximum collaboration and effective (re)use of capacity, Tribes and
even Squads will be composed of people from all over the world. In these so-called ‘distributed Tribes /
Squads’, the same roles and responsibilities, as well as WoW, ITSM processes and events (see upcoming
chapters) exist. In order to collaborate with people all over the world, we need good and reliable
working technology for virtual collaboration (e.g. Skype, Spark!).
Some basic principles need extra attention with respect to these distributed situations:
A distributed Tribe should…
Be distributed in up to three locations – Tribes are concentrated in up to three1 locations each.
Share Tribe status information over all locations – Tribe status information should be duplicated
at all locations to ensure involvement and prevent ‘us’ versus ‘them’.
Strive for a balanced level of maturity in craftsmanship - A Tribe has one shared roadmap, as all
locations should be balanced in their level of maturity in craftsmanship. Hence, together they
focus on a common dimension (e.g. CDaaS, Scrum / Kanban or Snow). Which means, that even
when the maturity of both locations of the Tribe is spread out on altered dimensions, there is
one shared focus for the total Tribe.
And distributed Tribes and Squads should…
Have one local governance line - The local office is the professional home for engineers, who
report hierarchically to their local organizations through Chapter Leads. Also Squad members
of a distributed Tribe have one local hierarchical line in the organization only.
Be organised around one purpose and goal – Squads are organised around a common purpose
and goal. The Squads working on a joint overarching purpose and goal are grouped in a Tribe.
1 Based on organization design principles of ING
In a distributed situation, all locations of the Tribe / Squad are organised around the same
purpose and goal.
Ensure distance is not troubling transparency, alignment or interaction – All informal and formal
events should be done with whoever is needed at Tribe or Squad level of all locations, meaning
one team, one process, same events.
Work from one backlog – One Product Backlog composed and prioritized by one (C)PO. For
example, closing specific CAS items raised at one of the locations is a joined effort for all
locations. Regardless whether the Squad situation is: (1) small asset developed / maintained by
one distributed Squad up to or (2) bigger asset developed / maintained by multiple Squads
across the globe.
And for distributed Squads this means…
Squads are split over maximum two locations - Squads are split over maximum two2 locations.
Minimum of three colleagues per country - The optimal Squad size is considered to be 7 ± 2
persons. This total amount should be respected in a distributed situation, preferably equally
distributed (except for the PO) and minimum of three colleagues per country, to ensure all
locations are involved. For example, a Squad out of eight persons that is distributed over two
locations (six and two) can decide with the six persons at one location to do X (and becomes
dominant), while the other two colleagues were not involved or forgotten to inform.
Defined ‘Squad focus time’ of at least three hours per day - As we want the Squads to adhere to
the Scrum / Kanban events and collaborate / interact with each other on daily basis, there
should be enough ‘Squad focus time’. This means, when working with different time zones, the
different locations of the Squad have a common responsibility to schedule at least three3 hours
of overlapping working hours per day for direct communication. During ‘Squad focus time’,
Squads are available for each other and do not schedule any ‘local’ events.
Staff Squad collectively - When there are changes needed in the composition of the Squad, all
Squad locations should be equally involved. As it should not come as a surprise for one location
of the Squad when the other location changes in composition.
Exchange of colleagues is a common practice - As distributed Squads are working from multiple
locations with different cultures, we should prevent that we create or establish an ‘us’ versus
‘them’ culture. As people can get frustrated about the other ‘location’ when they are not
behaving as they want them to. Hence, Squads should exchange people from and to the other
side of their Squad on a regular basis, to get to personally know each other better, improve
teamwork and understand cultural differences.
The physical presence of Product Owner and Agile Coach – In addition to the previous principle
‘exchange of colleagues is a common practice’, particularly the PO and AC should be present in
person on regular basis, as he / she should stay ‘in the picture’ at all locations for leadership
attention.
Shared team development goals – Squads have a common purpose / goal growing into a High
Performing Team, with a common roadmap.
Squad have E2E ownership- All Squad members have E2E ownership of their IT asset. Hence, it
should ideally not be the case that development activities are at one location while operations
2 Based on organization design principles of ING

3 Based on good practices of distributed Agile Squads
activities are at the other location, the same for testing activities, solving CAS items etc. This, in
order to prevent the creation or establishment of an ‘us’ versus ‘them’ culture (Chinese Wall)
and to stimulate learning from each other. In case this is not possible on a short-term, at least
the Squad members should work together as a virtual team.
IT Health
With the introduction of the Tribe / Squad model, adhering the principle of DevOps, we created
autonomous teams, responsible both for changing and maintaining secure and reliable IT services i.e.
a healthy IT. IT Health is based on managing the risk to our IT through controls defined in the policies
and minimum standards (see ING Policy House) and IT security standards (see Technology Standards).
Please note that internal network access is required to follow these links.
Why emphasize the need for IT Health?

IT Health is instrumental to ING to earn and sustainably maintain the trust of customers and safeguard
their and ING’s data while offering reliable IT services anywhere and anytime. Insufficient IT Health
could lead to financial loss, regulatory sanction or reputational damage and as a result of this IT Health
should be in the genes of our Engineers. As we introduced our new way of working to keep up with the
rapidly changing world and speed up our ability to change, IT Health can easily get less priority.
Therefore we want to make explicit that IT Health is part of our day-to-day delivery, which should be
executed via our OAWoW.
What do we mean with IT Health?

IT Health refers to all the activities which are needed to keep a ‘healthy’ run of the IT landscape. These
activities are the design and implementation of the IT risk controls (see ING Policy House), and the
testing of their design and effectiveness, as required for the services or IT assets. Any issues found
during testing have to be resolved in time. The controls are grouped into the following six IT Risk areas:
Essential to understanding the risk and address it appropriately is the assessment of ING’s assets by
their Product Owners. The correct registration of all assets and their assessment is the foundation for
all other controls.
Who owns IT Health?

As stated in the previous paragraph, the Tribe Lead is the CPO or assigns (C)PO for the systems in his
Tribe. As a result of that, he / she is accountable for the IT Health (in most cases delegated to the IT
Area Lead in his role as IT Custodian) of the IT assets in his / her Tribe. They fulfil the role of the ‘first
line of defence’. The actual housekeeping on IT Health is done by the engineers in the Squad, changing
and maintaining the IT asset, as they have the actual knowledge and rights to perform the actions
required.
How to manage IT Health?
First of all, managing the IT Health of an IT asset should be in the genes of the Squad. Engineers should
take responsibility for managing the risks to their IT assets. From this perspective, all IT Health aspects
should be included in the Definition of Done of every Squad.
For example: Squads check that for the defined business requirements, a risk and impact analysis on
business processes, infrastructure, systems, applications, business continuity plans, service providers is
timely performed, in any case prior to development. The risk and impact analysis addresses also
compliance of the IT solutions with relevant ING Policy documents. Mitigation of the identified risks (if
any) is included as part of the requirements, new Stories and / or acceptance criteria / Story. The NFR
function challenges and advises on the risk and impact analysis, and the mitigating controls.
But although we strive as much as possible for autonomy for Tribes and Squads, there should be
mechanisms in place which trigger recurring attention for this. This could be done by having the right
metrics on these aspects at the Performance Wall, for instance: #open risk issues and #vulnerability
patches behind. In case of deviations of the desired results, you might:
1. Work out improvement targets in KATAs
2. Implement the improvement Features / Stories on the Sprint / Product Backlog of the
Squads
or even
3. Create an Epic for the Tribe for a collective attention and plan it in the QBR
Of course, it is necessary that this work can be connected to Themes and a standard percentage of
unplanned, but reserved time is recommended depending on the Tribe’s preference.
Having these discussions every planning cycle will, in the end, increase the awareness that IT Health
‘comes along with the job’ and therefore needs to be managed actively. In order to prevent that:
 Squads have to pick up this work on top of the functional change, which often leads to
postponing this work
 Sprint Planning sessions get disrupted by ‘ad hoc’ Themes / Epics, wiping the Product and
Sprint Backlogs clean for this
However, it still can happen that at a certain period of time there is a need for disrupting the work
which is prioritized or even planned e.g. after an audit. For this, in the related events, there is always
room for ‘re-prioritization’. This will be more detailed in the upcoming chapters.
IT Processes
When changing our way of working towards an Agile approach, it is still required to act in a controlled
way. The Information Technology Infrastructure Library (ITIL) V3 (2011) process framework supports us
to stay “in control” and delivers evidence accepted by our regulators. While the ITIL processes deliver
complementary value for the IT delivery & maintenance process, in our current WoW by becoming
more Agile and automating steps, certain steps in the ITIL processes become effectively obsolete,
input- or output and, as a result of that, evidence is changed and responsibilities are shifted (e.g. from
dedicated roles towards teams). Hence, the ‘in control’ (ITIL) processes at ING are changing as well in
alignment with the OAWoW and in respect to ING’s minimum standards.
At the time of writing this document, a new Agile IT process framework has been developed,
containing: governance, innovation, create and operational processes.
In the near future, all the Agilised processes can be looked up via this framework.
For now: the currently changed ‘in control’ processes are published at the global IT processes
sharepoint (please note that internal network access is required).
From ING’s Vision and Strategy to Themes
This chapter describes the processes we follow to translate ING’s Vision and Strategy, including our
Think Forward Transformation, into Change Portfolio and further into Themes, as well as the delivery
management processes to ensure Executional Certainty on Bank-wide level. It is a summary of the
Transformation Management – How we work – document (a.k.a. Transformation Handbook (please
note that internal network access is required)) by GTO.
Flow
After defining the Vision and Strategy, it’s crucial to bring Strategy into execution in
order to deliver the desired value for our customers and other stakeholders.
Bankwide, all change is managed through Strategic Portfolio Management (SPM).
SPM is the periodical assessment of the Transformation Portfolio triggering potential
new plans to fill any gaps, cascading of group priorities, and rebalancing
investments were necessary and is discussed in Quarterly MBB sessions (MBB is the
Management Board Banking).
For prioritization and governance, the ING Transformation Portfolio composes of

two categories:
1. Transformation Programs are globally agreed critical, cross-country or
local programs. The programs have predefined roadmaps, and decompose
into multiple Themes (called initiatives in Transformation Handbook).
2. Local Change consist of the change investments that do not form part of
the Transformation Programs. It often relates to improving specific local
products, processes as well as local regulatory requirements. The Local Change within an
entity comprises of Themes.
The way of managing Themes depends on where they originate from:
3.1.1 Category 1: Transformation Programs
Transformation Programs are large containers of various Themes, each with their own defined targets
(investments, benefits and KPIs) and roadmap. Examples of Themes could be the country component
of a global program (e.g. country implementation of Modelbank), or a major self-contained
workstream (e.g. Workday implementation in HR TOM program). Transformation Programs follow
global governance and their progress is tracked monthly and quarterly through financials (investments
and benefits), KPIs and milestones. A more detailed description in how this takes place is explained in
the next paragraph.
From the selection of Transformation Programs which are considered to be important to track and
trace on MBB level, the Roadmaps are plotted in the Transformation Obeya Room on MBB level.
Managing a Transformation Program
Schematic overview
Description
The decomposition of a Transformation Programs into Themes and execution of the Transformation
Programs is supported by two core processes:
1. Global Gated Process (GGP): Jointly agreed best practices, providing standards and guidelines
for Transformation Programs, structured to five predictable review gates. The process supports
programs to “level up” their maturity – focusing on strategic alignment, design assurance,
business case and executional certainty. The gated process also ensures interlocks (program-
program handshakes, program-initiative handshakes and functional validations from e.g.,
Enterprise Architecture, Global Data Management, Global Process Management, etc.).
The gates are: (1) Idea, (2) Business Case, (3) Ready for Execution (incl. Roadmap), (4)
Implementation ready (complete) and (5) Benefits realized. Formal decision for passing a gate
is done by the Change Investment Committee (CIC) for gates 1-2 and Global Transformation
Office (GTO) for gates 3-5.
The Roadmap of a Transformation Program is plotted in the Transformation Obeya room of the
Transformation Program.
2. Global Quarterly Business Review (QBR) (consisting of both Transformation Program and Tribe
QBRs): Transformation Program roadmap increments (Epics) are delivered through 90-day
cycles, encouraging delivery of benefits every 90-days instead of only end-of-Program. The
QBR process is a quarterly planning process which incorporates feedback, re-calibration and
alignment of plans with clear investment release and change control. Global QBR process
involves the Tribes’ QBR process (described in chapter ‘From Themes to Epics’) as well.
The Transformation Program part of the Global QBR process has five steps:
I. Pre-QBR guidance: MBB shares bank-wide Transformation Program ambitions to Local
Boards. With taking into account these ambitions, Local Boards provide pre-QBR
guidance to Tribes (see chapter ‘from Themes to Epics’)
II. Global QBR writing: (senior) Road managers write Transformation Program QBR
document that is synchronised with Theme plans
III. Global QBR review: Other Transformation Programs and entities can comment on the
plans
IV. Global QBR market: Event to resolve open interdependencies and issues
V. Monthly MBB: Resolving any remaining interdependencies open after the QBR market
As already mentioned, are Epics provided by (senior) Road managers (with involvement of local
Portfolio managers) as well as Epics based on local ambitions (see next paragraph) input for the Tribe’s
QBR. Whenever the global and local input for the QBR cannot be met, priority conflicts are escalated /
communicated towards the global QBR market by the local Portfolio manager. In the end, the plan for
next two cycles (180 days) is agreed. The plan for the next 90-days is frozen, whilst the plan of
following 90-days can still be adjusted during the next cycle.
Outcome and progress of the Global QBRs is managed in the Monthly / Quarterly Transformation
Delivery sessions (TDT), which takes place in the MBB’s Obeya Room.
Whenever a Tribe is not able to complete or even plan the required Epic in time, the impact of that is
discussed during Monthly Roadmap session, taking place in the Obeya Room of a Transformation
Program and / or MBB.
3.1.2 Category 2: Local Change (incl. business as usual)
The remaining types of change (incl. business as usual), which usually can be organised and delivered
by an entity (country or domain(s)) itself without the governance of a Transformation Program, is
categorized as Local Change. It is driven by the entity’s strategy and typically strongly related to
improving or maintaining specific local products, processes as well as regulatory requirements.
These Themes are not predefined in Epics, but have a more KPI driven character. They are often
directional (e.g. we want to increase Reliability or we want to keep our Life Cycle Management / Patch
management up to date).
The definition breakdown and prioritization of the Epics contributing to these Themes is done by the
Tribes themselves (having a high degree of autonomy) based on guidance by the local Board and / or
MBB (e.g., by defining a top X list of directions / priorities which contribute to the entity’s strategy). This
process and managing the delivery is done by Tribe’s QBRs and delivery assurance processes (see
chapter ‘From Themes to Epics’).
Events
3.2.1 Quarterly and Monthly MBB
Quarterly agenda:
 Review transformation dashboard and overall portfolio progress including portfolio risks
 Monitor organisational health and engagement indicators
 Confirm bank-wide strategic investment & transformation priorities / Themes, KPIs and targets
 Adjust change budget & targets to Transformation Programs / entities if needed (following CIC
recommendations)
 Re-balancing portfolio on a recurring basis (where required)
 Communicate priorities ‘pre-QBR’ on a quarterly basis
Monthly agenda:
 Review key program progress by MBB responsibilities
 Review program and portfolio risks
 Resolve escalated issues (based on escalation from TDT / 2:2s)
Participants:
 MBB members (Quarterly/Monthly)
 Corporate Strategy and Group Finance (Quarterly)
 Chief of Staff (Quarterly/Monthly)
 Head of GTO (Quarterly/Monthly)
3.2.2 Change Investment Committee (CIC)
Agenda:
 Approve business cases for Themes of Transformation Programs
 Release funding for Themes of Transformation Programs
 Optimise funding (resource) allocation across Themes of Transformation Programs
Participants:
 Global COO
 Head of GTO
 Head of CS
 Head of OIB
 Head of Risk & Compliance
 COOs from ING C&G Cluster
 COOs from ING Market Leaders
3.2.3 Monthly 2:2 meeting
Agenda:
 Discuss progress of key Transformation Programs in scope
 Resolve impediments escalated from TDT
 Align on key topics to discuss at MBB level
 Provide support to MBB members
Participants:
 MBB member and CIO / COO / CTO
 Program Owner, who is accountable for the Transformation Program (COO and CIO (MBB -1))
 Head of GTO
3.2.4 Quarterly and Monthly Transformation Delivery Team (TDT) sessions
Agenda:
 Discuss outcomes of global QBR market and resolve any open impediments (Quarterly)
 Review progress for key Transformation Programs
 Resolve cross-program interdependencies, prioritization questions, design issues and
impediments (escalated from Monthly Roadmap session)
 Escalate risks, issues and cross Transformation Program interdependencies to MBB
 Escalate key decisions with P&L impact beyond Change Control threshold to CIC
 Escalate funding re-allocation across programs to CIC
Participants:
 COO / CTO / CIO
 Head of GTO
 Head of Smart PMO (part of GTO and Obeya Room facilitator)
 Program Owners
3.2.5 Monthly Roadmap session
Agenda:
 Create / Update roadmap
 Assess program milestone delivery
 Identify blocking interdependencies, impediments and root causes
 Formulate action plans
 Escalate unresolved impediments to Transformation Delivery Team
Participants:
 Senior Road managers for key Transformation Programs
Artefacts
3.3.1 Roadmap
Decomposition of a Theme into milestones with expected delivery date, focus on investments, planned
benefits, key risks and interdependencies. Epics link to milestones. Establishes an effective basis for
tracking milestones and related outcomes and outputs with bank-wide relevance.
The roadmap (a.k.a. Epic wall):
 Shows Themes with its related Epics and the involved Tribes plotted in time
 Is the basis for all planning, update and refinement meetings on Theme / Epic level
 Is used to coordinate dependencies across Tribes
 Can also consist of:
o Themes / Epics belonging to a Transformation Program (roadmaps)
o Themes / Epics derived from Local Change
3.3.2 Obeya Room (Transformation Program)
Obeya Room visually represents Transformation Program(s) performance and facilitates impediment
resolution. It supports collaboration and
interaction.
The Transformation Obeya Room has the

following components:
1. Performance wall – showing the current

score on strategic KPIs;
2. Roadmap - which work by Tribes is being
done when, to deliver more or improved
value to the customer;
3. Action board – containing the
impediments that need to act upon now
by the Leadership, to ensure that the
business keeps on running;
4. Improvement wall – containing the improvements (visualised in Kata Storyboards), in order to
realize the strategic objectives.
See “The OAWoW – Obeya confluence” (please note that internal network access is required) for more
information.
From Themes to Epics
This chapter provides a deep dive into the process of translating Themes to Epics. In addition, related
events and artefacts will be addressed.
Flow
Squads focus on delivering working (IT) products and services frequently, from a
couple of weeks to a couple of months (with a preference to the shorter timescale).
To allow Squads to focus, work has to be prioritised. In order to prioritise the work for
Squads, there are some basic guidelines:
 Themes, defined in the Portfolio management process (see ‘From ING’s Vision
and Strategy to Themes’) are the foundation for all Tribes and Squads and will
be processed in the standardised Global Backlog management tooling.
 Epics are aligned with Objectives and Key Results (OKRs) (related to any value
for ING), to align the work for the Squads with the strategic vision and report
back the executed Features / Stories linked to these Epics (see for more
explanation Appendix C).
 Epics are delivered in one or more quarterly cycles and can be broken down
into Features that can be delivered within a business quarter and are
considered as Minimum Viable Products.
Starting point
Translation of Themes into Epics is strongly depending on the way the Themes are defined in the
previous chapter. Themes can have two originations:
 Transformation Programs have predefined roadmaps, are decomposed into multiple Themes
and are both global and local.
 Local Change consists of the change investments that do not form part of the Transformation
Programs. It often relates to improving specific local products, processes as well as local
regulatory requirements. The Local Change within an entity comprises of Themes which are
not predefined in Epics but have a more KPI driven character.
Sequenced events and artefacts
Schematic overview
Description
When Tribes define their own Epics (in case of Local Change), Epic One-Pagers are created to provide
information about the suggested Epic, like the Epic’s value, size, high-level content, etc.. During the
creation of an Epic One-Pager, the Domain Architect performs a high-level assessment of the major
impact of the Epic and its contribution to the Target Architecture (as proposed in the ‘Enterprise
Architecture TOM’ (please note that internal network access is required)). The delivery and result risk
assessment process is initiated during the creation of the Epic One-Pager.
To come to a prioritised list of Epics (and Features), Tribe Leads perform the Quarterly Business Review
(QBR) process. Input for this QBR process are all Epic One-Pagers, originating from either
Transformation Programs and Local Change (e.g. defined by entity, Tribe, Squad or other stakeholders).
Quarterly Business Review

Tribe Leads stimulate collaboration in and between the Tribes by ensuring that the QBR process is a
collective process of the Tribe with active engagement of the (C)POs, IT Area Leads and Chapter Leads
and, if applicable, the (Senior) Road managers of the Transformation Programs involved.
The QBR process consists of three main phases:

1. QBR preparation: by discussing open actions of previous QBR-Market(s),
defining priorities based on pre-QBR guidance (usually given by local /
global boards (business, CIOs or MBB)), providing updates on
commercial, financial and operational performance, lessons learned
from previous quarter, etc. The way of preparing the QBR memo is free
format, but can be done by QBR-preparation sessions. Then summarize
the outcome of the QBR preparation in QBR memo, including purpose,
looking back at the previous (current) quarter, looking forward to the next quarter and
ambitions & goals (so-called Objectives & Key Results (OKRs)) based on value to the consumer.
2. QBR alignment: Tribes review QBR memos of other Tribes to discover conflicting items. Then
organise QBR-market(s) to align with the priorities of Epics (and Features) that require
collaboration between two or more Tribes and / or align with Global QBR ambitions. Finally,
(responsible of) the Local Board (usually entity level) discusses follow-up actions that should be
discussed at Local Board level, formalize the QBR memos and decide upon budget allocation
when needed during the Board alignment session.
3. QBR communication: Tribe Lead informs the Tribe about the priorities for this quarter and
distributes the Epics (and Features) amongst POs and Squads.
After QBR communication, the Roadmap (described in ‘From ING’s Vision and Strategy to Themes’) can
be updated and the new Epics / Features can be put on the Tribe’s Portfolio wall (a.k.a. Feature wall, see
‘From Epics to Features’) as a starting point for the next three months. This Portfolio wall is used for
cross Squad management of Features, as most Epics (and Features) require multiple Squads to
collaborate within a or across Tribe(s). On the Roadmap and / or Portfolio wall the product activation
target dates can be visualised.
Depending on the context in which Tribes operate, metrics are implemented to measure the current
operational performance of the Tribe, support dialogue and learning, plan improvement actions and
observe whether improvements lead to better performance / quality. These metrics can be visualised
on a Performance wall. Progress regarding these items can be discussed during the Tribe Performance
session and improvements can be defined (visualised in Kata Storyboards) to be put on the
Improvement wall. Please note that using metrics to learn and improve is more important than using
metrics to control and check adherence.
The Tribe Lead should organise a (Daily)Tribe Stand up for all POs within the Tribe to be able to address
impediments, which Squads cannot solve by themselves. These impediments are put on an Action
board.
Combining a Portfolio wall, Performance wall, Action board and Improvement wall in a single place,
accessible to all members of the Tribe, is considered as a good practice. The Tribe Obeya room
(Japanese for “Big Room”), refers to such a visual management tool setup in one physical room. Such a
room helps understand the value stream of your (part of the) organization and provides actionable
insights.
Whether an organisation needs Obeya rooms above Tribe level (like on entity level) is up to the
organisation itself. In the end there should be as much information as needed, plotted in Obeyas, to
get the best overview top-down as well as bottom up from Board of Directors to shop floor and back.
More information about the Obeya is described in “One Agile Wow - Obeya confluence” (please note
that internal network access is required).
Events
4.2.1 QBR-market
Agenda:
 Discuss issues or conflicting priorities of QBRs memos and / or
Global QBR ambitions
 Define decisions and actions (such as: further analysis required or
other people should be involved)
Participants:
 Tribe Leads
 Road managers
4.2.2 Board alignment session
Agenda:
 Discuss follow-up actions from QBR-markets that should be discussed at Local Board level
 Acknowledgment of the Local Board regarding the ambitions of all Tribes described in their
QBRs memos
 Deciding whether (and how) allocation of budget and capacity should be adjusted
Participants:
 Local Board members (usually entity level)
 Tribe Leads
Note: this meeting can vary from a formalized meeting up to an agenda point in a regular Local Board
meeting or even a bila with a Local Board member, responsible for the Tribe.
4.2.3 Tribe Performance session
Agenda:
 Discuss the metrics where current state does not meet the Tribe’s KPIs
 Define improvements (visualised in Kata Storyboards) by using the Improvement wall that is
part of the Tribe Obeya room
 Discuss status of problem-solving actions of previous Tribe Performance sessions (hence,
discuss what is the status and whether assistance is needed)
Participants:
 Tribe Lead
 IT Area Lead
 (C)PO
 Agile Coach
4.2.4 (Daily) Tribe Stand up
Agenda:
 Intake new impediments
 Follow up on actions related to existing impediments
Participants:
 Tribe Lead
 IT Area Lead
 Agile Coaches
 (C)POs
 (Other representatives from Tribes and Squads that are deemed necessary by a PO)
Artefacts
4.3.1 QBR memo
The QBR memo summarises the outcome of the QBR process. It contains the following information:
 Purpose: long term view
 Looking back at the previous (current) quarter: how have we been doing? How did we score on
our ambitions and goals? What worked well and what did not work so well? What are our
learnings?
 Looking forward to the next quarter: based on the learnings of the previous quarter, we look
forward to the next quarter. By defining forecasted Epics for the next quarter (incl. how they
are linked to Themes, what the expected impact will be, which other Tribes will be working on
these Epics as well) including product activation target dates.
 Ambitions and Goals (or Objectives & Key Results): for the next quarter are formulated.
4.3.2 Epic One-Pager
Provides information about an Epic such as:

 Why (purpose) and what (e.g. which high-level Features will be part of this Epic)
 Value: How it is linked to business objectives and
expected benefits
 Size: e.g. budget, quarters and T-shirt size (e.g. S, M, L, XL)
estimated by PO and / or Feature Engineer
 Stakeholders
 Squads that need to work on the Epic
 Urgency and risks
4.3.3 Performance wall
Provides an overview of metrics (or dashboards) showing the current performance (on a wall) of a Tribe
in the Tribe Obeya room. They can be various, like delivery speed (# times to production), operational (#
incidents, availability) and / or risk related (# open risk issues, # vulnerability patches behind). It shows
the current score on the Strategic KPIs, hence whether this score is below or above the Tribe’s current
norm.
4.3.4 Action board
The action board provides an overview of the impediments and actions that the Tribe has to act upon.
This board is in the Tribe Obeya room.
4.3.5 Improvement wall
Provides an overview of the improvements in the Tribe Obeya room, visualized in Kata Storyboards
(using the good practice method Plan-Do-Check-Act (PDCA)).
Kata are small, structured practice routines or protocols. Through physical practice, their pattern
becomes second nature, done with little conscious attention. Kata are typically for learning
fundamentals to build on. The goal is not the Kata themselves, which get used less as you grow more
proficient, but the habits of thinking and acting that practicing them leaves behind.
They are stepping stones for anyone who wants to acquire new ways of thinking and acting. Kata
make skill and mind-set transferrable, which is particularly useful for developing an organizational
culture.
Practicing the routines of the Improvement Kata gives us a way to develop scientific thinking and
acting. A Kata consist of four steps:
1. Give the direction or challenge (long term)
2. Describe / understand the current condition
3. Establish your (short term) next target condition (preferably expressed in KPIs on the
Performance wall)
4. Conduct structured experiments to get there / start removing all obstacles in the way to your
target condition
The Continuous Improvement Framework (including Kata) (please note that internal network access is
required) is described in more detail in a reference document.
4.3.6 Tribe Obeya room
Linking strategy with the situation of today and constantly improving ourselves are two cornerstones
of our OAWoW. An Obeya Room helps us with this by creating a space for intense collaboration and
interaction. A Tribe Obeya room has the following components:
1. Performance wall – showing the current

score on strategic KPIs;
2. Portfolio wall - which work by teams is
being done when to deliver more or
improved value to the customer;
3. Action board – containing the
impediments the Tribe Leadership has to
act upon now, to ensure that the business
keeps on running today;
4. Improvement wall – containing the
improvements (visualised in Kata
Storyboards) you are working on, in order
to realize the strategic objectives.
See “The OAWoW – Obeya confluence” (please note that internal network access is required) for more
information.
From Epics to Features
This chapter provides a deep dive into the process of translating Epics to Features. In addition, related
events and artefacts will be addressed.
Flow
Epics should either be delivered as a whole within a quarterly cycle or, in case of larger,
more complex Epic, in incremental deliveries (e.g. “working software” releases
delivering Minimum Viable Products (MVPs)) with just enough Features to gather
validated learning in reviewing. In order to translate Epics into Features and Stories,
there are some basic guidelines:
 Responsibility with regard to the delivery of Epics is placed as much as possible

within a single Tribe and within a single Squad
 Features are part of Epics and as a result of that, they deliver part of the value
of the Epic. They usually consist of end-to-end functionality, usable as such for
the customer (shippable product)
 Multiple Features that belong to a single Epic are prioritised and placed in a
delivery order based on common sense, business benefits, risks and
dependencies
 A Feature is a logical set of Stories that can be delivered in one or more Sprints.
 In case of Epics which can be directly broken down into Stories, this chapter could be obsolete.
Starting point
As a result of the QBR process, the Tribe Leads and (C)POs have agreed on the list of Epics and Features
for the next quarter’, based on T-shirt size (a per Squad / Tribe ratio of an amount of Sprints compared
to t-shirt sizes (Small up to XLarge). Depending on the context we need to consider two scenarios when
picking up the Epic / Features for further refinement / execution:
 Epic or Feature is delivered by a single Squad: The PO of the relevant Squad picks up the Epic
and / or the corresponding Features at the Portfolio wall and refines them into the Product
Backlog together with his Squad. If this is the case, chapter ‘From Features to Stories’ is the
next step.
 Epic or Feature is delivered by multiple Squads: If multiple Squads are needed to deliver the
Epic, (C)POs refine and plan the Epic and Features to a level that Squads can pick these
Features up for further refinement, planning and delivery. Alignment with Squads and
stakeholders, reviewing the deliverables, managing dependencies are part of this process. If
this is the case, the description of this process is given in the upcoming.
Sequenced events and artefacts
Schematic overview
Description
The CPO needs to ensure that every new Epic and Feature from the QBR is prioritized and planned
somewhere in the next three months. This is done in the Portfolio marketplace, where the product
activation target dates are to be taken into account, resulting in a revised Portfolio wall.
Whenever a Feature is to be executed, Feature engineers, who have the knowledge and oversight of
this (part of the) IT landscape in relation to the functionality, together with others like Domain
Architects and Squad representatives, refine / decompose the Feature (events happening at different
levels and with different frequencies, depending on the complexity) in what has to be done in which
system, risk and security approach: the Solution Approach. They make a high level design of the
solution of a Feature, taking into account functional and non-functional requirements (including risk
mitigation requirements coming from risk assessment process), dependencies, the strategic execution
roadmap towards the target architecture, and corporate policies and standards. This Solution
Approach implies a draft estimate (e.g. T-shirt sizing). Based on the decomposition of the Features, the
Features on the Portfolio wall have to be completed with the involved Squads.
Feature Engineers (and the other involved people) work in the same rhythm as all Squads, but usually
ahead (as their output is the input for Squads).
To keep track on the progress and alignment of the Feature delivery, the CPO can engage all POs from
all other involved Tribes in the Scrum of Scrums (as part of Portfolio marketplace). While updating, also
impediments can be raised, which are made visible on, or next to this wall.
Incidentally, during the execution of the Epics (and Features) in a QBR cycle, it can occur that the
Portfolio wall is updated with a new Epic (and Features) supported by Epic one-pagers during the
Portfolio marketplace.
Events
5.2.1 Portfolio marketplace
Agenda:
 Plan new Epics and / or Features (as acknowledged in QBR Memo) /
Agree on planning based on the risks and dependencies / Update
Portfolio wall
 Define acceptance criteria / required test scripts to be executed
 Present / Discuss new Epics / Features
(including the following a.k.a. Scrum of Scrums):
 Discuss and / or keep track on progress on Epics / Features
 Revise Squad estimates for existing Epics / Features
 Priority amendments to Epics / Features
 Raise and/or keep track on progress on solving impediments
 Refine and estimate the complex items
 Refine the initial estimate (T-shirt size) for each Epic / Feature based on input of Squads
Participants:
 (Feature Engineers)
 (C)POs
 (Agile Coaches)
 (Road manager)
 (Other representatives from Tribes and Squads that are deemed necessary by a PO)
Artefacts
5.3.1 Portfolio wall
Provides a clear forecast of the work for all Squads in a Tribe (and if applicable between Tribes) over the
longer term (usually six months: three months SMART as a result of the QBR, and three months high
level outlook for the next quarter).
The Portfolio wall (a.k.a. Feature wall):

 Shows Epics with its related Features and the involved Squads plotted in time
 Is the basis for all planning, update and refinement (Portfolio marketplace) on Epic / Feature
level
 Is used to coordinate dependencies across Squads (incl. testing, deployment and product
activation dependencies)
 Can contain the wish list (Product Backlog) of Epics and / or Features of the CPO
5.3.2 Solution Approach
Solution Approach is available for Squads at the beginning of a Sprint and is created by (Customer)
Journey Experts, Domain Architects and Feature Engineers (incl. taking up the testing
perspective). The Solution Approach can be Feature or Component-based. The
content depends on the maturity of the involved Squads and the complexity of the
issue: it can vary from a document up to a drawing on a whiteboard.
As a minimum the Solution Approach should include a solution description (with

respect to the architectural guidelines (as proposed in the ‘Enterprise Architecture
TOM’)( internal network access is required)), the product activation approach and respective test and
deployment approaches (in function of business, risk and technical acceptance criteria).
From Features to Stories
This chapter provides you with a deep dive in the process of translating Features to Stories. In addition,
related events and artefacts will be addressed.
Flow
Epics or Features are clusters of Stories that describe the actual work of Squads. In the
previous step, they are described on a high level, as the impact on possible
subcomponents (e.g. the different systems in the system landscape), in a so-called
Solution Approach (see the previous chapter). In order to translate Features into Stories,
there are some basic guidelines:
• Stories are the breakdown of small working increments that can be delivered in
one Sprint. To-be planned Features and Stories are tracked in the Product
Backlog.
• Squads translate their work to be done into one or more Stories.
Starting point
A Squad determines and realises the “how” of a Feature, based on the defined / provided
Solution Approach. The PO ensures that the Feature is broken down into Stories and
planned in Sprints leading to the actual delivery of the Feature in accordance with the
Portfolio marketplace.
Next to Features, also problem management, security patching etc. could create Stories for the next
Sprint.
Sequenced Events & Artefacts
Schematic overview
* Please note that Daily Stand Up and Definition of Done are described in ‘From Stories to value’.
Description
In order to translate Features into Stories, we presume that Squads work according to the Scrum
Framework (e.g. Scrum by the Book) and / or a Kanban approach. In practice, Scrum is suitable for
almost all Squads. The beating heart of Scrum is a Sprint, with a time-box of one or two weeks, in which
a “Done”, useable, and potentially shippable product increment is created: it is ready for production.
However, there are some circumstances in which working with a fixed Sprint is not feasible. This can be
the case when it is impossible to predict when work needs to start, or when it is impossible (not hard,
but impossible) to predict how long work will take to finish. In these circumstances, a Kanban approach
can be helpful. In addition, there are some circumstances that Squads work with a hybrid Scrum and
Kanban working model, also known as Scrumban.
Scrum
At the beginning of a Sprint, the workload (Stories) for the Sprint is determined in a Sprint Planning.
During the Sprint Planning, the Sprint Backlog is defined, which is a set of Product Backlog items
selected for the Sprint. (Stories or) Features of different Epics can be executed, as long as they fit into a
Sprint, meet the Definition of Ready and can be brought to Production together at the end of a Sprint.
Whenever (Stories or) Features appear to be too big to fit in a Sprint or too complex to execute as one
Story, they can be broken down into more Stories. This is done in a Backlog Refinement session.
Although this is done during a Sprint, it is the preparation of the Stories for the next Sprints. Together
with the Feature Engineer, the Squad works out in how many Sprints the Feature will be delivered and
what the acceptance criteria will be. When the Stories are delivered is eventually formalised in a Sprint
Planning. Although ‘Done’ Stories can be deployed to Production, Feature acceptance is needed before
product activation.
The Product Owner and / or Feature Engineer and / or Road Manager (in complex cases) will facilitate /
coordinate (not steer!) the actions on the Feature level i.e. Product / Sprint Backlog alignment across
Squads, in case of a large and complex Feature. For example, an integration (and validation / testing)
Sprint could be defined, followed by a collective product activation (release) moment. In other cases,
independent releasing could be an option (e.g. first the backend change exposed by a n & n+1 service
(for the old and the new situation), then e.g. the API and / or Front end). This is defined in the Solution
Approach.
A Sprint Review is held at the end of each Sprint to inspect the Increment and adapt the Product
Backlog if needed. This is not meant as a status meeting, and the presentation of the Increment is
intended to stimulate feedback and collaboration. The Sprint Review is the meeting to create
stakeholder alignment and share information about the need to change priorities on the backlog.
Finally, the Sprint Retrospective is an opportunity for the Squad to inspect itself and create
improvement Stories to be enacted during the next Sprint.
In case of larger and / or complex Features, a Feature Review can be organized, whenever the complete
Feature meets the acceptance criteria as defined upfront and as proven during E2E or acceptance
testing through a final feature test report. In case all Stories of the Feature are already deployed into
Production, the Feature acceptance can trigger the product activation after validation of the Tribe
Lead. If not all Stories are deployed into Production, the deployment is initiated according to the Tribe
deployment and product activation strategy. This review meeting is at Feature level and is usually a
cooperation between the Squads working on the Feature with the objective to accept the Feature and
trigger the product activation (release).
Kanban
Like Scrum, Kanban encourages work to be broken down into manageable chunks and uses a Kanban
Board (very similar to the Scrum Board) to visualize that work as it progresses through the work flow.
Where Scrum limits the amount of time allowed to accomplish a particular amount of work (by means
of Sprints), Kanban limits the amount of work allowed in one condition (only so many tasks can be
ongoing at the same time (‘Work in Progress (WIP) limit’), only so many can be on the to-do list.). As a
result of that, Kanban will not perform a Sprint Planning but will work on the items with the highest
priority. It is even not necessary to have a Product Owner when the work is mainly repetitive /
operational by nature and / or stakeholder management is not required.
During this 'Scrum by the book' and / or Kanban execution (this and next chapter), the PO, Chapter
Leads and the Scrum Master and / or Agile Coach form an active coalition to continuously monitor and
improve the working of a Squad. This coalition is called the POCLAC.
Events
6.2.1 The Sprint
Characteristics of the Sprint:

 Standardised to one or two weeks
 A new Sprint starts immediately after the conclusion of the previous
During the Sprint:

 No changes are made that would endanger the Sprint Goal
 Quality goals do not decrease
 Scope may be clarified and re-negotiated between the PO and Squad as more is learned
6.2.2 Sprint Planning
Agenda:
 Define what can be delivered in the Increment resulting from the upcoming Sprint
 Define how the work needed to deliver in the Increment will be achieved
 Define a Sprint Goal for the Increment
Participants:
 The Squad
 (Agile Coach)
Dealing with unplanned operational activities

Squads could reserve bandwidth time for unplanned operational activities on their Sprint Backlog
during the Sprint Planning. Size could be based on historical data of time spent (also for technical debt
and problem analysis), expressed in a percentage of Sprint capacity.
For more mature Squads (that do not need to reserve bandwidth time), in case of incidents (depending
on the severity), the incident will be solved immediately which could affect reaching the Sprint goal. In
that case, Stories with the lowest priority of the Sprint will be input for the next Sprint Planning.
6.2.3 Sprint and / or Feature Review
Agenda:
 The Product Owner explains what Product Backlog items have been
“Done” and what has not been “Done”
 The Squad discusses what went well during the Sprint, what problems it
ran into, and how those problems were solved
 The Squad demonstrates the work that is has “Done” and answers questions about the
increment
 Based on what has been done and the changes to the Product Backlog during the Sprint,
attendees collaborate on the next things that could be done to optimize value
Participants:
 The Squad
 Stakeholders
 (Feature Engineer)
 (Agile Coach)
6.2.4 Sprint Retrospective
Agenda:
 Inspect how the last Sprint went with regards to people, relationships, process, and tools
 Identify and order the major items that went well and potential improvements
 Create improvement Stories regarding the way the Squad does its
work
Participants:
 The Squad
 (Agile Coach)
6.2.5 Backlog Refinement
Agenda:
 Perform detailed requirements analysis
 Present, explain and estimate new items
 Refine items that are too complex
 Re-estimate existing items
Participants:
 The Squad
6.2.6 POCLAC
The POCLAC is a coalition, which usually meets once a week or once a Sprint, at which the PO, Chapter
Lead(s) (and if considered necessary Scrum Master) 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 CL.
During the POCLAC:

 The PO is owner of functional leadership, the what and the why.
 The Scrum Master and / or Agile Coach is owner of turning
Squads into High-Performing Teams, for continual improvement
and for safeguarding the Agile values.
 The Chapter Lead is owner of the growth of individual chapter (and therefore Squad) members,
for ongoing professionalization.
 Together, they ensure that Tribes/Squads are qualitatively properly staffed.
Artefacts
6.3.1 Product Backlog
The Product Backlog is an ordered list of everything that might be needed in the service in scope of the
Squad(s) and is the single source of requirements for any changes to be made to the service. This
service could be an (IT) asset (in case of one or more Squads working from that Product
Backlog) or even multiple (IT) assets (in case of a feature team working from that IT asset).
All members of the Squad can propose to add new items to the Product Backlog. However,
it is the PO who owns the Product Backlog, including its content, availability, and ordering.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in the future. Product Backlog items
have the attributes of a description, order, estimate and value.
 The Product Backlog is a list of all potential future items (Epics, Features, Stories) dealt with by
a Squad
 The Product Backlog lists the items in order of priority
 The top-priority items (mainly Stories) are more detailed and elaborated
The PO can introduce new Epics and Features from his Product Backlog towards other Tribe members
during a Portfolio marketplace.
6.3.2 Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, including testing and
deployment, for delivering the product Increment and realising the Sprint Goal. It represents the plan
of approach of the Sprint.
Key characteristics of the Sprint Backlog:

 Sprint Backlog items with the highest priority are posted at the top of the board
 The status and priority of the Sprint Backlog items are displayed on the Scrum Board
 The Scrum Board contains up-to-date information on the Sprint backlog, progress and
impediments
 The Scrum Board hangs on the wall of the
Squad’s workplace
 The Scrum Board contains Stories as well as
Tasks
6.3.3 Definition of Ready
 The Definition of Ready (DoR) sets out the pre-requisites in order to deliver the Stories
 The DoR is drawn up by the Squad
 The Squad determines whether Product Backlog items meet the DoR
 The PO respects the DoR. That means that a Product Backlog item is only
included in a Sprint if it meets the DoR
6.3.4 Kanban Board
Key characteristics of a Kanban Board:

 Every Kanban Board is split into three basic sections that show the up-to-date state (requested,
in progress and done) of the work
 The swimlanes of the Kanban Board can be dedicated to specific types of activities (design,
bugs, technical debt, etc.)
 The Kanban Board hangs on the wall of the Squad’s workplace
 The Kanban Board contains Stories
From Stories to Value
This chapter provides you with a deep dive in the process of execution of Stories into value on a day to
day basis. In addition, related event and artefact will be addressed.
Flow
7.1.1 Develop, test and transition
To measure progress, discover dependencies, raise impediments (blocking issues,

also when they cannot be solved by the Squad itself), the Squad gathers every day
in a Daily Stand up at the Sprint Backlog (see ‘From Features to Stories’). The
purpose is to tell each other briefly about their progress towards the Sprint
commitments.
This chapter mainly concerns the real engineering work (coding (of functionality
and test scripts), build, test and deploy), according to the priority setting in the
Sprint.
In the engineering process, we follow as much as possible the principles of

Continuous Delivery. The goal of Continuous Delivery is to enable a constant or
frequent flow of (smaller) changes into production via an automated software production line (also
known as CD Pipeline), which delivers fast feedback. The underlying principle of Continuous Delivery is
that learning from mistakes sooner in the process, the chance of mass rework or the time to repair an
error can be substantially decreased.
The CD Pipeline itself consist of set of tools which supplies a fully Automated software production
process line and support all the steps within Continuous Integration up to Continuous Deployment
from code to build, test and (re)deploy whilst respecting Bank standards and gates for risk and quality
(which evolve to a more Agile character as a result of this (e.g. by automation)).
Continuous Integration is the process to integrate (merge), build and test the new code as fast as
possible to a Develop, Test or Pre-production environment. The primary objective is to prove whether
the changes do not break the Build. Continuous Deployment is the part of the process where one
defines an “agnostic deployment process” which covers pre and post configuration from Development
to Production environment in small increments a higher frequency in order to get fast feedback.
Usually End to End (E2E) testing is required, which results in running a set of automated test scripts on
E2E level.
The deployment strategy can differ from a full product to small updates that build up to a bigger
functionality to be really used by the target customer. As such a clear distinction is to be made
between the deployment of Stories into Production that are ‘Done’ and the acceptance of the Feature
and corresponding product activation.
For further acceleration of this process and increased focus for Squad members on their Stories, Squads
are supported by centralised tooling (build server, version control, Artefact repository & deployment)
and Configuration Management automation a.k.a. Continuous Delivery as a Service (CDaaS, which is
standardized tooling delivered as Service). Build servers are not configured and maintained by Squads
themselves, but are stateless (keep no relevant data within itself) and immutable. They can be applied
to deliver only the Build function as a service. Code can be shared between developers on a global scale
by using the central version control system. And by automating the deployment of the artefacts, the
handover between Development and Operations (as a result of ‘separation of duties’) is taken out.
A Story is considered Done when it meets the Definition of Done (DoD). Each artefact, as a result of this,
should be demoed (if applicable) to the stakeholders (PO), based on which the Story can be accepted
and either:
 Put into production in case of the possibility of independent deploying (Single change)
 Set to prepared/ready in case of deploying as part of a bigger change or combination of
changes (Release)
A Story that is Done can trigger a Feature acceptance (see ‘From Features to Stories’).
For more information, please visit: Change Management on the Global IT Processes SharePoint (ING
internal network access required).
7.1.2 Operations
Whenever a service is operational, different operational tasks need to be performed to make sure that
the service remains stable, reliable and delivered effectively and efficiently.
All tasks that can be planned and prioritized will be entered in the Product Backlog (e.g. story to
analyse a problem). Incoming tasks, that need to be done within the current Sprint, will not be entered
in the Product Backlog but will enter the Sprint Backlog directly (utilizing the bandwidth that could be
reserved during the Sprint planning).
These operational tasks will be performed following their respective IT process. The detailed
information about these IT processes is or will be published on the Global IT Processes SharePoint (ING
internal network access required):
IT process Description Document link

Incident management ensures that normal service operation is
Incident & restored as quickly as possible and the business impact is minimized.
Incident
Request Incidents may be recognized by technical staff, detected and reported
Management
Management by event monitoring tools, communications from users (usually via a
Service Desk), or reported by third-party suppliers and partners.
Problem management proactively prevents incidents from happening
Problem Problem
(Root Cause Analysis) and minimizes the impact of incidents that
Management Management
cannot be prevented (Workarounds).
The process responsible for allowing users to make use of IT services,
data or other IT assets. Access management helps to protect the
confidentiality, integrity and availability of IT assets by ensuring that
Access
only authorized users are able to access or modify them. Access
Management management implements the policies of information security
management and is sometimes referred to as rights management or
identity management.
The process responsible for ensuring that the IT assets required to
deliver services are properly controlled, and that accurate and reliable
Configuration Configuration
information about those IT assets is available when and where it is
Management Management
needed. This information includes details of how the IT assets have
been configured and the relationships between IT assets.
Included facilities management for DCs (power mgt., physical access
Lifecycle
control etc.), application and technical management and IT operations
Management
control.
Capacity The process responsible for ensuring that the capacity of IT services Capacity
Management and the IT infrastructure is able to meet agreed capacity- and Management
performance-related requirements in a cost-effective and timely
manner. Capacity management considers all resources required to
deliver an IT service, and is concerned with meeting both the current
and future capacity and performance needs of the business. Capacity
management includes three sub-processes: business capacity
management, service capacity management, and component capacity
management. See also capacity management information system.
The process responsible for ensuring that IT services meet the current
and future availability needs of the business in a cost-effective and
timely manner. Availability management defines, analyses, plans,
measures and improves all aspects of the availability of IT services, and
ensures that all IT infrastructures, processes, tools, roles etc. are
Availability
appropriate for the agreed service level targets for availability. See also
Management
availability management information system.
Availability management contains the ‘event management’ process

responsible for managing events throughout their lifecycle. Event
management is one of the main activities of IT operations.
The process responsible for managing risks that could seriously affect
IT services. IT service continuity management ensures that the IT
IT Service
service provider can always provide minimum agreed service levels, by
Continuity
reducing the risk to an acceptable level and planning for the recovery
Management
of IT services. IT service continuity management supports business
continuity management.
Events
7.2.1 Daily Stand up
Agenda:
 What did I achieve yesterday that helped the Squad meet the
Sprint Goal?
 What will I achieve today to help the Squad meet the Sprint
Goal?
 Do I see any impediment that prevents me or my Squad from
meeting the Sprint Goal?
Participants:
 The Squad
 (Agile Coach)
Artefacts
7.3.1 Definition of Done
 The Definition of Done (DoD) is the list of specific requirements and acceptance criteria
applicable to the Sprint Backlog items
 The Squad is only finished with a Sprint Backlog item once it meets the DoD
 The DoD is drawn up by the Squad
 Based on insights and a changing environment (continual improvement) the
DoD will grow towards the entire Product Chain
Glossary
Artefact An artefact is one of many kinds of tangible by-products. Some help describe the
function, architecture, and design of software. Other artefacts are concerned with the
process of development itself.
Burn Down A chart that provides the Squad insight in their velocity within the Sprint, using the
Chart work remaining over time.
BusDevOps The practice of Business, IT operations and IT development engineers collaborating in

one Squad for the E2E service lifecycle, including design, development, test, change
and production configuration, monitoring and support.
Change A Change is a modification of the existing functionality, product and / or service that
requires effort in terms of FTEs, money, goods, etc.
Continuous An automated manifestation of your process for getting software from new or
Delivery changed code into functionality in the hands of your users. It typically includes
Pipeline continuous integration, build automation, test automation and deployment
automation.
Continuous A software engineering approach to ensure that software can be Released reliably, fast
Delivery and easy at any time. It can be implemented using an automated Continuous Delivery
Pipeline.
Continuous A long-term approach that systematically seeks to achieve small, incremental changes
Improvement in processes in order to improve efficiency and quality.
Data With Data, we mean all data we use within the bank like our customers, employee,
product, transaction, operational, pricing data, etc.
Data The Management of Data, is the generic term for all activities related to the lifecycle of
management data (gathering, storing, exchange, distribution, protection, retention, archiving), the
governance and usage of data to the benefit of all stakeholders: customers, regulators,
investors and internal staff.
Entity An entity (being a country or domain(s) (like Group Services)) is a collection of Tribes,
usually with a logical interrelation on a common purpose.
Epic An Epic is a large scale bank initiative that is delivered in one or more
QBR cycles. It represents value for a stakeholder. It requires 3-12 months to be
completed.
Event Timebox with a defined topic, participants and cadence.
Feature Reflects value that fulfil some user and stakeholder need that can be delivered within
one to six Sprints. A Feature should be demo-able during a Feature Review meeting.
Impediment Anything that keeps the Squad from getting work to Done.
IT asset An IT asset is any company-owned information, system or hardware that is used in the
course of business activities.
Kanban Kanban is a Japanese term for “signboard” that indicates “available capacity (to work)”.
It is a way for Squads to visualise their work, identify and eliminate bottlenecks and
achieve dramatic operational improvements in terms of throughput and quality. It is a
method to gradually improve whatever you do – whether software development, IT /
Ops, Staffing, Recruitment, Marketing and Sales, Procurement.
Lean Lean principles are at the core of Agile and Scrum. They include: identify value,
eliminate waste, create flow, establish pull and seek perfection.
Objective and OKR is a method of defining and tracking objectives and their outcomes. Its main goal
Key Results is to connect company, team and personal objectives to measurable results, making
people move together in the right direction.
Release A release is the distribution of software components into Production.
Roles Roles describe the work function or job responsibilities of a person. A person can have
multiple roles.
Scrum Scrum employs an iterative, incremental approach to managing product development

increasing speed and flexibility. Scrum accepts that the problem can’t be fully
understood or defined, focusing instead on maximising the Squads’ ability to deliver,
respond and adapt quickly. The process includes a feedback loop between the business
(PO) and the Squads output.
Sprint A continuous and consistent time-box of maximum two weeks during which the
“Done” Increment and other Artefacts are delivered.
Sprint Goal The Sprint Goal is an objective set for the Sprint that can be met through the
implementation of Product Backlog.
Story Describes a value that can be delivered by a Squad within one Sprint.
Story points A Story point is an estimate of the relative complexity of a Story.
Task A Task is the lowest level unit of work. During Sprint Planning, Squads break Stories
down into Tasks, the individual actions that are required to deliver a Story in a specific
Sprint. Tasks are typically assigned to one person and must be delivered in a single
iteration. Tasks provide a way for the Squad to agree on exactly who is going to do
what to complete the Story.
Theme ING’s Change Portfolio (Transformation Programs and Local Change) is decomposed
into underlying Themes (also known as initiatives) representing one to five year(s),
connecting the dots between Strategy and execution.
Time to Time to volume is a metric that measures the time to develop a new product from
Volume concept to launch and achievement of commercially relevant business volumes.
Value Stream Is a long-lived series of steps used to deliver value, from concept or customer order to
delivery of a result for the customer.
Velocity At the end of each iteration, the Squad adds up effort estimates associated with Stories
that were completed during that iteration. This total is called velocity.
Velocity Chart A chart that provides the Squad insight into their velocity and predictability, using Story
points committed and Story points realised over multiple Sprints.
Appendix A – Background
Short history
Until 2010 project and program management was based on the waterfall model and Prince II, and was
applied at a large scale as a project and program management framework. The waterfall model is a
sequential process where the delivery of IT goes through fixed stages: concept, initiation, analysis,
design, build, test, deploy and operate.
The waterfall model and Prince II within ING was based on two core concepts:
1. First time right: Teams know what to build, how to build it and nothing changes along the way.
Documenting requirements is done upfront and only once the complete set of requirements are
defined the design and build activities may start. However, in practice teams discover what to
build, how to build it and many things change along the way.
2. Segregation of duties: Different roles fulfil their Tasks at each stage of the process. The project is
handed over from each department the other from phase to phase where the output of each
phase is input for the next. However, as a consequence many handovers exist in process of
delivery of IT which causes waste (e.g. information losses, delays, errors, etc.)
Since 2010 ING adopted a new method for software development based on Scrum and Agile values
and principles across various entities, which led to the creation of the Agile@ING framework. The
Agile&ING framework consists of:
 A guidance document explaining 4 stages in reaching Enterprise Agility: Dev, DevOps,

BusDevOps and Enterprise Agility
 A Buzz community Agile@ING, serving as a platform providing access to: good practices,
role-descriptions and training material
The Agile transition towards Enterprise Agility for ING Domestic Bank Netherlands has covered three
phases
 Dev (2010) - Internet / Mobile teams started to experiment with Scrum

 DevOps (2014) - Integration of Dev and Ops within IT by having only one manager per
DevOps team
 BusDevOps (2015) - Organise IT and Business into Tribes and Squads
Other entities within IT at ING followed similar steps…
 ITS Belgium started Scrum with 20 pilot teams back in 2013 and launched a Scaled Agile
program in 2014
 OIB Group Services, Wholesale Banking Services and Infrastructure Services also merged
development and operations engineers in teams and brought them under single
hierarchical management within their entities in 2014. In some cases business roles have
been integrated in the team set-up as well
In all entities where the WoW has evolved from waterfall / Prince II towards Agile / Scrum the following
benefits are experienced
1. Shorter time-to-market for a faster response to changing client needs

 From large, extended projects to (much) smaller, short-cycle launches
 From large, complex departments to small teams
 From first time right to producing a fast minimum viable product and getting user feedback
2. Fewer handovers to empower and give space to individuals and teams

 From organisational silos to a purpose organisation
 From micromanagement to teams in aligned autonomy
 From a meeting-to-explain culture to a work-directly-together culture
3. More motivated, passionate and self-organised teams and employees

 From top-down management and control to appreciation for own initiative
 From status and grades to alternative forms of recognition
 From keeping quiet to giving and accepting candid feedback
Challenges in moving towards OAWoW in delivery
1. We were in different stages of transitioning towards Enterprise Agility
 For example, Domestic Bank Netherlands has already completed the transformation
towards BusDevOps whereas other entities have not yet adopted Agile and Scrum in IT Dev.
Many entities are still far from reaching DevOps with distributed IT Dev and Ops
 Even within entities that have made a lot of progress towards installing the Agile WoW,
teams are individually at different maturity levels and only a sub-set of teams are truly
mature and self-improving
 As a result, transitioning to OAWoW within IT at ING globally will take a lot of effort
2. We adopted multiple flavours of Agile and the way we work

 For example, Domestic Bank Netherlands has implemented “The Model That Works” based
on the Spotify Model (e.g. Tribes, Squads, Chapters) and Scrum, whereas Belgium has
implemented SAFe and Australia has implemented PACE
 Many of these flavours of Agile have a similar purpose and are based on the same
underlying principles. However multiple flavours result in differences in the way we work
and cause organisational confusion, misalignment, inefficiencies or even failures: especially
in areas where international / global collaboration is key (e.g. GTO global portfolio
management, ISR global software as a service, ISP global infrastructure)
 These multiple flavours of Agile and the way we work (in which we lack a common
language and process of collaboration) blocks us in reaching convergence, global
scalability and reduced time to volume
3. Initiatives that require multiple teams to collaborate faced persevering unaligned autonomy
 It is not always clear how we collaborate on larger initiatives. This leads to priority conflicts,
chaotic coordination, too many hand-overs and rhythms not being in sync
 Change is not always realised in an optimal sequence and sometimes important
dependencies are discovered too late, which requires re-design, re-work, and delays
 Satisfying business deadlines tends to come before structural improvements and removing
technical debt (regardless of how ‘ugly’ the short cuts are)
 Some ING entities (e.g. WB) have global product lines with complex, interrelated products
which need extensive and mostly long lasting guidance towards a coherent solution
 Across teams we lack a shared understanding in the way we set priorities. Too much time
is spent on planning and convincing each other that we should prioritise certain blocks of
work
Appendix B - Principles
The Agile Manifesto and Principles

The Agile manifesto and agile principles are valid on all levels: incremental, iterative, frequent delivery,
self-organising, bring work to the Squads, less is more, close collaboration between IT and business,
continuous improvement, fast feedback and fast learning.
We work and behave according to the Agile Manifesto. This means that we value:
We are uncovering better ways of developing software by doing it and helping others do it. Through this
work we have come to value:
 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Our OAWoW is based upon the 12 Agile principles:
 Our highest priority is to satisfy the customer through early and continuous delivery of
valuable products and services.
 Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
 Deliver working products and services frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
 Business people and developers must work together daily throughout the initiative.
 Build initiatives around motivated individuals and Squads. Give them the environment and
support they need, and trust them to get the job done.
 The most efficient and effective method of conveying information to and within a Squad is
face-to-face conversation.
 Working products and services are the primary measure of progress.
 Agile processes promote sustainable development. The sponsors, engineers, and users should
be able to maintain a constant pace indefinitely.
 Continuous attention to technical excellence and good design enhances agility.
 Simplicity--the art of maximising the amount of work not done--is essential.
 The best architectures, requirements, and designs emerge from self-organising Squads.
 At regular intervals, the Squad reflects on how to become more effective, then tunes and
adjusts its behaviour accordingly.
DevOps (CAMS)
The practice of IT operations engineers and IT development engineers collaborating in one Squad for
the entire service lifecycle, including design, development, test, change and production configuration,
monitoring and support.
 People and process first. If you don’t have culture, all automation attempts will be fruitless.
 Tools can start to stitch together an automation fabric for DevOps. Tools for Release
management, provisioning, configuration management, systems integration, monitoring and
control, and orchestration become important pieces in building a DevOps fabric.
 If you can’t measure, you can’t improve. A successful DevOps implementation will measure
everything it can as often as it can… performance metrics, process metrics, and even people
metrics.
 Sharing is the loopback in the CAMS cycle. Creating a culture where people share ideas and
problems is critical.
Scrum
Scrum employs an iterative, incremental approach to managing product development increasing
speed and flexibility. Scrum accepts that the problem can’t be fully understood or defined, focusing
instead on maximising the Squads’ ability to deliver, respond and adapt quickly. The process includes a
feedback loop between the business (PO) and the Squads output.
Our OAWoW within Squads is based on following “Scrum-by-the-book”. Across Squads we strive
towards reaching aligned autonomy in our OAWoW:
 ING Strategy leads to prioritised Themes, Epics, Features and Stories supported by a shared
rhythm and a shared process of collaboration
 Autonomy is important in order to respond and be agile. But we still work in the context of ING
and our goal is to serve customers. When multiple Squads work together on related Epics and /
or Features, they do so in an aligned rhythm with handshakes instead of handovers so we can
go faster supported by integrated road mapping to enable early detection and management
of dependencies
 Aligned autonomy means that we are organised in autonomous stable Squads with a clear
purpose. Aligned autonomy does not mean that Squads can do whatever they want, but it
means that Squads may solve the problem given to them the way they see fit. To do so
Squads need to be aware of the context of the problem. An important role for leadership in
aligned autonomy is providing this context.
Continuous Delivery
Continuous Delivery is the practice of automated build, test and deployment of software. There are five
principles at the heart of continuous delivery:
 Build quality in
 Work in small batches
 Computers perform repetitive Tasks, people solve problems
 Relentlessly pursue continuous improvement
 Everyone is responsible
Appendix C - OKRs
To break down large strategic Themes into manageable and clearly delineated chunks of work, Tribes
can use Objective & Key Results (OKRs):
 OKRs help to be ambitious and transparent, force to think, improve communication, provide
focus and enable measurement
 The methodology distinguishes between:
o Objectives, which are qualitative and aspirational goals (that are ideally ranked
amongst themselves). Objectives need to be:
 Very Ambitious
 Qualitative, focussed on output
 Inspire and are easy to understand
 Help to prioritise daily business
o and Key Results, which are quantitative and SMART indicators of the extent to which
the Objectives are realised
 Usually in ING the OKRs are formulated for a full year horizon and updated on a quarterly basis
in Quarterly Business Reviews (QBRs)
 The Objectives at Tribe level are based on company-wide strategic themes, joint MT priorities,
MTP targets and the Tribe’s purpose (which of course are all linked to each other)
 The Tribe Key Results are cascaded to the Squads. Based on their own purposes, Squads
determine to which Tribe Key Results they will contribute and how. They do so by formulating
Squad Key Results and mapping their Epics, Features, Stories to them
 This cascade establishes a clear, explicit link of value contribution upstream and work division
downstream.
This figure shows a simplified illustration of how this cascade works:
Appendix D – Squads and Tribes – reporting lines
Level Job function Hierarchically reporting to..
(IT) Development Engineer IT Chapter Lead
Squad (IT) Operations Engineer IT Chapter Lead
Customer Journey Expert Business Chapter Lead
Tribe Lead Entity’s leadership
IT Area Lead IT Lead / CIO
Business Chapter Lead Tribe Lead
Tribe IT Chapter Lead IT Area Lead
Domain Architect CoE Lead
Feature Engineer IT Chapter Lead
Agile Coach CoE Lead
Road manager CoE Lead
Cross-Tribe Enterprise Architect Chief Enterprise Architect
Local Portfolio manager CEO

One Agile Way of Working model

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

One Agile Way of Working model

Uploaded by

Copyright:

Available Formats

One Agile Way of Working

Tribe / Squad approach: how IT and business

0.9 June 2016 Approved by Project Management Framework –

1.0 Beta October 2016 Author: Beta version

1.0 December 2016 Author: Unify IT Including processed feedback on

1.1(1) April 2017 Author: Unify IT Including processed feedback on

1.2 August 2017 Author: Unify IT Including processed feedback on

1.3 December 2017 Author: Unify IT Including processed feedback on

The context of this document

The content of this document

How to use this document

Setting the scene 5

One Agile Way of Working for delivery 7

From ING’s Vision and Strategy to Themes 18

From Themes to Epics 23

From Epics to Features 29

From Features to Stories 32

From Stories to Value 37

Continuous Delivery Pipeline provides central tooling and generic deployment

How to read this document?

Autonomy is strived for by minimising

Alignment is key to ensure that Spotify Engineering Culture, Henrik Kniberg

Teams deliver value through regular

An incremental process is one in which a

An iterative process makes progress through successive

A Theme is broken down in multiple Epics: large scale bank deliverables

An Epic can be broken down in one or more Features. A Feature reflects

Organisation and roles view

In order to support our ability to respond on rapidly changing market demands

We looked at other organisations that have been successful in adopting an

We use the following motto to reach aligned autonomy:

Roles at Squad level

The Customer Journey Expert:

A Tribe is a collection of Squads with a Tribe Lead, organised around a

Roles at Tribe level

Role at Chapter level

2.3.4 Center of Expertise (optional)

Roles at Center of Expertise level

Members of a Center of Expertise,

2.3.5 Community (optional)

2.3.7 Additional roles

For Epics within a complex IT landscape, the Feature Engineer:

Distributed Tribes / Squads in a Global Organisation

A distributed Tribe should…

Be distributed in up to three locations – Tribes are concentrated in up to three1 locations each.

And distributed Tribes and Squads should…

1 Based on organization design principles of ING

And for distributed Squads this means…

2 Based on organization design principles of ING

Why emphasize the need for IT Health?

What do we mean with IT Health?

Who owns IT Health?

For prioritization and governance, the ING Transformation Portfolio composes of

The way of managing Themes depends on where they originate from:

3.1.1 Category 1: Transformation Programs

3.1.2 Category 2: Local Change (incl. business as usual)

3.2.1 Quarterly and Monthly MBB

3.2.2 Change Investment Committee (CIC)

3.2.3 Monthly 2:2 meeting

3.2.4 Quarterly and Monthly Transformation Delivery Team (TDT) sessions

The roadmap (a.k.a. Epic wall):

3.3.2 Obeya Room (Transformation Program)

The Transformation Obeya Room has the