awb - 02 - launching agile in a team

27 Agile White Book – AXA Emerging Markets EMEA-LATAM

Chapter 2 LAUNCHING AGILE IN A TEAM

V1.0


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

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

BENEFITS OF

IMPLEMENTING

AGILE

LEARN HOW TO

- create the right context.

- Locate an Agile Coach.

- Find people for the

project.

- Identify stakeholders.

KNOW WHAT

AWARENESS

SESSIONS TO

ORGANISE

KNOW HOW

TO START A

PROJECT

I know the emphasis for a successful Agile project.

project.implementation I know what the baseline & phase cero stages are.


These are some of the Agile benefits I see:

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.


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.


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.

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.

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.

http://www.proyectosagiles.org/estrella-agil


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.


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.

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.

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.

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.

Scrum values

Focus

Courage

Openness

Commit ment

Respect


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.


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.


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.

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.


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 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.


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.


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.

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.


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 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.


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.


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.

They will be “your friends” in other departments; they will help our team flow and get things done for us in their areas.


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.


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.

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.

ORGANIZATIONAL

ROLES

Workshop with the organizational part involved (Managers, HR, etc.) to make sure they understand the Agile concepts and foundations.

CORE ROLES

Workshop to align Business Stakeholders and P.O. with Agile benefits, values, principles, practices and their duties.

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).


START with the baseline stage

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.

Elevator

Test

Roadmap



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.


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.


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.


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.


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 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.


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.

http://www.systemsatwork.co.uk/systemsatwork-blogs/the-agile-implementation-methodology/

https://less.works/less/adoption/index.html


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].

http://www.cubesmith.com/5x5roundstandard.JPG


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.

awb - 02 - launching agile in a team

Leadership & Management