beingagile

Agile Development Framework Global Training:

Shanghai, China
Pune, India
Detroit, USA
Burscheid, Germany
August and September, 2017
Being Agile:
An Agile Development Framework for Adient

Be like water,
my friends… we’re Agile at Adient
Bruce Lee

August 23, 2017

Introductions & Team Working Agreement

1. Have a Beginner’s Mindset

2. This is an interactive workshop .. Be Curious/Lean In

3. Please no electronic devices active during the session

4. We’ll have two 15 minute breaks & 60 minute Lunch

5. Please ask questions … or add them to the Parking Lot

6. Two volunteers to assist with updating the Scrum Board

and Burn-down Chart
 Objective:

Get In 18 minutes build the tallest free

standing structure using 20 sticks of
spaghetti, 3 feet of tape, 3 feet of string
and a marshmallow.
Rules:
1. Build the tallest structure.
2. The entire marshmallow must be on top.
3. Use as much or as little of the kit.
4. Break up the spaghetti, string or tape.
The Marshmallow Challenge
5. The teams cannot hold the structure when the
time runs out.

Instructions: 5-minute prep time

1. 18 minutes build time.
2. 10 minutes retrospective
Are you more agile than a kindergartener?

Kids on average prototyped their solution 5 times in 18

minutes…iterate and adapt!

Magic happens at intersections – where different

mindsets, approaches and skills collide
Source: Ted Wujec, The Marshmallow Challenge, TED April 2010
Why Agile?
Adient’s Mission

 To be the world-class automotive seating

supplier through leadership in cost, quality,
launch execution, and customer satisfaction

 We will leverage our capabilities to drive

growth, both within and beyond the
automotive industry

 We will constantly innovate and develop new

technologies to more efficiently and
effectively serve our customers and grow our
business
 Why Agile? AGILE
ADIENT’S STRATEGIC OBJECTIVES TECHNOLOGY ACCELERATORS AGILE

Industry 4.0 Mindset

Artificial Intelligence Framework

Advanced Analytics Training &

Coaching
SMAC DevOps &
Automation

In a world of increasing market volatility, shorter product life cycles, higher product complexity, and
global supply chains, Adient must have both the culture and capabilities to become more adaptive
and responsive to business trends and demand changes.

This is the only way we can consistently deliver on our strategic business goals as outlined in our 5
Year Marker.
Let the Agile Journey Begin
 Across Adient we’re starting to explore how technology accelerators like Industry 4.0 and advanced
Analytics can help us digitize our production cycle and effectively use data from product
development, services and manufacturing to accelerate decision making, increase efficiency and
lead to faster product improvements.

 Digitization-driven priorities are accelerating the use of Agile delivery methods in organizations—
more than 85% of organizations use Agile for the delivery of at least some part of their project
portfolios (Source: CEB).

 As Adient IT pursues digital transformation and transitions to a new operating model to maximize
business value, we will need to adopt an agile development framework to pick up the pace of
delivery.

 That is why we’ve started this Agile journey and developed a framework to help Adient IT define
and deliver value faster to our stakeholders.

 Agile will be the “preferred” solution development framework at Adient IT.

Adient’s Agile Framework

What is an Agile Framework?

An Agile Framework is a set of lightweight guidelines which allow you to
develop products or solutions in an incremental fashion

Scrum at Scale

 We have selected Scrum at Scale as Adient’s Agile Framework

 Scrum allows for context-driven solutions and processes
 Scrum at Scale is a minimal extension of the core Scrum framework
 It keeps the modular structure at the core of Scrum and also allows for scaling
of a Scrum implementation tailored to fit Adient’s needs and contextualized for
the disperse, global nature of our teams
What is Agile?
What is Agile?
 Is Agile …?
Chaos

No Documentation A Cult

Process? A Methodology?

No Architecture No Planning

A Fad An Approach?

A Framework? SDLC? No Discipline

Like Waterfall …
but iterative? Something we’re
already doing …?
Agile is…

a MINDSET
defined by values
guided by principles
and manifested through
many different practices
What is the Agile Mindset?
A mindset is an established set of attitudes. It is our consciousness, our way of
being, how we behave and what we value. It is our organizational culture.

The Agile Mindset emphasizes:

 Expect and embrace change
 Focus on rapid value delivery – identify the most important thing and get it
done
 When in doubt, defer decisions to the last responsible moment
 Get started as quickly as possible and learn as we go – inspect and adapt
 Only do what is needed and no more – the simplest thing
 Organize work so we get working product into the hands of our customer
as quickly as possible – focus on incremental, iterative development
 Organize the work to leverage the power of collaborating teams
Doing Agile and Being Agile

 Value Driven  Empowerment

 Problem Driven  Efficiency
 High Quality  Self Organizing
 Project Focus  Standardization
 Continuous Delivery  Autonomy
 Incremental  Process Driven
 Test Driven Development  Team Engagement
 Directing  Agile is a mismatch with
corporate culture, tends  Do Less, Deliver More  Continuous Improvement
 Control to be unsustainable
Doing Agile Saves Sentinel

March 2010 November 2011

FBI shut down biggest software Agile/ Scrum Saves
September 2001
development project in decades Sentinel
 $405M spent and only half  20 months to complete
9/11 Commission Report the project was complete.  5% remaining budget
blamed FBI’s lack of  1 year behind schedule  reduced contractors from
technological sophistication as  Independent analysis 220 to 40
one of key reasons why they estimated it would take  decreased FBI employees
failed to connect the dots prior another 6-8 yrs. to finish and from 30 to 12
to the attacks of 9/11. another $350M.

2006 Sentinel Spring / Fall 2010

• FBI decided to bring To Do In Process Completed
$451M approved
development in-house
Planned deployment for 2009
• Team switched to an
Agile approach

The FBI
Sentinel
Program
Being Agile: HP’s Transformational Agile & DevOps Journey

Delighted Innovation Relationships, Focus on

Customers & Autonomy & Designing
Stakeholders Engagement the Future

140% Increased “You need continuous Development

increase in capacity for integration or costs reduced
the number innovation continuous delivery from $100M to
of products from 5% to infrastructure to allow $55M freeing up
being 40% teams to go fast. Only funds for
supported then can teams work reinvestment
with enough
autonomy”
Doing Agile and Being Agile
Agile Leadership is key to Being Agile
Agile leadership is rooted in service.

Robert Greenleaf first defined and coined the

term ‘servant leadership’. In simple words, it
means the leader puts others before him,
with an aim to achieve results for the
organization by keeping in mind the needs of
the people.

Agile leadership at every level of the

organization and project is necessary for the
success of an Agile transformation.
Role of the Servant Leader- David Marquette Story
“Great leaders GIVE CONTROL.
They don’t take control. ”
- Capt. David Marquet

Turn this Ship Around Video

Servant Leader Traits

 Give Control, Competence, Clarity

 Acts with humility – don’t need to use their authority
 Creates trust – builds community
 Values diverse opinions
 Allows room for the team to learn
 Grows their people and develops teams
 Makes sure the team has the resources needed to get their
work done
 Removes impediments so the team can get their work done
Exercise: Agile Leadership
Break

15 minutes
Agile Manifesto
 A Short History of Agile
1999
Extreme 2002
Programming, User Test Driven
1994
Stories, Release Development
DSDM 1997 2003
Planning &
1992 Feature Continuous 2001 Lean
Crystal Driven Integration Agile Software
Methods Development Manifesto Development

1993 1999 2011

Refactoring Adaptive SAFe
System 2002
1995 Development Planning
Scrum Poker
The Agile Manifesto

core
values
principles
The Agile Manifesto: 4 Core Values

1
Individuals &
The Agile Manifesto: 4 Core Values

2
Working
Software
The Agile Manifesto: 4 Core Values

3
3
Cu
Collaboration
The Agile Manifesto: 4 Core Values

4
Responding
to change
The Agile Manifesto: 4 Core Values Summary

individuals and interactions

working software

customer collaboration

responding to change
The Agile Manifesto: 12 Principles

Our highest priority is to

satisfy the
P1
customer
through early and
continuous delivery of
valuable software
3
5
The Agile Manifesto: 12 Principles

Welcome changing
requirements, even
P2 late in the development.
Agile processes harness
change for the customer’s
competitive advantage
3
6
The Agile Manifesto: 12 Principles

Deliver working
software frequently,
P3 from a couple of weeks to
a couple of months, with a
preference to the shorter
timescale
3
7
The Agile Manifesto: 12 Principles

Business people and

developers must work
P4
together daily
throughout the project

3
8
The Agile Manifesto: 12 Principles

Builds projects around

motivated
P5 individuals. Give them
the environment and
support they need, and trust
them to get the job done
3
9
The Agile Manifesto: 12 Principles

The most efficient method

of conveying information
to and within a
P6 development team is
face to face
conversation
4
0
The Agile Manifesto: 12 Principles

Working software is
P7
the primary measure of
progress

4
1
The Agile Manifesto: 12 Principles

Agile processes promote

sustainable development.
The sponsors, developers
P8 and users should be able
to maintain a constant
pace indefinitely
4
2
The Agile Manifesto: 12 Principles

Continuous attention to

P9
technical excellence
and good design
enhances agility

4
3
The Agile Manifesto: 12 Principles

Simplicity; the art of

P10 maximizing the amount of
work not done is essential

4
4
The Agile Manifesto: 12 Principles

The best architectures,

P11 requirements and designs
emerge from self-organizing
teams

4
5
The Agile Manifesto: 12 Principles

At regular intervals,
the team reflects on
P12
how to become effective,
then tunes and adjusts its
behavior accordingly

4
6
The Agile Manifesto: 12 Principles Summary
1. satisfy the customer
2. welcome change
3. deliver frequently
4. work as a team
5. motivate people
6. talk, face to face
7. measure working software
8. maintain pace
9. excel at quality
10. keep it simple
11. evolve design
4
12. reflect regularly 7
Exercise: Stepping into Agile Values & Principles
Lunch

60 minutes
Scrum
“Scrum will help you fail in 30 days or less.”
- Ken Schwaber
Scrum Framework
Scrum is a lightweight Agile framework that allows software development to be completed in short
cycles known as sprints. It incorporates the principles and values of the Agile Manifesto.

It is especially well suited to projects with:

 aggressive deadlines
 high degree of complexity or uncertainty
 high degree of novelty (uniqueness)

Sprint Burn down

Chart
Scrum: Elements of Core Framework
SCRUM
SCRUM
Scrum is the basic building
block of Adient’s Scrum at
Scale Framework.

ROLES CEREMONIES ARTIFACTS

 Product Owner  Sprint Planning Meeting  Product Backlog


ROLES
Scrum Master
Scrum Team
CEREMONIES


Daily Scrum/Standup
Sprint Review Meeting
ARTIFACTS
 Epics
 Features
 Sprint Retrospective  User Stories
 Backlog Refinement  Sprint Backlog
 Sprint Burndown Chart

 Proxy Product Owner Scrum at Scale with

 Scrum of Scrums Distributed Scrum at Scale
 Proxy Scrum Master Distributed Teams
What is a Sprint?
A Sprint is a time boxed period during which committed work
must be completed and made ready for review

Sprints are generally 2-4 weeks as determined by Scrum

Master

Each sprint begins with a planning meeting. During the

meeting, the Product Owner and the development team
agree on what work will be accomplished during the sprint

The development team has the final say in determining how

much work can realistically be accomplished during the
sprint

The Product Owner has the final say on what criteria need to
be met for the work to be approved and accepted
What happens in a Sprint?
Sprint 0 (Initiation Sprint) Sprint 1 Sprint 2 to Completion
2-4 Weeks 2 weeks 2 weeks

 Identify Product Owner  Set up metrics e.g. burn down, velocity • Keep going – inspect & adapt
 Create Product Backlog  Begin Behavior-driven development (BDD)
 Create Project Roadmap by creating Quality Assurance plan with tool Activities done in every sprint:
 Onboard team (include DevOps resource in  Choose Quality Assurance and DevOps  Product Backlog Grooming (done
team) automation tools before sprint start)
 Create Social Contract/Team Working  Teams develop regular practices of Sprint Planning: Identify Sprint
Agreement identifying anti-patterns and correcting them Goal, Estimate Stories, Acceptance
 Establish environments and code check-ins in regular retrospective Criteria, Interdependencies
protocol, CI/CD foundations like Daily Stand-up
agreements on build frequency and Activities done in every sprint: During Sprint: address
branching practices  Product Backlog Grooming (done before impediments, write code, build
 Schedule all ceremonies on cadence, sprint start) product / develop solution, quality
including backlog refinement with entire Sprint Planning: Identify Sprint Goal, assurance
team. Estimate Stories, Acceptance Criteria, Sprint Review – demo working
 Refine User Stories for next 2 – 3 sprints Interdependencies software
Daily Stand-up Sprint Retrospective – stop, start,
During Sprint: address impediments, write continue
code, build product / develop solution, quality
assurance
Sprint Review – demo working software
Sprint Retrospective – stop, start, continue
Scrum Roles
Scrum Framework: Roles

3 Roles
 Product Owner
 Scrum Master
 Scrum Team

Sprint Burn down

Chart
Scrum Roles
For the successful implementation of the Scrum framework, the following roles are
involved:

The Product Owner is responsible

for defining the vision/value of the
product to maximize the value of
the work of the Development Team

Product Owner
Scrum Team

The Scrum Team is a cross

functional group of talented
people with different skills,
working together, committed to
completing a sprint

The Scrum Master is

responsible for making sure a
Scrum team lives by the values
Scrum Master and practices of Scrum
Scrum Roles: Product Owner
The Product Owner is responsible for defining the vision/value of the product
to maximize the value of the work of the team. Product Owner

The Product Owner is the sole person responsible for managing the Product
Backlog. This includes:

 Clearly expressing Product Backlog items – writing User Stories

 Ranking the items in the Product Backlog to best achieve goals and
missions
 Optimizing the value of the work the team performs
 Ensuring that the Product Backlog is visible, transparent, and clear to all and
shows what the Scrum Team will work on next
 Ensuring the team understands items in the Product Backlog to the level
needed

The Product Owner owns the backlog. They are not a BA, they are empowered
to lead the product vision and make decisions.
Scrum Roles: Product Owner

Subject Matter Expert End User Advocate Product Owner

Understands the domain well enough to Describes the product with
envision a product that will deliver value understanding of end user needs
for the customer. Able to answer
questions on the domain for those Business Advocate
creating the product
Understands the needs of the
organization paying for the product
Customer Advocate development and selects a mix of
Understands the needs of the business features that serve their goals
buying the product and can select a mix
of features valuable to the customer Decision Maker
Given a variety of conflicting goals
Communicator and opinions, the Product Owner is
Capable of communicating vision and the final decision maker for hard
intent, deferring detailed feature and product decisions
design decisions to be made just in time
Scrum Roles: Product Owner

The Product Owner is one person, not a committee.

Product Owner
The Product Owner may represent the desires of a committee in
the ongoing creation of the Product Backlog, but those wanting to
change a Product Backlog item’s ranking must go through the
Product Owner.

For the Product Owner to succeed, the entire organization must

respect his or her decisions. The Product Owner’s decisions are
visible in the content and ranking of the Product Backlog.

No one is allowed to tell the team to work from a different set of

requirements, and the team isn’t allowed to act on what anyone
else says.
Scrum Roles: Scrum Master

The Scrum Master is a servant leader responsible for making sure a

Scrum team lives by the values and practices of Scrum. Scrum Master

The Scrum Master is often considered a coach, mentor and

facilitator for the team, helping the team do the best work it possibly
can by removing obstacles and impediments.

The Scrum Master can also be thought of as a process owner for the
team, creating a balance with the initiative's key stakeholder, who is
referred to as the Product Owner.
Scrum Roles: Scrum Master

 Guides the Agile Execution

Scrum Master
 Responsible for the process

 Responsible for maximizing team productivity

 Sets up and conducts meetings

 Representative to management and team

 Characteristics of a servant leader

Scrum Roles: Scrum Master

The Scrum Master is also often viewed as a protector of the team. The
most common example is that the Scrum Master protects the team by Scrum Master
making sure they do not over commit themselves. However, a good
Scrum Master also protects the team from complacency.

Responsibilities:
 Helping others
 Being a catalyst
 Training, mentoring, consulting, coaching
 Growing more Agilists
 Building up skill set of all roles on Agile team
 Focus on restoring problem solving rather than solving problems
 Removing need for Scrum Master role on the team
Scrum Roles: Scrum Master

The primary job of the Scrum Master is to get the team to self-
organize. Scrum Master

Indicators of success:
 Team is truly cross-functional with all skills needed to do the work
 Each team member is on just one team
 All work in a backlog is either as a story or a defect
 Estimating as a team – everyone participates
 All or most of the decisions that could be made by the team are made by
the team
 Team members choose their own stories
 Team sees value in and practices self-reflection (e.g. retrospectives)
 Team is primarily left to their own devices during the iteration
 Team creates a shippable increment of work at the end of each sprint
Scrum Master as a Servant Leader

Thinks tactically
Coaches the
and strategically
team

Empathizes with Protects the

the team team
Scrum Master

Promotes
Encourages
transparency
personal
development of Inspires the
team members team
Scrum Roles: Scrum Master
As a Scrum Master, I would like to ensure that all the Scrum processes are followed so that the
Scrum team delivers on the incremental minimally marketable features to the client iteratively.

As a Scrum Master, I would like to ensure that the team is protected from external disturbances so
that they can focus on the sprint goals.

As a Scrum Master, I would like to ensure that the product owner is available to groom the product
backlog so that the team has a consistent flow of work that can benefit the customer.

As a Scrum Master, I would like to ensure that the product owner prioritizes features for the team so
that the team delivers user stories at a consistent pace.

As a Scrum Master, I would like to coach the performing organization on Scrum processes so that
the organization makes available the required systems and tools for continuous build, automated
testing, etc.

As a Scrum Master, I would like to promote the use of information radiators and open work spaces to
increase visibility of progress and osmotic communication.
Scrum Roles: Project Manager
As a project manager, I would like to get frequent updates on the project's progress so that I can
monitor slips from baseline for schedule and cost.

As a project manager, I would like to understand the contractual requirements to be met so that I can
ensure all outcomes are met satisfactorily.

As a project manager, I would like to proactively identify, monitor, and control risks, assumptions, and
constraints so that the project outcomes are not impacted, displeasing the client.

As a project manager, I would like to identify and control scope creep so that appropriate corrective
actions can be taken to satisfactorily meet the performing organization's and client's needs as
agreed with the client.

As a project manager, I would like to understand the development process for my project so that I
can use the appropriate scheduling model, such as the critical path or critical chain method.

As a project manager, I would like to know the transition of tasks between groups so that I can
monitor progress without calling unnecessary meetings.
Scrum Roles: Project Manager
As a project manager, I would like to understand the processes used by various groups so that I can
ensure that quality is being monitored and checked from the beginning.

As a project manager, I would like to identify all the stakeholders so that I can put together a clear
and concise communication plan to keep them all informed.

As a project manager, I would like to understand the availability of the resources and access to the
organizational assets to ensure the schedule built uses optimal resource allocation.

As a project manager, I would like to use lessons learned as a vehicle to bring effective and efficient
processes so that the organizational project management framework matures to benefit other
projects.
Scrum Roles: Scrum Team
The Scrum Team is a cross-functional group of people with different
skills, working together, committed to completing a sprint. It has a
Scrum Team
different composition from a traditional waterfall project, with three
specific roles: Product Owner, Scrum Master, and the development team.

Since scrum teams are cross-functional, "the development team"

includes testers, designers, and ops engineers in addition to developers.

 Owns the work performed in the Sprint

 Responsible for estimating and committing to work
 Self-organizing
 Between 3 and 9 (general pattern)
 Business and technical skills to build an increment of functionality
 Full autonomy during a Sprint
Scrum Team: Whole Team Approach
 One of the biggest differences in agile development versus
traditional development is the agile “whole-team” approach. Scrum Team

 This means involving everyone with different knowledge and

skills to ensure an initiative’s success.

 Team should have T shaped skills

 The focus of agile development is producing high-quality

software in a time frame that maximizes its value to the
business.

 Quality is the job of the whole team. Not just testers or

designated quality assurance professionals.
Scrum Team: Testing & Quality
Test Engineers are part of the Scrum team and should participate in
all ceremonies and in estimation. Scrum Team

The Scrum team should ideally develop a full suite of automated

tests because the number of test cases at all levels (system testing,
integration testing, component testing, unit testing etc..) will grow in
line with the new functionality added in each sprint, quickly stretching
beyond the limits of what can be tested manually within the sprint.

Automated tests are the only way to achieve a sufficiently high test
coverage in each sprint and provide the quality and rapid feedback
which are the key benefits of Agile adoption.

An Agile project without test automation is just a waterfall project

in phases. Except for the smallest projects, it’s just not possible to
satisfactorily regression test in every sprint if the tests are performed
manually.
Agile Programming
Over decades, programming teams have found certain patterns correlated to greater
success. Scrum Team

First called Extreme Programming (XP), but also referred to as Agile Engineering Practices,
Scrum Developer Practices, or simply Agile Programming, the core agile software
programming best practices are the following:

 Continuous integration
 Simple design
 Test-Driven Development
 Rigorous, regular refactoring
 Sharing the codebase between all or most programmers
 A single coding standard to which all programmers adhere
 Pair programming (when possible)
 A common “war-room” style work area (when possible)

Such practices provide the team with flexibility to deal with new features, enhancements or
bugs without putting the project in jeopardy or creating undue stress.
DevOps: Extending Agile thru Delivery
Initially Agile teams were made up of developers. As these teams became more
effective and efficient at producing software, it became clear that having Quality Scrum Team
Assurance (QA) and Dev as separate teams was inefficient. Agile grew to encompass
QA in order to increase the velocity of delivering software.

With DevOps, Agile is once again growing to encompass the delivery and support DevOps Maturity
members for the project to extend agility from ideation to delivery. will require that over
time Adient culture
DevOps is an IT mindset that encourages communication, collaboration, and tools support:
integration and automation among software developers and IT operations in  Automation
order to improve the speed and quality of delivering software.  Continuous
Integration
DevOps teams focus on standardizing development environments and automating  Continuous
delivery processes to improve delivery predictability, efficiency, security and Delivery
maintainability. The DevOps ideals provide developers more control of the production  Continuous
environment and a better understanding of the production infrastructure. DevOps Deployment
encourages empowering teams with the autonomy to build, validate, deliver and
support their own applications. With DevOps, nothing gets “thrown over the wall.”
Scrum Ceremonies
The Ball-Point Challenge
Scrum Framework: Ceremonies

4+1 Ceremonies
• Sprint Planning Meeting
• Daily Scrum/Standup
• Sprint Review Meeting
• Sprint Retrospective
• Backlog Refinement

Sprint Burn down

Chart

Backlog
Refinement
 Scrum Ceremonies
Scrum ceremonies are forums to collaborate, provide feedback, check for work status, discuss
any challenges, and plan for future sprints.
Team meets with the Product Owner and commits to a set of work to deliver during a
Sprint Planning
sprint

Daily Stand Up Team meets each day to individually share progress, next steps and impediments

Team demonstrates to the Product Owner what has been completed during the
Sprint Review
sprint

Sprint Team reflects on what worked and what didn’t during the sprint and looks for ways to
Retrospective improve the product and the process

Five to ten percent of every Sprint should be dedicated to Product

Backlog Refinement. This is not for users stories selected for the current sprint; it is
Backlog
for items in future sprints. Includes detailed requirements analysis, splitting large
Refinement
Click each ceremony to learn more.
items into smaller ones (epics to use stories), estimation of new items, re-estimation
of existing items
Scrum Ceremonies: Sprint Planning
Sprint Planning - Part 1 Sprint Planning - Part 2
Sprint Planning
1. Duration: 1. Duration:
 1 to 2 hours, on the first day of the  1 to 2 hours, on the first day of the Sprint
Stand Up Sprint
2. Participants:
2. Participants:  Scrum Master and Scrum Team
 Product Owner, Scrum Master and
Sprint Review 3. Activities:
Scrum Team
 Understand team capacity for the sprint
3. Activities:  Plan team tasks according to the team
Sprint
 Coming into meeting the Product capacity
Retrospective Owner will have a prioritized product  Sprint forecast outlining how much work
backlog. the team can complete from the product
Backlog  Selection and final review of user backlog. That body of work then
Refinement stories and acceptance criteria for becomes the sprint backlog.
the Sprint
 Estimate user stories in Story Points 4. Results:
 Prioritize Sprint Backlog  Commit user stories for the sprint
 Break down user stories into tasks
4. Results:
 Sprint Backlog
Scrum Ceremonies: Sprint Planning
Scrum Ceremonies: Daily Standup
Daily Stand Up (Scrum)

1. Duration:
 15 minutes, once per day, typically in the morning

Sprint Planning 2. Participants:

 Product Owner, Scrum Master and Scrum Team

Daily
DailyScrum
Stand Up 3. Activities:
 Stand Up is designed to quickly inform everyone of what's going on across the
team. It's not a detailed status meeting. The tone should be light and fun, but
informative.
Sprint Review  The Scrum Master schedules the daily stand up session
 Each team member must be standing and individually provides updates on the
status of tasks and remaining hours (‘what I did’, ‘what I’m working on ’ and ‘any
Sprint impediments’)
Retrospective  The Standup is not the forum to solve problems or reflect on team performance. If
necessary, a follow up meeting can be scheduled between team members and the
Backlog Scrum Master for more detailed discussions on impediments.
Refinement
4. Results:
Click each ceremony to learn more.
 Track progress
Scrum Ceremonies: Daily Stand Up
Scrum Ceremonies: Sprint Review
Sprint Review

1. Duration:
 1 hour on the final day of each sprint, usually in the morning
Sprint Planning
2. Participants:
 Product Owner, Scrum Master and Scrum Team
 Optional: Other Stakeholders, Customers
Daily Standup
3. Activities:
 Scrum Team demonstrates ready and done user stories to Product Owner and
Sprint Review
Sprint Review users.
 Use this time to showcase the work of the team, for the team to celebrate their
accomplishments, demonstrate work finished within the iteration, and get immediate
Sprint feedback from project stakeholders.
Retrospective  Remember, work should be fully demonstrable and meet the team's quality bar and
Product Owner’s Acceptance Criteria to be considered complete and ready to
Backlog showcase in the review.
Refinement  Discuss in high level upcoming backlog items for future sprints

4. Results:
Click each ceremony to learn more.
 Sprint and Product backlog is updated to reflect completed stories
Scrum Ceremonies: Sprint Review
Scrum Ceremonies: Sprint Retrospective

Sprint Retrospective

1. Duration:
Sprint Planning  1 hour, on the final day of sprint, usually in the afternoon

2. Participants:
Daily Scrum  Product Owner, Scrum Master, Scrum Team

3. Activities:
 Discussion on what went well, what went wrong, and what could be different
Sprint Review
 Agile is about getting rapid feedback to make the product and development culture
better. Retrospectives help the team understand what worked well – and what
Sprint didn't.
Sprint Retrospective
Retrospective
4. Results:
 Prioritized list of improvement in the form of user stories.
Backlog
Refinement
Click each ceremony to learn more.
Scrum Ceremonies: Sprint Retrospective Techniques
Retrospectives can take many formats including Stop Start, Starfish, Speedboat, Timeline,
Maturity Matrix, Open Space, 5 Whys.
Scrum Ceremonies: Backlog Refinement

Backlog Refinement

1. Duration:
Sprint Planning  As needed

2. Participants:
Daily Scrum  Product Owner, Scrum Master and Scrum Team

3. Activities:
 Refine user stories and acceptance criteria.
Sprint Review  Includes detailed requirements analysis, splitting large items into smaller ones
(epics to user stories), estimation of new items, re-estimation of existing items.
It’s a good practice to have at least two sprints worth of user stories refined.
Sprint
Retrospective 4. Results:
 Prioritized list of user stories ready for development for subsequent sprints
Backlog
Backlog Refinement
Refinement
Click each ceremony to learn more.
Scrum Ceremonies: Backlog Refinement
Break

15 minutes
Scrum Artifacts
Scrum Framework: Artifacts

3 Artifacts
• Product Backlog
• Epics
• Features
• User Stories
• Sprint Backlog
• Sprint Burndown Chart

Sprint Burn down

Chart
Scrum Artifacts
There are three key artifacts in Scrum:

 The Product Backlog prepared by the Product Owner contains a list of user stories, which are smallest
units of value to deliver.
 These are prioritized by business value inside the backlog.
Product Backlog
 The list should include all features visible to the customer, as well as the technical pieces needed.
These technical pieces are call “enabler stories.”

 The Sprint Backlog is a detailed list containing information about which requirements (user stories) the
team is going to implement and how the team is going to implement these requirements in the upcoming
Sprint.
Sprint Backlog  Tasks on the Sprint Backlog are broken down into hours with no task taking longer than 16 hours.
 If a task is greater than 16 hours it should be broken down further.

 The Burndown Chart is a highly visible information radiator that shows the cumulative work remaining in
Burn down a Sprint and is updated on a day-to-day basis. It’s recommend that teams view this daily.
Chart  The Burn down Chart can aid teams in quickly ascertaining if they have overcommitted to tasks in the
sprint.
Scrum Artifacts: Product Backlog
The Product Backlog is a detailed document
prepared by the Product Owner that contains
a list of customer requirements prioritized by
business value.

This should include all business

requirements, as well as the technical
requirements (enablers) needed to build the
actual solution.

These requirements can and will change and

it is the duty of the Product Owner to keep
track of these changes in the Product Product Backlog in HP ALM Octane
Backlog.

The Product Backlog includes in hierarchical

order:
 Epics
 Features
 User Stories
Product Backlog in Excel
Scrum Artifacts: Product Backlog
A Product Backlog includes:

Epics
Features
User Stories

Business Architecture
Business backlog items Enabler stories: Technical
and end-user functionality work items that are created
to support the development
of the business initiatives
Product Backlog Items: Epics

EPICS
Epic
An epic is a large initiative delivering new products,
solutions, or services to customers. This body of work
can be broken down into a number of smaller features
and stories.
Feature
An epic can span more than one project and generally
epics often change in scope over time as a natural
aspect of agile development.

Epics are delivered over a multiple set of sprints.

User Story
Product Backlog Items: Features

Epic FEATURES
Features are smaller than an epic and bigger than
a story.

Each feature includes a benefits hypothesis and

Feature
acceptance criteria.

Features are realized by some collection of user

stories.

User Story
Product Backlog Items: User Stories

Epic USER STORIES

User stories are smallest unit of requirements.

They are a concise, written description of a piece

of functionality that will be valuable to a user of the
Feature
product.

User stories are not detailed requirements.

User Stories committed to for a sprint should be

completed within the sprint.
User Story
Product Backlog Items: User Stories
User stories are short, simple descriptions of a feature told
from the perspective of the person who desires the new
capability, usually a user or customer of the system.

User stories should be concise enough that they could be written

on index cards or sticky notes, and arranged on walls or tables to
facilitate planning and discussion.

As such, they strongly shift the focus from documentation (writing

about features) to discussing them.
Product Backlog Items: User Stories Template
Product Backlog Items: Detailed User Story Sample

Source: Rally Dev

User Stories - Components
A good user story has three components, commonly referred to as the
three C’s.

Card Conversation

3 C’s

Confirmation
User Stories - Components

CARD
A user story should be short
enough to fit on a note card or
Post-it when written physically.
Card Conversation

3 C’s
The information included in the
card should identify and plan the
requirement.

Confirmation
User Stories - Components

CONVERSATION
Conversation is critical throughout
the software development
lifecycle. Conversations represent
Card Conversation
discussions between the Product

3 C’s Owner, development teams and

the stakeholders.

Confirmation
User Stories - Components

Card Conversation

3 C’s CONFIRMATION
Acceptance criteria should be
defined before a user story is
developed. Confirmation helps in
Confirmation
delivering successful user
stories with reduced rework and
incorrect assumptions.
INVEST in User Stories

I N V E S T
INVEST in User Stories
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess
the quality of a user story. If the story fails to meet one of these criteria, the team may want to
reword it, or even consider a rewrite (which often translates into physically tearing up the old story
card and writing a new one). A good user story should be:

Independent Negotiable Valuable Estimable Small Testable

I N V E S T
INVEST in User Stories

Independent Negotiable Valuable Estimable Small Testable

I N V E S T

Make stories as independent as

possible from each other.
INVEST in User Stories

Independent Negotiable Valuable Estimable Small Testable

I N V E S T

Start with a brief description.

Details emerge in discussion
INVEST in User Stories

Independent Negotiable Valuable Estimable Small Testable

I N V E S T

Users and customers perceive

value in the deliverables
INVEST in User Stories

Independent Negotiable Valuable Estimable Small Testable

I N V E S T

Domain and technical

knowledge allow the team to
provide estimates
INVEST in User Stories

Independent Negotiable Valuable Estimable Small Testable

I N V E S T

A team can finish one story in a

few days, and several in every
sprint
INVEST in User Stories

Independent Negotiable Valuable Estimable Small Testable

I N V E S T

Validation criteria and

techniques are specified clearly
User Story Acceptance Criteria
Acceptance Criteria are the list of functional and non-functional requirements that a
software product must satisfy in order to be accepted by the stakeholders.

Given: a scenario

When: an action is carried out

Then: a particular set of observable results should be displayed

Example

Given that I am a paid Netflix subscriber, I want the ability to manage parental
controls. When there is an attempt to access the channels that I have locked,
then a warning message should be displayed and the channel should not be
accessed unless a correct password is entered.
User Stories: Definition of Ready
Teams can check the quality of the user stories using a Definition of Ready. Getting started on a sprint with
poorly understood stories can result in rework or could take the team in the completely wrong direction.

Definition of Ready for a User Story

 User Story defined
 The expected behavior is understood by relevant team members
 The business value is clearly articulated
 The story is small enough to fit in one sprint (INVEST)
 User story has been estimated/sized by the development team
 Scrum Team accepts User Experience artifacts
 Performance criteria identified, where appropriate
 The story has clear and concise acceptance criteria which covers all of the features of the story
 Team has an idea how, and if, it can be demonstrated
 Known user Story dependencies identified and captured in the story
 No external dependencies block the story being started or completed
 Test data needed to test the functionality is identified
User Stories: Definition of Done
The Definition of Done (DoD) is used to describe when a user story from the Sprint Backlog can be
considered complete. Definition of Done is a simple checklist of all necessary activities (e.g. writing code,
coding comments, unit testing, integration testing, release notes, design documents, etc..) that ensure that
only truly completed features are delivered, both in terms of functionality and in terms of quality.

Definition of Done for a User Story

What must happen for the story to be marked as complete. This may vary across team.

May include:
 Story should have automated acceptance test
 The story should have working code supported by unit test that provide around 60 – 70 percent coverage
 The story should have well defined acceptance criteria
 The code must have been written as a pair or should be code reviewed
 Code must be completely checked in to the source control system and the build should pass with all the
automated tests running
 The Product Owner must accept the story
User Story Prioritization & Refinement
Prioritizing User Stories
The stories to prioritize at the top of the
product backlog are the ones that will
deliver the greatest business value,
Prioritized Product Backlog
The highest priority user stories should be
done first. Fine-grained Backlog Items
ready for next sprints i.e.
smaller user stories
The Product Owner or product team must
spend time early in the product lifecycle to Medium-grained Backlog
define the business value criteria. Items for current Release

The business value of a user story could be

expressed in different ways.
Coarse-grained Backlog
items for Future Releases
The product owner may choose to focus on
value e.g. to get more users, revenue (to
increase the cash flow), validated learning (to
better prepare the future), stability (to boost
customer retention) etc.
Prioritizing User Stories: MoSCoW Technique
MoSCoW is a fairly simple way to sort features (or user stories) into priority order - a way to help teams
quickly understand the customer's view of what is essential for launch and what is not.

MoSCoW stands for:

Must have (or Minimum Usable Subset)

Should have
Could have
Won't have (but Would like in future)

Must Haves are features that must be included before the product can be launched. This is the minimum scope for the product to
be useful and meet customer needs.

Should Haves are features that are not critical to launch, but are considered to be important and of a high value to the user.

Could Haves are features that are nice to have and could potentially be included without incurring too much effort or cost. These
will be the first features to be removed from scope if the project's timeline or budgets are at risk.

Won't Haves are features that have been requested but are explicitly excluded from scope for the planned duration, and may be
included in a future phase of development.
User Story Elaboration happens in Backlog Refinement
User stories in the Product Backlog exist at different levels of detail depending on their
priority and when they will be developed. User stories must be refined to the point they
meet the Definition of Ready before they enter into Sprint Planning.

User Stories are: Vague Understood Estimated Broken

into Tasks

This
Sprint +1 Sprint
Future Next Sprint +2
Releases Release
Features to User Stories Decomposition
Features are decomposed into small user stories so that they can be completed within a
sprint. User stories are smallest units of business and technical requirements.

Daily
Features Scrum

Single
Not possible in Sprint
User a single sprint
Story
Daily
Scrum

Possible in
Daily
Scrum a single
sprint
User
Story
Decomposition
User Story Decomposition: Vertical vs Horizontal Slicing
More Scrum Artifacts: Sprint Backlog &
Burndown Chart
Scrum Artifacts: Sprint Backlog
The Sprint Backlog contains information
about which user stories the team is going
to implement in the upcoming Sprint.

Stories on the Sprint Backlog are broken

down into tasks with no task taking longer
than 16 hours.

If a task is greater than 8 hours it should

be broken down further.

Tasks are assigned to members of the

development team and progress on tasks
is tracked each day during the Daily
Standup.
Sprint Definition of Ready & Definition of Done
Exit
Gate

Definition of Ready Sprint Definition of Done

Entry
Gate
Scrum Artifacts: Burndown Chart
The Burn down Chart is a real-time,
visual guide that shows the actual and
estimated amount of work to be done
in a sprint and is updated on a day-to-
day basis.

 The Burn down chart can tell us:

 Work expressed in effort (story points)
or hours for the sprint
 Ideal and Actual Velocity
 Work remaining
 Work done so far
 If we are on track to complete work by
the sprint end date
How to track velocity

Velocity is a measure how much new

functionality a team can deliver in a
sprint.

Velocity is measured in the same units

as story estimates, whether this is story
points, days, ideal days, or hours that
the Scrum team delivers.

It usually takes 3- 6 sprints tor team

velocity to stabilize.
Team Scrum Board
Being Agile Project Scrum Board: Sprint 1, Week 2

While it’s not a required scrum artifact,

we can make the sprint backlog visible
by putting it on a Scrum board.

Team members update the board

continuously throughout the sprint; if
someone thinks of a new task it can
be added. Either during or before the
daily standups cards are moved
around the board.

We track stories in To Do, In Process,

in Test and Done for the Sprint
Product Backlog Completed
Backlog Items to be completed
Sprint Backlog
in Sprint
Items
Managing the Product Backlog at Adient: HP ALM Octane
ALM Octane is Adient’s selected tool for
managing and tracking Agile Projects
and maintaining the Product Backlog
and other Scrum artifacts.

Training on ALM
Octane can be
provided to teams
kicking off Agile
projects by making to
a request to the
ALPM CoE.
Break

15 minutes
Sizing User Stories
User Story Estimation: Story Point Sizing
Story point sizing is a relative estimation technique

Except the Product Owner, the entire Scrum Team is involved in the estimation
process

It is useful for estimation of ALL backlog items including Epics, Features and
User Stories

Fibonacci sequence reflects the inherent uncertainty in estimating backlog

items

Planning poker is used as a technique for estimation

User Story Estimation: Story Point Sizing
When estimating the relative size of user
stories in agile software development
the members of the team are supposed
to estimate the size of a user story as
being 1, 2, 3, 5, 8, 13, ... . ...

We recommend that if a user story is

greater than a 5 it should be broken
down further.

Higher numbers should be used for

Features and Epics

The reason for using a modified

Fibonacci sequence is to reflect the
inherent uncertainty in estimating larger
items.
Estimating Game
Relative Sizing: Estimating the Agile Training Backlog

Using a round robin approach, each team member will take his/her turn to select a card from the DONE
section of the Training Scrum Board:
• The first person takes and reads the top Story Card and then places it on the display area.
• The second person takes and reads the next Story Card and positions it (with justification) on the
display area in somewhere relative to first card depending upon whether he/she sees it as being
more or less complex.
• The next person then either:
• Takes, reads and positions (with justification) the next Story Card, or
• Moves (with justification) an existing card, or
• Do nothing
• Repeat the previous step until:
• All the Story Cards have been taken, and
• No-one wishes to move any of the already positioned Story Cards
• Debrief, including discuss size vs hours
• Group into T-Shirt or Fibonacci groups
Day 1 Retrospective

Great Work!
beingagile
Agile Development Framework Global Training: Day 2
Being Agile:
An Agile Development Framework for Adient

Before you lay a foundation on the

cricket field, there should be a solid
foundation in your heart … after that as
you start playing more and more
August 23, 2017
matches, you learn how to score runs
and how to take wickets …
Sachin Tendulkar
The Chair Challenge
Let’s Review
Pop Quiz!

 What is Agile?
 What are the four core values?
 What is the most important principle?
 Explain the Scrum Framework.
 Describe the Scrum ceremonies.
 Explain the role of the Scrum Master, Product Owner, and Scrum Team.
 What is servant leadership?
 What is different about estimating in Scrum?
 How might we ideate and develop solutions that deliver real business value when the
future is uncertain?
Scrum at Scale
Scaling of Scrum Team
Scrum provides a flexible framework for delivery at the team and project level. In order to scale Scrum
there are several dimensions that may be addressed.

Scale
Number of teams,
complexity of projects

Three Dimensions Distribution

for Scaling Scrum Number of geographic
locations across which Adient
teams are distributed

Adoption
Degree Agile principles and Scrum
practices have penetrated the
organization i.e. degree to which
Adient is “being agile”
Scrum Framework

Sprint Burn down

Chart
Scrum at Scale Framework
Scrum of
Scrums
2 New Ceremonies 3-5 times
per week
• Scrum of Scrums Overall Sprint
• Overall Sprint Team 3 Retrospective

Retrospective Sprint
Planning Sprint Sprint
Meeting Backlog 3 Burndown
Chart

Team
Retro
Team
Representatives
Team 2 Potentially
Sprint Sprint Sprint
Shippable
Planning Sprint
Planning Backlog 2 Burndown
Product
Meeting 1 Meeting
Chart Increment Team
Sprint
Review: Retro
All Teams

Team 1
Sprint
Sprint Sprint
Planning
Meeting Backlog 1 Burndown
Chart Team
Retro
Scrum at Scale Framework Overview
 The framework starts with the assumption of several cross-functional, self-organizing Scrum teams on a project
(up to 8).

 Cross-team coordination is decided by the teams with preference to decentralized and informal coordination e.g.
just talking, communication in code, cross team meetings, Scrum of Scrums etc.

 Roles and artifacts are the same as in Scrum but 2 new Ceremonies are added.

 Teams share one Product Owner and one Product Backlog. As the Product Owner will be shared across teams,
the PO’s role shifts from primarily clarification of story details for the teams, to better defining the product and
prioritization of the product backlog by business value. The PO should focus on maximizing ROI and the team in
more directly engaged with customers.

 Planning is done collaboratively across teams. Like Scrum, Sprint Planning is split into two parts.

 With Scrum at Scale:

 the first part of Sprint Planning is a joint meeting attended by representatives from all of the teams to agree
"What" Product Backlog Items will be built in the coming Sprint
 The second part of Sprint Planning is then used by each team to produce the Team Sprint Backlog and agree
"How" the PBI's will be built.
Scrum at Scale Framework Overview
 Sprints are synchronized across teams with Sprint Planning, Sprint Review and Sprint Retrospective all run at
the same time for each team.

 The individual team sprints all lead to one integrated Potentially Shippable Product Increment.

 The end of the sprint also needs to be synchronized. This is accomplished by having one common Sprint
Review for all the teams.

 The Sprint Retrospective is divided into two parts:

• first each team holds their own individual team Retrospective
 then representatives from each team hold a joint Retrospective together that enables them to identify and
address issues that cannot be solved at the individual team level.

 Note: The complexity of co-ordination between teams increases exponentially as there are more teams
involved. If there are more than eight Scrum teams working off the same product backlog, it’s time to divide
the product backlog into different requirement areas. Then assign 4-8 teams to each of these new
requirement area-specific backlogs and assign Area Product Owners. This may add necessitate adding a new
ceremony called the PO Sync.
Scrum of Scrums
A Scrum of Scrums meeting is a Daily-Scrum-like meeting
between teams, typically held two or three times per week.

Scrum of Scrums is a virtual team composed of Scrum Masters

and often a technical lead from the individual Scrum teams that
are working together to integrate and ship the product.

Usually the format is three questions, similar to a Daily Scrum:

 What did my team do that is relevant to other teams?
 What will my team do that is relevant or will impact other
teams?
 What are my team’s obstacles that other teams should know
about or can help with?

Outside the Scrum of Scrums meeting, relevant individuals from

the meeting volunteer to deal with eliminating operational
impediments that are identified related to the release and
deployment process. For example, a Scrum of Scrums would have
coordination mechanisms to deal with cross-team dependencies
related to completion of epics required for release.
Scrum at Scale Ceremonies: Scrum of Scrum
Scrum of Scrums

Sprint Planning 1. Duration:

 30-60 minutes, three times per week or as necessary

2. Participants:
DailyStand
Daily ScrumUp  Team Representative (usually technical lead), Team Scrum Masters, Scrum of Scrums
Leader or senior technical or business leader (usually Director level)

3. Activities:
Sprint Review  Scrum of Scrums is designed to support cross team collaboration and remove
impediments
 First 15 minutes, each team member must be standing and individually provide updates
Sprint on the status of team activities and timelines (‘what team worked on’, ‘what team will
Retrospective work on ’ and ‘any impediments’)
 As needed, the Scrum of Scrums can be used as a forum to solve problems.
Backlog Participants address any issues, problems, or challenges that were raised during the
Refinement initial discussion or previously identified and maintained on a scrum of scrums backlog.
This backlog is analogous to what might have been called an issues list on a traditional
project
Scrum of Scrums
4. Results:
Click each ceremony to learn more.
 Cross Team Collaboration, Continuous Improvement & Impediment Removal
Scrum at Scale Assumptions
• Teams vertically slice requirements into the
smallest possible increments that can be
deployed independently. Vertical Slices

• Teams are expected to focus on technical Take a large feature and break
excellence such as doing continuous integration it up into several small pieces
and automated regression testing. that slice through each of the
architectural layers.
• At the end of every sprint the teams should have
a potentially deployable product. Each slice is comprised of any
work needed to be done in
• In order to support the team level, Adient has set each architectural layer as
up a group of decision makers (for example, an well as any testing and
Executive Action Team) whose mandate is to integration to make it release
facilitate and oversee the improvements that the ready.
teams, Product Owners, and Scrum Masters do
not themselves have the ability to implement.
Distributed Scrum
Distribution of Scrum Teams
 Distributed Scrum allows geographically dispersed teams
to work together as one unit to deliver value
Proxy Product
Owner
 It also refers to the techniques we apply to a team or
teams when they are not co-located.
Proxy Scrum
Master
 This may include introducing new roles such as Proxy
Scrum Masters and Proxy Product Owners to help bridge
the communication gap Distributed
Scrum
 The complexity of communication increases exponentially
when team members are located in countries where time Feature
Communication
zone differences preclude interaction and collaboration for Releases

most of the day

Joint
 Language and culture play a key role in the teams Ceremonies
effectiveness

 Distributed Scrum can also encompass aspects of scaling

including the Scrum of Scrum ceremonies
 Distributed Scrum vs Co-located Teams

Differences Details
Timing of Ceremonies With Adient teams being globally dispersed and the time zone differences
amounting to 12 hours, we have to have an approach that takes into
consideration these large variances.
Proxy Product Owner Given the time zone differences, it is physically impossible for the Product Owner
to be present in all meetings in which they should participate. In situations like
this, the Product Owner can assign one or more proxies. The Proxy Product
Owner will have sufficient domain expertise to act as the local Product Owner
and help the teams with business/functionality related questions.
Proxy Scrum Master Proxy Scrum Masters are important for avoiding undesirable behaviors, as well
as helping teams synch when globally and geographically dispersed.
Team Working Agreement Team working agreements are key for teams to establish a protocol on a
multitude of common practices including team ceremonies across geographies,
best practices to communicate.
Feature Teams When the work needs to be distributed across many time zones and the time
difference does not allow for daily communication, the Feature team model
greatly reduces cross team dependencies.
 Distributed Scrum Framework: New Roles & Ceremony

2 New Roles New Ceremony

 Proxy Product Owner • Scrum of Scrums
 Proxy Scrum Master Scrum of
Scrums
3-5 times
per week

Proxy Scrum
Master

Sprint Burn down

Proxy Product Chart
Owner
Distributed Scrum Roles

The Product Owner is responsible

for defining the vision/value of the
product to maximize the value of
the work of the Development Team

Product Owner Proxy Product Owner is

a local (offshore) Product
Scrum Team Owner who have enough
domain knowledge to
help answer questions
when the primary Product
The Scrum Team is a cross
Owner is not available
functional group of talented
people with different skills,
working together, committed to
completing a sprint The Proxy Scrum Master is an
onsite coordinator for the Scrum
team
The Scrum Master is
responsible for making sure a
Scrum Master Scrum team lives by the values
and practices of Scrum
Scrum Roles: Proxy Product Owner

The Proxy Product Owner is a critical role in Distributed Scrum.

Proxy
They are the co-owner of the Product Backlog along with the Product Owner, who is the key Product Owner
owner. This role is important in ensuring all teams in all regions have a solid understanding
of the backlog and priorities.

Proxy PO ensures the teams in region stay actively involved in backlog refinement,
providing their valuable input to what’s possible and what’s necessary.

Responsibilities:
 All the responsibilities of the Product Owner (PO), plus…
 PO Synch meeting – ½ twice weekly with the PO and all other Proxy Product Owners
 Keep teams in geographical region informed, updated and actively involved in backlog
refinement, including enabling their input on stories
Scrum Roles: Proxy Scrum Master

The Proxy Scrum Master is a very important role in Distributed Scrum.

This role shares the key responsibilities of the Scrum Master, and applies them specifically Proxy
to their geographical region. As a true Servant Leader and Scrum Master, the SM protects Scrum
the teams in a region and removes impediments. Master

Responsibilities:
 All the responsibilities of the Scrum Master, plus…
 Hold a 1-2x/week Scrum of Scrums to synch events with the Scrum Master and the
other regional Proxy Scrum Masters
 Hold the teams in geographical region to the scrum ceremonies. Hold those rigidly at
first for several months or years
Distributed Scrum: Scaling can take tremendous co-ordination

SM GERMANY

TEAM TEAM
Daily Daily
SM
Scrum Scrum CHINA

Sprint Planning
Team
TEAM
Lead
Daily
Daily TEAM TEAM
Scrum
Scrum Daily
Scrum of PPO Daily
Backlog Grooming Scrum
Scrums Scrum

PPO Scrum of TEAM

Scrum of
Sprint Review Daily
Scrums
Scrum of Scrum
SM INDIA
Scrums PPO

Sprint
Retrospective

TEAM TEAM
Enterprise Daily Daily
Architect Scrum Scrum
SME’s
BA’s
Synchronization
Ceremony Across Time- TEAM
zones
Daily
Scrum PPO
Scrum of
Scrums
Distributed Scrum: Simplify with scheduling joint ceremonies even if
they may be outside regular working hours
Example of US and India based teams timetable India – Workday Starts (9:30 AM IST)

DEV QA SM
Mail checks and check HP Octane tool
Task pickup & execution
24
Detroit, MI – Workday Ends (5 PM EST) 23 1 Brainstorming and issue resolution OPS
22 2
21 3

20 4

19 5

18 6

Update daily task status in HP Octane Tool Update daily task status in HP Octane tool
17 7

16 8
Task pickup & execution Detroit, MI – Workday Starts (8:30 AM EST)
Brainstorming and issue resolution 15 9
Meetings/discussions with stakeholders 14 10
Daily Scrum Meeting (8:45 -9:00AM EST)
13 12 11

*Timing in dial are all EST timings

DEV DEV QA PPO SM PO

Iteration planning meeting at start of iteration India– Workday Ends (7:00 PM , IST)
(7:00 AM EST)
Onshore/Offshore leads/teams to discuss issue
resolution (Need basis) – 9AM EST
Retrospective last day of iteration (7:00 AM
EST) Overlap of 2-3 Hrs. between Detroit & India
teams
Success Criteria for Distributed Scrum Teams

Trust
Dedicated
Embrace
Product
Culture
Owner &
Differences
Scrum Master

CI/CD Communication

Successful
Patterns for
Distributed
Scrum
Establish Feature Teams
Required at each
Infrastructure location

Ownership at
Availability of
different
SMEs
geographies
Whole Team
part of
ceremonies
 Overcoming Challenges for Globally Distributed Teams
Challenges Solution
Lack of Dedicated Scrum Master It is very important for distributed teams to have local dedicated Scrum Masters
Product Owner generally unavailable A Scrum Master can share more than one scrum team
Scrum master should be dedicated to a scrum project and not in a part time capacity
Likewise the Product Owner needs to make sure they are available for the team during their local times. If this is
not possible, then proxy owners should be nominated who are domain experts
The proxies can then attend all the local ceremonies and synch up with the primary Product Owner at a regular
interval
No Continuous Integration and For the success of an Agile Transformation continuous integration and continuous delivery MUST be embedded
Continuous Delivery (CI/CD) as part of the sprint process. This becomes imperative when considering globally distributed teams.
provision in the scrum process or If CI/CD is missing there is a high risk of not being able to deliver working software at the end of each sprint (one
non being planning for in the near of the scrum basic tenants)
future

Most organizations start This is an activity that needs to be considered at the onset of discussions about the project
development using Agile but The infrastructure setup is one of the most important activities of the project setup
overlook the need to have The infrastructure setup goes hand in hand with the CI/CD
infrastructure in place to support the
correct CI/CD enabled system
landscape
Lack of Availability of SME’s SME can provide additional context to stories being worked on by the developers, as well as clarifications during
story grooming meetings. Look for additional roles (e.g. Proxy PO) to supplement SME availability
Not all team members attend team Provide technologies to support virtual co-location
ceremonies Ceremonies should be held at mutually convenient times for all teams planning to attend a meeting
 Overcoming Challenges for Globally Distributed Teams
Challenges Solution
Lack of Ownership Since teams usually come from a waterfall model, they are used to “order taking” from a project
manager. In scrum the team is self empowered to make its own decisions, thus giving the team a
greater latitude. Challenge behaviors during sprint ceremonies

Teams do not communicate effectively with Extensive use of tools that can allow better audio and visual communications
each other Video conferencing tools
Wiki style project forums allowing instant communication, as opposed to emails
Explore available tools in market and make selections based on Adient criteria. Popular tools
include Sococo, an online workplace for creating virtual co-located teams and Slack for
collaboration

Lack of understanding of Culture Cultural sensitivity should be considered when working across time zones and even across
departmental divisions or teams, since each has their own culture and set of accepted behaviors
Local holidays – co celebrate or play pop quizzes
Local work ethics
Teams are not multi-functional and this results To reduce the interdependencies between different teams in different regions, it is important to set
in high level of dependencies across teams the project structure in a Feature Team model
Break

15 minutes
 Objective:

Get In 18 minutes build the tallest free

standing structure using 20 sticks of
spaghetti, 3 feet of tape, 3 feet of string
and a marshmallow.
Rules:
1. Build the tallest structure.
2. The entire marshmallow must be on top.
3. Use as much or as little of the kit.

Scrum at Scale Simulation: Adient Aftermarket

4. Break up the spaghetti, string or tape.
5. The teams cannot hold the structure when the
time runs out.

Instructions: 5-minute prep time

1. 18 minutes build time.
2. 10 minutes retrospective
Adient Global Aftermarket Platform Overview
Adient believes there is a $100M Business to Business
Aftermarket that has not yet been tapped.

In the next 6 months we want to launch a global

aftermarket platform which can be customized for dealers
in different regions including North America, Europe,
Japan and China to buy Adient seats and retail them to
their end consumer.

We want to roll out the platform at the next Autoshow.

This deadline is business driven.

 Self organize into 4 teams of 7 or 8

 Kick off an Agile project to develop Adient’s Global
ecommerce Aftermarket Platform for Dealers
Adient Aftermarket: Co-located Teams
Sprint 0 (Initiation Sprint) Sprint 1
60 minutes 60 minutes

 Onboard team Sprint Planning (15 minutes)

 Identify Product Owner & Scrum Master  Identify Sprint Goal
 Create Social Contract/Team Working Agreement  Estimate Stories for Sprint
 Confirm Definition of Done & Ready
 Define Project Vision  Acceptance Criteria: You must create something physical and tangible
 Identify Interdependencies
 Share-out: Team Name, Roles, Working Agreement &  Create Sprint Burndown Chart & Scrum Board
Project Vision
Sprinting
 Create Product Backlog Sprint Execution (5 minutes)
Led by Product Owner (team contributes)  Build product / develop solution, quality assurance.
 List 2 Epics Daily Stand-up 1 (5 minutes)
 Select 1 Epic and for selected epic, list 3 Features  Update Burndown Chart & Scrum Board
 Select 1 Feature and create 5 user stories to deliver Sprint Execution (5 minutes)
the feature  Build product / develop solution, quality assurance
 Prioritize User Stories Daily Stand-up 2 (3 minutes)
 Refine User Stories for next sprint Update Burndown Chart & Scrum Board
Sprint Execution (2 minutes)
 Share-out: Selected Feature and User Stories  Check-in, QA & final tasks to prepare for sprint review

 Establish environments Sprint Review (5 minutes per team)

 Demo solution, car of the future prototype to the group
 Scrum Master: Schedule all ceremonies
Sprint Retrospective – (5 minutes)
Stop, Start, Continue
Lunch

60 minutes
Adient Global Aftermarket Platform: Distributed Scrum
After the first sprint we recognize the project is much bigger than we anticipated, especially because we now
want to add direct to consumer (B2C) capabilities to the platform. We’ve decided to onboard new development
teams and change the current team structures.

 Select a team lead to take a card from the facilitator and go back to team
 Cards will have two region names – USA & India. Your team will be located in that region
 Product Owner location will be in USA
 As a team, determine what new roles need to be added and what new ceremonies must be scheduled
 Start Sprint 2 of your Agile project to develop Adient’s Global ecommerce Aftermarket Platform to supports
both dealers and consumers
Adient Global Aftermarket Platform Sprints
Backlog Refinement Sprint 2
30 mins 80 minutes

 Onboard team Sprint Planning 1 (10 minutes) Daily Stand-up 2 (2 minutes)

 Identify Product Owner  Identify Sprint Goal
 Identify Proxy Scrum Master  Identify what user stories will be Scrum of Scrums (4 minutes)
 Identify Proxy PO delivered
 Create Social Contract/Team Working  Acceptance Criteria Sprint Execution (2 minutes)
Agreement  Interdependencies  Check-in, QA & final tasks to
prepare for sprint review
 Consolidate & Update Product Backlog Sprint Planning 2 (10 minutes)
Led by Product Owner (team Team Estimate and commit to user Sprint Review (5 minutes per team)
contributes) stories  Demo solution, car of the future
 New vision for the product Sprint Backlog created prototype to the group
 Prioritize Backlog, User Stories
 Refine User Stories for next sprint Team Sprint Retrospective – (3
Distributed Sprint Execution (5 minutes) minutes)
 Scrum Master: Schedule all ceremonies  Build product / develop solution, Stop, Start, Continue
quality assurance. You must create
something physical and tangible Overall Sprint Retrospective – (5
minutes)
Daily Stand-up 1 (3 minutes) Stop, Start, Continue
Distributed Sprint Execution (5 minutes)
 Build product / develop solution,
quality assurance
Debrief & Recap
but wait … what do I
actually do … today?
Being agile (small a) in a Not Yet Agile Environment
 Remember Being Agile is a MINDSET that embraces change, focuses on interactions, collaboration and rapid delivery
of value. You can adopt an agile mindset whether or not you’re in an environment that currently leverages an Agile
development framework. Your measure of success is delivering quality working software that meets the user’s needs.

 Begin by impacting the areas in your environment that are within your own sphere of influence –successful Agile projects
are built on the individual behaviors of each person as empowered members of the team. Continue to educate
yourself and look for opportunities to improve your own collaboration behaviors and communication skills. Agile requires
a shift to autonomy and freedom which, in turn, requires well-rounded soft skills and a culture of open, collaborative,
team-based communication. Identify what additional help and training you will need and seek it out.

 What can you automate? Begin assessing your current technical environment and ability to support automated testing
and continuous integration (tools, resources etc.). Teams that don't already have technology environments that support
fast-build, continuous integration activities, should be aware that manual testing every time you commit code to the
repository will make running projects in an Agile way much more difficult.

 Connect with your customer and deliver something of value that makes them happy …whatever development
methodology you use. Understand what’s the number one problem they are trying to solve and how they prioritize value.
Use ongoing communication to kick start the collaborative process and get them comfortable with flexibility. Don’t begin
by just asking them to provide requirements, ask them to help align you and the development team around the vision,
and value of the project and features requested. Seek to understand their Intent. Remember it’s your customer who
should ultimately prioritize the features delivered based on business value … whatever the development framework.

 Be passionate! Be plucky! Remember you’re one catalyst for the Agile movement at Adient … not just some lone nut!
Learn & Share
Scrum in 10 minutes
https://www.youtube.com/watch?v=XU0llRltyFM

Introduction video to Turn the Ship Around!

https://www.youtube.com/watch?v=mkr9UtI-7FA

Turn the Ship Around!: A True Story of Turning Followers into Leaders
by L. David Marquet
Link: http://a.co/7vn9ZL4

Leading the Transformation: Applying Agile and DevOps Principles at Scale

by Gary Gruver
Link: http://a.co/fttmu9m

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
by Gene Kim
Link: http://a.co/8kT8l5c
Training Retrospective
We’re here to help

Kandis O’Brien
Agile Transformation Lead
[email protected]
[email protected]

Vivek Vivek
Agile Transformation Lead
[email protected]
[email protected]

Mohammed Shafiq
Agile Coach
[email protected]
[email protected]

Kelly Fidei
Agile Coach
[email protected]

Jeff Kavanaugh
Partner
[email protected]
Appendix
 Objective:

Get In 18 minutes build the tallest free

standing structure using 20 sticks of
spaghetti, 3 feet of tape, 3 feet of string
and a marshmallow.
Rules:
1. Build the tallest structure.
2. The entire marshmallow must be on top.
3. Use as much or as little of the kit.
4. Break up the spaghetti, string or tape.
Exercise: Car of the Future
5. The teams cannot hold the structure when the
time runs out.

Instructions: 5-minute prep time

1. 18 minutes build time.
2. 10 minutes retrospective
Car of the Future
With the acceleration of trends like Autonomous Driving, the Sharing
Economy, and the Internet of Things (connected cars) the cars of the
future will offer experiences we can only imagine today.

Adient wants to maintain our competitive advantage and grow our

market share by partnering with our customers and JVs to develop
technologies that can transform the way people drive and that increase
automotive safety dramatically.

 Self organize into 4 teams of 7 or 8

 Select a Product Owner
 Select a Scrum Master
 Kick off an Agile project to design your Product Owners’ vision for the
Car of the Future
Car of the Future: What happens in the Sprints?
Sprint 0 (Initiation Sprint) Sprint 1
30 minutes 45 minutes

 Onboard team Sprint Planning (10 minutes)

 Identify Product Owner  Identify Sprint Goal
 Create Social Contract/Team Working Agreement  Estimate Stories
 Acceptance Criteria
 Define Project Vision  Interdependencies

 Create Product Backlog Sprint Execution (5 minutes)

Led by Product Owner (team contributes)  Build product / develop solution, quality assurance. You must create
 List 2 Epics something physical and tangible
 Select 1 Epic and for selected epic, list 3 Features
 Select 1 Feature and create 3 user stories to deliver Daily Stand-up 1 (3 minutes)
the feature
 Prioritize User Stories Sprint Execution (5 minutes)
 Refine User Stories for next sprint  Build product / develop solution, quality assurance

 Create Project Roadmap Daily Stand-up 2 (2 minutes)

 Establish environments Sprint Execution (2 minutes)

 Check-in, QA & final tasks to prepare for sprint review
 Scrum Master: Schedule all ceremonies
Sprint Review (5 minutes per team)
 Demo solution, car of the future prototype to the group

Sprint Retrospective – (3 minutes)

Stop, Start, Continue
Rope Challenge