Launching Agile in A Team: Agile White Book - AXA Emerging Markets EMEA-LATAM

Chapter 2
LAUNCHING AGILE IN A TEAM

V1.0
27 Agile White Book – AXA Emerging Markets EMEA-LATAM

Contents
WHAT I WILL LEARN IN THIS CHAPTER? ...................................................................................................................................................................... 30
THE AGILE FRAMEWORK ..................................................................................................................................................................................... 31
THE BENEFITS ....................................................................................................................................................................... 31
AGILE VALUES AND PRINCIPLES ................................................................................................................................................ 34
MITIGATE RISKS .................................................................................................................................................................... 36
USE THE AGILE READINESS OF THE TEAM CONTEXT ...................................................................................................................... 38
GET THE SPONSORSHIP OF AN AGILE CHAMPION......................................................................................................................... 40
OUR CHOICE: THE SCRUM FRAMEWORK .................................................................................................................................... 41
SCRUM VALUES ..................................................................................................................................................................... 42
FIND THE RIGHT PEOPLE ....................................................................................................................................................................................... 44
LOCATE AN AGILE COACH (AC) ................................................................................................................................................ 45
FIND A PRODUCT OWNER (PO) ............................................................................................................................................... 46
FIND A SCRUM MASTER (SM) ................................................................................................................................................. 47
LOCATE PEOPLE FOR THE DEVELOPMENT TEAM (DT)................................................................................................................... 48
LOCATE PEOPLE FOR THE EXTENDED TEAM (ET) ......................................................................................................................... 49
CLEARLY IDENTIFY WHO YOUR STAKEHOLDERS ARE ...................................................................................................................... 50
ORGANISE THE AWARENESS SESSIONS .................................................................................................................................................................... 51
ORGANIZATIONAL ROLES ........................................................................................................................................................ 51
CORE ROLES ......................................................................................................................................................................... 51
TECHNICAL TRAINING ............................................................................................................................................................. 52
START WITH THE BASELINE STAGE ........................................................................................................................................................................... 53
ENVISION THE PROJECT ........................................................................................................................................................... 54
CREATE THE ROADMAP .......................................................................................................................................................... 55
HIGH LEVEL VIEW BACKLOG .................................................................................................................................................... 57
PREPARE LOGISTICS................................................................................................................................................................ 58
RUN A PHASE ZERO ............................................................................................................................................................................................. 60
TEAM WORKING AGREEMENTS................................................................................................................................................. 60
DEFINITION OF READY ............................................................................................................................................................ 61
DEFINITION OF DONE ............................................................................................................................................................. 62
BUSINESS VALUE DEFINITION .................................................................................................................................................. 63
PRODUCT BACKLOG CREATION................................................................................................................................................. 63
YOUR VERY FIRST RELEASE PLANNING ....................................................................................................................................... 65
TAKE AWAY .................................................................................................................................................................................................... 66
CHECKLIST 2.1 .................................................................................................................................................................................................... 67
CHECKLIST 2.2 .................................................................................................................................................................................................... 69
CHECKLIST 2.3 .................................................................................................................................................................................................... 72
CHECKLIST 2.4 .................................................................................................................................................................................................... 74
CHECKLIST 2.5 .................................................................................................................................................................................................... 77

Launching Agile in a Team
Agile requires certain stages in order to assure

success. The ground has to be prepared in advance
and individuals to be aware how agile works and be
ready for the change.

What I will learn in this chapter?
AGILE IMPLEMENTATION
LEARN HOW TO KNOW WHAT

BENEFITS OF - create the right context. AWARENESS KNOW HOW
IMPLEMENTING - Locate an Agile Coach.
SESSIONS TO TO START A
AGILE - Find people for the
ORGANISE PROJECT
project.
- Identify stakeholders.
I know the clear steps to create a product people love.

I know the emphasis for a successful Agile project.
project.implementation
I know what the baseline & phase cero stages are.

THE AGILE framework
We are going to learn some clear steps to start an Agile project and create a product that your
customers will love and enjoy. We have seen in the Chapter 1 that there are principles, values
and practises, all of which are part of the framework. Now, we will see how to consolidate them
by starting an Agile initiative.
The idea of this chapter is to help you connect the dots and gain a clear understanding of the
benefits and a concise way to make things happen.
THE BENEFITS
We first encourage people focusing on some key factors at the time of inspiring a shift to the Agile
paradigm.
These are some of the Agile benefits I see:

THE AGILE framework
Let’s try to understand why and where to place the emphasis to have a successful Agile
implementation from the very beginning; we have chosen 7 areas that are critical:
Focus in business value - the main motivator is Business Value; everything is

prioritised by it and the main objective is placed on value creation.
Quicker delivery and feedback - quicker feedback from clients and end-user
(improving Time To Market) comparing to other traditional approaches. Working in
iterations is a form of regular risk management. Quicker delivery increases customer
satisfaction and minimise handoffs.
Greater Return on Investment - ROI is improved by explicitly comparing different

objectives in terms of value vs. cost.
Increased productivity - increased speed of development and less rework thanks to

collaboration between Business and IT and inside the development team, self-
organization and synergies, focus on priorities and reducing Work in Progress, continuous
improvement and automation of IT work.
Higher quality - high quality, simplicity and maintainability are achieved through
techniques such as Continuous Integration (see more on chapter 12) with developer
regression testing, test-first development, pair reviews and refactoring.

THE AGILE framework
Team morale - people prefer Agile because they can collaborate and self-
organize with others to create better products, they can be more creative in
finding solutions and bring results in a shorter time, creating a product they love.
Constant learning – the most effective organizations promote a learning-

oriented and continuous improvement environment for their staff and it is a
key factor in Agile.

THE AGILE framework
AGILE VALUES AND PRINCIPLES
There are many drivers in the modern business environment to rethink how we work and start
following values to keep individuals aligned with the same goals and objectives.
Agile values are all about individuals and

interactions, working software,
customer collaboration and responding
to change.
Agile values give you an answer in times

of uncertainty.
We have seen many cases where people were doing some practices (like iterations, automated
regression testing, pairing, etc.) and with relatively good communication inside the team but the
problem was many times that even everyone believed they “were already Agile”, they were not
delivering valuable and potentially shippable increments frequently and consistently
(iteration after iteration), nor were changing the way of working in order to improve (not
adapting to the changing business needs, working Business and IT together or keeping
everyone´s motivated).
That is why is critical that the Agile values and principles are understood and set in place in
order for people to go ahead (read more about them in Chapter 3).

THE AGILE framework
After the values and principles have been shared by everyone, the focus should be placed on
certain areas to make sure Agile implementation is successful. This is what we call the Agile Star.
Based in The Agile Star concept, www.proyectosagiles.org
These 8 areas in here are important to discuss in order to start moving the wheel and making people
aware of the parts to improve.

THE AGILE framework
MITIGATE RISKS
A number of risks need to be mitigated before implementing Agile. Most of them are cultural
or people factors - a typical outcome when approach changes.
I generally spend energy on these actions to minimise the impact/risks and positively re-focus
people on good practices/behaviours:
- Make sure management understand what Agile is and actively sponsor it. In order for
Agile to work, you need support from certain key stakeholders of the company.
- Have a strong reason to justify why you want to use Agile. Know clearly the problems to
solve or how the company can benefits from implementing it.
- Analyse people and idiosyncrasy, especially in the first areas to start, find early
adopters and make sure they align to the Agile principles.
- Remember that Agile requires the people´s willingness to move in that direction, it can’t
be dictated (but can be influenced).
- Find open minded people as they are needed in order to change things. Individuals
curious about new things, willing to learning and collaborate is a must.
- Be sure that the project is relevant for the Business, as you’ll need guaranteed
dedication and commitment from the person who will hold the Product Owner role.
- Be careful of dependency on third parties as they can add risks and tension.
Understanding them in advance can give you an integral vision of the problem.

THE AGILE framework
As you can see, Agile place a different and new challenge to the individuals and organisation to be
addressed; there is exactly there where the values and principles come into place. That is why we
strongly advise you to involve an experienced Agile Coach to help during this initial stage. He can
bring expertise and ideas on board and simplify the whole process.
A good idea is to start with an Agile methodology pilot, but if you do so, make sure you don’t
select a project that will be extremely difficult with high probabilities to fail as your
purpose is “test & learn” on the methodology and start with a successful experience you can
communicate.
Look for a Business individual and an IT team with a previous track of positive collaboration
between them, in business fields and technologies they already know, open minded and
willingness to try new things.

THE AGILE framework
USE THE AGILE READINESS OF THE TEAM CONTEXT
To be sustainably responsive you need to balance the way you work, the Team you have, the
business you are partnered with, and the technology you use.
To connect all the dots between practises and reality, you can use the following principles to assist
you identifying the more important aspects to remediate in an initiative.
You can use the previous Readiness criteria as a chechlist and score the initiative from 5 (fully
“Agile-ready”) to zero (not recommended to be developed under Agile principles). Note that not all
criteria need a “high ranking”; though improving them will produce better results and impacts.

THE AGILE framework
Agile is a journey where you learn and improve continuously. Readiness to assessment can make
visible to everyone where they are and to decide what is the next to improve and what the
steps will be. Lack of skills & open spaces, team members continuously shifting, extremely busy
people doing multitasking or not having the right cohesion between IT and business can be
important risks to target and mitigate.
You don’t need to start with a perfect

context; you can fix it during the project. For
example, don’t wait for electronic boards, a
Scrum task board and some excels are
enough to start.
Open the checklist “Understand the change” to help you do all

the work to understand the Agile mindset.

THE AGILE framework
GET THE SPONSORSHIP OF AN AGILE CHAMPION
You know enough about the initiative context and are convinced that it can be a reality. The next logical
step is to focus on making sure that it can be achieved considering the organisational context.
For that, you would need to locate a Sponsor who believes in the change and is able to make things
rolling and real; we call this individual Agile Champion.
Are you wondering what an Agile Champion does?
o He is a high level Manager in charge of the Agile Adoption success. He makes things
happen at an organizational level, so he has the authority to work with the leadership
team and middle management and aligns them. He intervenes with potential people to
alleviate their fears and concerns.
o He is an experienced person in identifying the tasks or changes that might be required

to transform the organization, i.e. identifying potential stakeholders.
o He creates and communicates the transformation vision and strategy and aligns
them with the change drivers.
o He establishes a timeline for affecting the change.
An Agile Champion also helps managers understand why the change is important. He sells the concept
and is an Agile evangelist (showing more than telling).
He also works with management to remove roadblocks, reduce complexity and unnecessary activities
that don’t help to produce value. Finally, he makes sure people get use to ask for help/support when
they need.

THE AGILE framework
OUR CHOICE: THE SCRUM FRAMEWORK
Our approach is based on Scrum as it is the most widely Agile framework adopted in the world, it
is the “de facto standard” for project management, with lots of knowledge resources and
experiences in various fields. Something important for you to know is that Scrum offers a whole set
of the values and practices that are fully needed from the very beginning and never optional.
What we do is little by little improving the practices and here the support of an Agile Coach that
knows how to work in this way is critical.

THE AGILE framework
SCRUM VALUES
Scrum reflects the spirit of the Agile manifesto, its support for individuals and interactions,
working software, customer collaboration and quickly responding to change.
Scrum values are used at Team level and promote inclusiveness of people to work together as a
single unit moving towards a common goal and a shared commitment, it focuses on rapid
cycles, time to reflect and improving what is done. Everything we do is based on Agile values
and principles.
Focus
Respect Courage
Scrum
values
Commit Openne
ment ss
Scrum also provides a clear set of additional values to be followed when developing a product and
help mitigating risks resulting from erratic behaviours on the system.

THE AGILE framework
It is now time for you to take a look at them and think how they can be implemented in the whole
team/people around you:
Focus - because you focus on only a few things at a time, you work well together
and produce excellent work. In this way, you always deliver valuable items sooner.
Courage - as you are not alone, you feel supported and have more resources at your
disposal. This gives you the courage to undertake greater challenges.
Openness - as you work together, you practice expressing how you're doing and
what's in your way. You learn that it is good to express concerns so that they can be
addressed.
Commitment - because you have great control over your own destiny, you become
more committed to success.
Respect - as you work together, sharing successes and failures, you come to respect
each other and to help each other become worthy of respect.
It is generally a good practise to encourage discussion –but never to impose it- to allow people to
know their benefits.

FIND the right people
In this stage, you need to identify the different roles and find the right people that will work on your product (collaborative, open
minded, eager to test & learn, with willingness to try the change and with enough product knowledge and technical skills). Be
aware that some of the roles do not exist in the same way as in the traditional approach.

LOCATE AN AGILE COACH (AC)
It is highly recommended you get the support of an Agile Coach –at least- in the initial stages.
She is the “living book” of Agile. She can bring assistance in many areas and help everyone
develop not only new expertise but gradually changing mindset and breaking inertia. An Agile
Coach can also provide valuable feedback and advice to you or people you are involving in the
project.
All right, this is what I do:
- I am a coach only and not part of the team. I am not in

charge of project delivery but team development under
Agile principles, in order to get the expected benefits.
- I am often from outside the delivery organization and

objective in guidance without personal or political
considerations.
- I am experienced in change management as well as in

methodical implementing Agile techniques and monitoring
progress.
The support of an Agile coach is particularly useful from the beginning of the implementation
to identify adoption risks, assess the context readiness, help to find the right people, do the
awareness sessions & training, and facilitate the Product Backlog inception (in order to foster
value generation) and other specific Scrum meetings, before transferring the responsibility to the
Scrum Master.
If the team is already working in some projects, the Agile coach is also useful as helps Teams and
members with values, practises and techniques to make sure the product development is
successful.

FIND A PRODUCT OWNER (PO)
This role owns the product on behalf of the company and is a single person, not a group or
board. This is crucial step as Product Owner is the responsible of getting agreement on business
needs of the project.
I am the only representative of all stakeholders, I regularly

meets customers and also invite developers to do so. I have
deep business knowledge and the authority&recognition
to the last decision about the product through the Backlog
and enough availability to collaborate with the
development team.
I am always looking to maximise the ROI.

FIND A SCRUM MASTER (SM)
Scrum Master is responsible of developing a high performance, motivated and self-organized
teams. She can come from any background or discipline (i.e., engineering, design, testing, product
management, social work, etc.) but must have a great Scrum understanding and hold social
skills.
These are some of my responsibilities:
- Empowering and shepherding the team.
- Removing impediments.
- Keeping the process moving.
- Helping the Product Owner solve some

questions about Scrum.
Check if there is any current Scrum Master in the organisation that can mentor a new Scrum
Master, especially in the initial phases, when the Product Backlog is created.

LOCATE PEOPLE FOR THE DEVELOPMENT TEAM (DT)
It is time now to focus on the people who will be in charge of analysing, designing, coding and testing
the product and working hand-to-hand with Business. Members will be working in a team on
consecutive initiatives or projects with their colleagues for months (preferably some years).
Your first target should be individuals who are:
 Fully available.
 With previous experience on the product to be developed / business domain (or similar).
 With wide knowledge of the technologies to be presumably used in the product and/or
with the technical training needed.
 Get along.
We do the work of developing the product. We are

programmers, testers, designers, writers, and
people who have hands-on roles in product
development. These are some of our responsibilities:
- Estimating size of backlog items and providing

a solution.
- Converting Product Backlog Items into “ready

to ship” functionalities.
- Tracking own progress.
- Think on how to improve our process.

LOCATE PEOPLE FOR THE EXTENDED TEAM (ET)
Identify experts that have to collaborate part-time and with direct communication with the
Development Team (Architecture, Security, Infrastructure, User Experience, etc.). They will be your
point of contact, you don’t want to re-explain our projects every time you contact a functional area and
they will work with us from the beginning on the project.
I am an expert who collaborates on part-time

basis and have direct communication with the
Development Team. I am a permanent part of
the Team.
They will be “your friends” in other departments; they will help our team flow and get things done for
us in their areas.

CLEARLY IDENTIFY WHO YOUR STAKEHOLDERS ARE
You should clearly identify who the potential clients and initiative stakeholders are as it helps you
determine a clear Vision, establish your Business Goals and define what Business Value is for
them.
I am everyone who has a real interest in the project. I can be a

direct manager of the Team members, the people providing
funding for the project, a group of users, etc. This is what I do:
- Work with the Product Owner to bring ideas to the Product

Backlog.
- Attend Sprint Planning meetings to provide feedback and

expertise.
- Provide direct feedback to the Team during Sprint Reviews.
- Avoid distracting the Team during a Sprint — after the

Team has made a forecast of the achievable work in the
Sprint.
Remember to get people take ownership on what each Scrum Role entails for them.
Open the checklist “Finding the right people” to make sure you are not forgetting
anything.

ORGANISE the awareness sessions
All people involved in the project require different kinds of initial basic explanation on their
roles and the Agile Coach can do it. This is a crucial step as it maps Agile terminology and
concepts on all participants, identifies worries, promotes initial alignment and helps build a
successful culture.
It is recommended that the awareness sessions are done even if some of the people were working
using some Agile “flavour” before.
Workshop with the organizational part involved (Managers, HR,

etc.) to make sure they understand the Agile concepts and
ORGANIZATIONAL foundations.
ROLES
Workshop to align Business Stakeholders and P.O. with Agile

benefits, values, principles, practices and their duties.
CORE ROLES Workshop for Scrum Master, Project Manager.
Workshop for Development team.

ORGANISE the awareness sessions
TECHNICAL TRAINING
Lack of technical skills should be detected and targeted in this stage as it can bring initial risk to the
project. You should have in mind that Agile Development Teams are cross functional therefore they
could require an additional training to make sure you have the require skills in the team.
Complete the checklist “Awareness Sessions” to make sure you don’t forget any
training.

START with the baseline stage
It is essential that Business and IT start working together to set a main goal and clearly
establish what are the business objective and its context. This should be done in two steps:
The project has to be envisioned by drawing a high-level list of ideas/goals.
Ideas should slowly be taken down into more detail and it is here where the roadmap is
created, generally following these parts:
 A Roadmap, where high level-view goals are defined/reviewed with all the desired
releases and a timeline (for example to help evaluate the Business Portfolio), is
created.
 A High-level View Backlog is created. Vision of the sequences of product features

to be delivered on Epic level. You can also define milestones, which are significant
events or achievements (for example to help start coordinating the initiative at a
Portfolio level).

ENVISION THE PROJECT
Product Owner and Stakeholders need to have a clear vision of the project. That vision might
help stakeholders pass the elevator test - the ability to explain the project to someone within
two minutes (including information about the customer, product name, key benefits and
primary differentiation).
Once everyone agrees and the vision is ready, all the parties should establish a concise definition
of what is important for the company in the coming months or what we call Roadmap.
Roadmap
Elevator
Test

CREATE THE ROADMAP
Once P.O. and Stakeholders have a vision and an initial business value definition, it is time to
create a Roadmap.
Extracted from http://www.romanpichler.com/blog/agile-product-roadmap/
This focuses on creating a very high level medium/long-term goals list that is useful to steer
the direction of travel for your product, and to set expectations within your company/client. It also
helps keep the balance between strategic developments and day-to-day requests and set
clear expectations.
We can build a roadmap simply by setting a time period for each high level goal, or strategic
development initiative.

This is what a Roadmap contains:
- Identification of scope and High level Goals in the short, medium and long term.
- Identification of milestones (and possible releases).
- Have the items in a time-line following some order criteria.
- Give a sense of proportional distribution.
- Demonstrate where your people, resources and budget are being allocated.
- Consider possible risks mitigation.
Make sure everyone agrees with it and make it visible. The Roadmap is an excellent
tool to manage expectations.
Open the checklist “Creating a Roadmap” to make sure you know

how to create a Roadmap.

HIGH LEVEL VIEW BACKLOG
Once the previous part is done, you need to start working on the second which is producing the
High Level View Backlog.
Extracted from http://www.romanpichler.com/blog/agile-product-roadmap/
The process is generally done incrementally and involves a number of meetings/workshops. The
Roadmap and High Level View Backlog mitigates the conflict between viewing the roadmap
features as commitments.
A High Level View Backlog contains the following information:
- A prioritised list of smaller goals to be achieved in the short and medium term (a relative
value score can be used).
- Most important features (high level requirements) for the company/client and/or that can be
achieved quicker.
- Indication of backlog items size: big, medium or small (a relative cost score can be used).
- Some dependencies, risks and mitigations.
- Some initial high-level metrics to make sure that everyone understands what is
targeted/expected by each goal and to verify what has been achieved.
- Elements blocking other areas of the company from moving faster.

PREPARE LOGISTICS
As there are organisational processes than can take time as team logistics, start asking for:
 Physical space for the Development Team to sit together.
 Scrum Taskboard to ease joint project view, facilitate communication and creation of synergies
inside the team.
 White Board for developing ideas.
 Ability to book a specific room for meetings and workshops.
 Access to ALM tools integrated with Continuous Integration and automated testing systems (If
already available, not necessary for starting to work in Agile, but they help).
 Prepare Agile Coach logistics (desk, internet connection, access to building, etc.).
Open the checklist “Preparing Logistic” to make sure you know

how to prepare the logistic.

Get everyone into the Training
Before starting with the next phase (phase zero), all members (P.O., S.M., Development Team,
etc.) should do training on Agile values, principles and practises. Usually a one-day workshop
is sufficient to start experimenting; games and simulations can be used as well. They will be
strengthened by means of “training on the job” by the Coach during the first iterations in the own
reality that the team has to face.
Vocabulary, business values and practices need to be aligned

across the team. Cooperation of the team members with the
business is the key factor of the success of the project.

RUN a phase zero
A phase zero sets the foundation for the project and makes sure everyone is on-board, fully
collaborating and aligned on what to build. This includes the rules for the coming initiative to be
followed by everyone as well as the creation of the Product Backlog.
First we will focus on the required agreements and later learn about the Product Backlog.
TEAM WORKING AGREEMENTS

The whole Team should state clearly, which rules/disciplines they agree to follow without fail, to
become more efficient and successful.
The Scrum Master may have to play the role of the meeting facilitator helping to come up with
the agreements, but it is the whole team that decides on the agreements themselves. Some
examples:
 “Everyone should collaborate with each other”
 “Everyone should ask for help if the problem is not solved after half an hour”
The list should be noted down by the Team and placed in a visible space across the working area. As
other sets of Agreements, rules and Definitions/good practises are typically evolved as a result of
Sprint retrospectives and other improvement events.

RUN a phase zero
DEFINITION OF READY
A Definition of Ready (DoR) is a criteria applied to every Backlog Element before it is accepted into
the development workflow. It is something that every element must get over before the
Development Team adds it to their to-do list.
The Agile team (Product Owner and Development Team) should agree on what it means
before starting to develop the Product Backlog.
The item will be ready to be

developed by us if it passed the
Definition of Ready we previously
agreed on.

RUN a phase zero
DEFINITION OF DONE
A Definition of Done (DOD) is an agreed-upon set of things that must be true before any
Backlog Item is considered complete; that might include:
 Code is well-written, the code is checked in.

 Code comes with automated tests at all appropriate levels.
 Code has been either pair programmed or has been code inspected.
 Diagrams or other documents where updated, etc.
This is something as simple as a checklist of the criteria which must be met before a Business
Feature or requirement is considered as "done".
Typically it expresses what is expected to be done in terms of programming, testing and

documentation.

RUN a phase zero
BUSINESS VALUE DEFINITION
Before the Product Backlog creation, a clear definition of Business Value has to be established. This
includes prioritization criteria and forms of measuring how much business return will be obtained
from placing a specific feature on the market or delivering a part of the system to end users. They
also will help to determine what will be more important or “valuable” to be shipped next.
Remember that Business Value must be expressed in the language of the business and that
Stakeholders and Product Owner should fully agree with this definition. A relative value score can
be used.
PRODUCT BACKLOG CREATION

At this point it is time for all the Agile Team to create a Product Backlog, which is a prioritised
list of product needs and single source from which all requirements flow.
The main objective of this workshop is to identify characteristics that might be developed in the
project (having just the closest ones in greater granularity). The result is a Product Backlog
which is a prioritized list where Potential Releases are marked containing each a set of
functionality.
This activity is done by very collaborative workshops using flipcharts, white boards, etc. It is
important that this activity involves the whole team, stakeholders, additional technical people, etc.
Remember that the facilitator of these meetings is usually the Scrum Master.
Check chapter 6 “Agile Planning” for more details and specific techniques.

RUN a phase zero
These are some of the activities/outcomes I expect from these workshops:
 Identify functional and non-functional requirements.
 Estimate elements and know how much they will cost (a relative estimated score can be used).
Small items which offer faster return are allocated first.
 Identify any kind of dependencies and plan their resolution in specific Sprints.
 Check if spikes or prototypes are going to be used to reduce uncertainty in terms of feasibility,
estimation or expectations and where.
 Create solution models (architectural maps, domain models, etc.) and Impact Maps.
 Identify risks and mitigations.
 Have some initial clues about the product Interface, Graphical guidelines and Navigation map.
 Business and IT aligned with the releases scope and expected dates.
 Check what a Minimum Valuable Product (MVP) is.
 Establish the size of Sprints and an initial idea of what will be developed in each one
of them.

RUN a phase zero
YOUR VERY FIRST RELEASE PLANNING
Finally, a release planning workshop is run. It emphasises exclusively on the coming release and
makes any other required adjustment to the future or Roadmap in order to represent reality.
There is a catch in here which is that the First Release Planning has a special focus: preparing
the foundations for the project and define their scope.
As seen before, this can include creating solution Models and Impact Maps.
Check Chapter 6 Agile Planning for more details.

TAKE AWAY
REMEMBER
 Identify what is the shared need for the change to Agile.
 Align middle management to the Agile principles getting support of an Agile Champion.
 Accurately plan in detail only for nearby requirements/releases.
 Make sure you always produce in short iterations.
 Culture change management and Coaching are critical success factors.
DEEPEN YOUR KNOWLEDGE

Agile Implementation
Large Scale Scrum (LESS) - Adoption
BENEFITS
Priorities are based on Business Value, which is directly driven by its natural owner, the Business (not IT).
Time is spent only in crucial activities/important requirements
Quick feedback and flexibility even in late phases of development.
Early warning of problems, more visibility and more predictable delivery.
Business and IT Development Team working together and face-to-face improves performance.
Motivated people do incredible things.

Understand the change
Checklist 2.1
Version 1.0
DATE: __________
Audience
Target audience of this checklist is quite wide. It is applicable to anyone who is initiating or
participates in the change to Agile way of working.
Context
This checklist may serve as the roadmap for understanding the importance, mechanism and
options to change organization to be aligned with Agile values and principles.

Task Comments
Understand the change

I worked/organise some chats to promote the
understanding of benefits of tight Business
 and IT collaboration and face to face
communication.
I understand the advantages of a cross-

functional, stable, self-organized and
 motivated teams.
I know the benefits of rapid feedback cycles

 and how they can impact business.
I understand how I can apply the concept of

 Simplicity in product and technology areas.
I know the advantages of Scrum values and I

had a thought of how I could implement
 them.
I understand that changes are natural and

 acceptable (flexibility).
I have read and understand the different

 areas of the Agile Readiness tool.
I have read and understand the different

 areas exposed by the Agile Star.
I know and understand the risks when trying

 to implement Agile.

Find the right people
Checklist 2.2
Version 1.0
DATE: __________
Audience
Target audience of this checklist is quite wide. It is applicable to anyone who is initiating or
participating in the change to Agile way of working.
Context
This checklist helps to validate if all key-people needed to start transformation to Agile are
available (or will be available by the beginning of the change implementation).

Task Comments
Find the right people

I have identified the Agile Champion, confirmed
his responsibility on managing the Agile
 adoption and have informed about my initiative.
I and the Agile Champion have identified key

 people who are able to help.
I have identified an Agile Coach and I have

checked he has enough availability for this role
 in the project: 50% dedication during the 4 first
months for a 5 people development team.
I have identified the Product Owner and I have

checked she has relevant knowledge about the
 product or has worked in similar products
before.
I have checked she is a collaborative person

and she has the authority from Business to
 create an agreed ordered lists of priorities and
she has the final say on what to do.
I have checked she has enough availability for

this role in the project: has at least 20%
 dedication for a 5 people development team.
I have identified a Scrum Master and I have

checked he has enough availability for this role
 in the project: has at least 50% dedication for a
5 people development team.
I have checked he has the required soft skills to

grow a team, if he is not a person who will
 “direct” the team (instead of making them think
together) and if he is open-minded.
I have identified the required cross-functional

development team and his full dedication to
 constitute a team during several months
(preferable some years).

I have checked the development team has
relevant knowledge about the product or similar
 products (business domanain and technologies
involved).
I have checked they get along and which

 domain & technical training they need.
I have identified the extended Team, stable
experts that have to collaborate part-time from
the beginning (Architecture, Security,
 Infrastructure, User Experience, etc.). I got the
minimum dedication and commitment and it
was confirmed.
I have worked with the Stakeholders to have a
clear definition of Business Value. I have
checked that Stakeholders have an idea about
the following questions:
- For (target customers)
- Who (statement of the need or opportunity)
 - The (product name) is a (product category)
- That (key benefit, compelling reason to buy)
- Unlike (primary competitive alternative)
your product (statement of primary
differentiation)

Awareness sessions
Checklist 2.3
Version 1.0
DATE: __________
Audience and Context

This checklist will help to person responsible for Agile change to ensure, that awareness sessions
for all key-people were performed.

Task Comments
Awareness sessions
An awareness session have been carried out

for the Management and HR to align them
 with Agile values and principles and a high
level view of Agile was explained.
An awareness session has been carried out

for Business Stakeholders and Product Owner
 to align him with Agile values and principles
and a high level view of Agile was explained.
An awareness session has been carried out

for the Scrum Master and Project Manager to
 align them with Agile values and principles
and a high level view of Agile was explained.
An awareness session have been carried out

for the Development Team to align them with
 Agile values and principles and a high level
view of Agile was explained.
I have talked to the development team and

we have identified which skills are missing
 and the required domain and technical
training sessions have been arranged for
them.

Create a Roadmap
Checklist 2.4
Version 1.0
DATE: __________
Audience
If the development team and Scrum Master are available,
they can also assist in order to gain more visibility.
Context
Below you will find enlisted the steps to be run by Product Owner and stakeholders to elaborate
the roadmap for software product.

Task Comments
1. Vision and alignment
Stakeholders passed the elevator test and

have a clear vision about the product. This
high level vision should answer the following
questions:
- For (target customers)
- Who (statement of the need or
opportunity)
 - The (product name) is a (product
category)
- That (key benefit, compelling reason to
buy)
- Unlike (primary competitive alternative)
- Your product (statement of primary
differentiation).
An order of importance has been defined

 and it is clear for everyone.

Task Comments
2. High Level View Backlog

creation
Some very high level goals to be included
 in the Roadmap have been identified.
We have created a Roadmap and make it
 visible.
A list of high level goals has been created.

We have an idea of which elements are more
 important (a score can be used) and sorted
them out using a defined criterion.
Most important features have been placed
 on a timeline.
Some initial high-level metrics have been
 identified.
The final collaborative High Level View
 Backlog is made visible and accessible to
everyone.

Preparing Logistics
Checklist 2.5
Version 1.0
DATE: __________
Audience and Context

This checklist will help to person responsible for Agile change to ensure, that all preparations were
made and logistics for coaching activities was set-up

Task Comments
Common space where the Development

Team can sit together, including the Scrum
 Master. If possible, have an extra space for
Product Owner visits.
One whiteboard per team. Minimum size:

 100x140 cm.
A flipchart with sheets.

Whiteboard markers for each team. 4 colors:
 black, blue, red, green.
Sticky-notes of several colors – 4 minimum

 (preferably 3M). Sizes: 7,5 x 7,5 cm and 5 x
4 cm.
Adhesive tape per each team (preferably 3M
 Scotch tape).
Small round stickers like these.

A meeting room of 8 people capacity for
team regular meetings-workshops: ~ 4
hours for Sprint Planning, 1-2 hours for
Sprint review. 1-2 hour for Sprint
retrospective and 1 or 2 Product Backlog
Refinements sessions during the sprint. That
means ~ 12h meetings / Sprint / team. If you
 have two teams: 3 work days of room
bookings that will be spread in every 10 work
days. This meeting room needs a big
whiteboard and flipcharts. [If already
available, not necessary for starting to work
in Agile, but they help].

Access to ALM tools integrated with
 Continuous Integration and automated
testing systems.
An order of importance has been defined

 and it is clear for everyone.
Coach logistics
A desk for the coach, sitting together with

 the teams (e.g. in the same row of a team).
 Internet access for the coaching days.
 Access to building premises.


Launching Agile in A Team: Agile White Book - AXA Emerging Markets EMEA-LATAM

Uploaded by

Document Information

Original Description:

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

Launching Agile in A Team: Agile White Book - AXA Emerging Markets EMEA-LATAM

Uploaded by

Copyright:

Available Formats

Chapter 2

LAUNCHING AGILE IN A TEAM

27 Agile White Book – AXA Emerging Markets EMEA-LATAM

28 Agile White Book – AXA Emerging Markets EMEA-LATAM

Agile requires certain stages in order to assure

29 Agile White Book – AXA Emerging Markets EMEA-LATAM

LEARN HOW TO KNOW WHAT

I know the clear steps to create a product people love.

30 Agile White Book – AXA Emerging Markets EMEA-LATAM

These are some of the Agile benefits I see:

31 Agile White Book – AXA Emerging Markets EMEA-LATAM

Focus in business value - the main motivator is Business Value; everything is

Greater Return on Investment - ROI is improved by explicitly comparing different

Increased productivity - increased speed of development and less rework thanks to

32 Agile White Book – AXA Emerging Markets EMEA-LATAM

Constant learning – the most effective organizations promote a learning-

33 Agile White Book – AXA Emerging Markets EMEA-LATAM

Agile values are all about individuals and

Agile values give you an answer in times

34 Agile White Book – AXA Emerging Markets EMEA-LATAM

Based in The Agile Star concept, www.proyectosagiles.org

35 Agile White Book – AXA Emerging Markets EMEA-LATAM

36 Agile White Book – AXA Emerging Markets EMEA-LATAM

37 Agile White Book – AXA Emerging Markets EMEA-LATAM

38 Agile White Book – AXA Emerging Markets EMEA-LATAM

You don’t need to start with a perfect

Open the checklist “Understand the change” to help you do all

39 Agile White Book – AXA Emerging Markets EMEA-LATAM

Are you wondering what an Agile Champion does?

o He is an experienced person in identifying the tasks or changes that might be required

o He establishes a timeline for affecting the change.

40 Agile White Book – AXA Emerging Markets EMEA-LATAM

41 Agile White Book – AXA Emerging Markets EMEA-LATAM

42 Agile White Book – AXA Emerging Markets EMEA-LATAM

43 Agile White Book – AXA Emerging Markets EMEA-LATAM

44 Agile White Book – AXA Emerging Markets EMEA-LATAM

All right, this is what I do:

- I am a coach only and not part of the team. I am not in

- I am often from outside the delivery organization and

- I am experienced in change management as well as in

45 Agile White Book – AXA Emerging Markets EMEA-LATAM

I am the only representative of all stakeholders, I regularly

46 Agile White Book – AXA Emerging Markets EMEA-LATAM

These are some of my responsibilities:

- Empowering and shepherding the team.

- Keeping the process moving.

- Helping the Product Owner solve some

47 Agile White Book – AXA Emerging Markets EMEA-LATAM

Your first target should be individuals who are:

We do the work of developing the product. We are

- Estimating size of backlog items and providing

- Converting Product Backlog Items into “ready

- Tracking own progress.

- Think on how to improve our process.

48 Agile White Book – AXA Emerging Markets EMEA-LATAM

I am an expert who collaborates on part-time

49 Agile White Book – AXA Emerging Markets EMEA-LATAM

I am everyone who has a real interest in the project. I can be a

- Work with the Product Owner to bring ideas to the Product

- Attend Sprint Planning meetings to provide feedback and

- Provide direct feedback to the Team during Sprint Reviews.

- Avoid distracting the Team during a Sprint — after the