Agile Transformation: EDF Training

Led by: Abdullah Khan

Introductions

▪ Name
▪ Total Experience
▪ Role
▪ Share one thing that you love to do in your spare time

2
Agenda

1. Agile and Scrum Definitions

2. Scrum Theory
3. Scrum Values
4. Scrum Team
5. Scrum Events
6. Scrum Artifacts
Long Range Planning – Key Activities

▪ Define LRP goals for 8/9 weeks duration

▪ Identify and prioritize product features for the LRP
▪ Break down features into high-level user stories for next 1-2 sprints/iterations
▪ Identify risks, issues, dependencies, and parking lot items for future discussions
▪ Enter the identified features into the ADO.

4
Long Range Planning – Output
Output

▪ Product Backlog is
produced
▪ Common vision
about what needs to
be achieved, and
when
▪ Collective ownership
and shared
understanding of
what it takes to hit
the key objectives in
the said time frame
▪ Insight into work-
streams prioritization
and sequencing of
work, via Features
and Stories
▪ Initial roadmap
▪ General sizing of
Stories and Features

5
Agile software development is a set of methods and practices based on
the values and principles expressed in the Agile Manifesto

Agile Manifesto consists of 4 core Agile values

and 12 Agile principles

Agile Evolution and Adoption Timeline

6
Core Agile Values

1 Individuals and Interactions over processes and tools

2 Working Software over comprehensive documentation

3 Customer Collaboration over contract negotiation

4 Responding to Change over following a plan

“While there is value in the items on the right, we value the items on the left more.”
7
Twelve Agile Principles
1 5
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.  agility.
Welcome changing requirements, even
2 late in development. Agile processes
harness change for the customer's
competitive advantage. 
6 of conveying information to and within a
Deliver working software frequently,
3 7
from a couple of weeks to a couple of
months, with a preference to the shorter
timescale. 
4 8
Business people and developers must
work together daily throughout the
project. 
Build projects around motivated
9
Continuous attention to technical
individuals. Give them the environment
excellence and good design enhances
and support they need, and trust them
 
to get the job done. 
The most efficient and effective method
development team is face-to-face
conversation.
10 Simplicity– develop just enough to get
the job done for right now
11
The best architectures, requirements,
Working software is the primary
and designs emerge from self-
measure of progress. 
organizing teams. 
Agile processes promote sustainable At regular intervals, the team reflects on
12
development. The sponsors, how to become more effective, then
developers, and users should be able to tunes and adjusts its behavior
maintain a constant pace indefinitely.  accordingly. 
8
Scrum – Definition

What is Scrum? What Scrum is NOT?

Scrum is a lightweight framework that helps people,

Scrum is not a process, technique, or definitive
teams and organizations generate value through
method
adaptive solutions for complex problems.

Scrum Usage
➢ Research and identify viable markets, technologies, and product capabilities
➢ Develop products and enhancements
➢ Release products and enhancements, as frequently as many times per day
➢ Develop and sustain Cloud and other operational environments for product use
➢ Sustain and renew products

9
Scrum – Theory

Empiricism & Lean? Iterative & Incremental?

Scrum is founded on empiricism and lean thinking.
Empiricism asserts that knowledge comes from experience
and making decisions based on what is observed. Lean
thinking reduces waste and focuses on the essentials.
Scrum employs an iterative, incremental approach to
optimize predictability and to control risk. Scrum engages
groups of people who collectively have all the skills and
expertise to do the work and share or acquire such skills as
needed.

Events & Pillars

➢ Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint.
➢ These events work because they implement the empirical Scrum pillars of:
• Transparency
• Inspection
• Adaptation

10
Scrum Values

▪ The decisions that are made, the steps taken, and the way Scrum is used should reinforce these
values, not diminish or undermine them.
▪ The Scrum Team members learn and explore the values as they work with the Scrum events
and artifacts.
▪ When these values are embodied by the Scrum Team and the people they work with, the
empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.
• Successful use of Scrum depends on people becoming more proficient in living five values:
1. Commitment
2. Focus
3. Openness
4. Respect
5. Courage

11
Scrum Team

▪ The fundamental unit of Scrum is a small team of people, a Scrum Team.

▪ The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.
▪ Within a Scrum Team, there are no sub-teams or hierarchies.
▪ It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
▪ Scrum Teams are cross-functional, meaning the members have all the skills necessary to
create value in each Sprint.
▪ They are also self-managing, meaning they internally decide who does what, when, and how.
▪ The Scrum Team is small enough to remain nimble and large enough to complete significant
work within a Sprint, typically 10 or fewer people.
▪ In general, we have found that smaller teams communicate better and are more productive.
▪ If Scrum Teams become too large, they should consider reorganizing into multiple cohesive
Scrum Teams, each focused on the same product.
▪ Therefore, they should share the same Product Goal, Product Backlog, and Product Owner

12
Scrum Team (Conti…..)

▪ The Scrum Team is responsible for all product-related activities from stakeholder collaboration,
verification, maintenance, operation, experimentation, research and development, and anything
else that might be required.
▪ They are structured and empowered by the organization to manage their own work.
▪ Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
▪ The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
▪ Scrum defines three specific accountabilities within the Scrum Team:
▪ The Developers
▪ The Product Owner
▪ The Scrum Master

13
Developers

▪ Developers are the people in the Scrum Team that are committed to creating any aspect of a
usable Increment each Sprint.
▪ The specific skills needed by the Developers are often broad and will vary with the domain of
work.
▪ However, the Developers are always accountable for:
▪ Creating a plan for the Sprint, the Sprint Backlog
▪ Instilling quality by adhering to a Definition of Done
▪ Adapting their plan each day toward the Sprint Goal
▪ Holding each other accountable as professionals

14
Product Owner

▪ The Product Owner is accountable for maximizing the value of the product resulting from the
work of the Scrum Team.
▪ How this is done may vary widely across organizations, Scrum Teams, and individuals.
▪ The Product Owner is also accountable for effective Product Backlog management, which
includes:
▪ Developing and explicitly communicating the Product Goal
▪ Creating and clearly communicating Product Backlog items
▪ Ordering Product Backlog items
▪ Ensuring that the Product Backlog is transparent, visible and understood
▪ The Product Owner may do the above work or may delegate the responsibility to others.
Regardless, the Product Owner remains accountable.

15
Scrum Master

▪ The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
▪ They do this by helping everyone understand Scrum theory and practice, both within the Scrum
Team and the organization.
▪ The Scrum Master is accountable for the Scrum Team’s effectiveness.
▪ They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
Scrum Masters are True Leaders who serve the Scrum Team and the larger organization.

▪ The Scrum Master serves the Scrum Team in several ways, including:
▪ Coaching the team members in self-management and cross-functionality
▪ Helping the Scrum Team focus on creating high-value Increments that meet the Definition
of Done
▪ Causing the removal of impediments to the Scrum Team’s progress
▪ Ensuring that all Scrum events take place and are positive, productive, and kept within the
timebox

16
Scrum Master

▪ The Scrum Master serves the Product Owner in several ways, including:
▪ Helping find techniques for effective Product Goal definition and Product Backlog
management
▪ Helping the Scrum Team understand the need for clear and concise Product Backlog items
▪ Helping establish empirical product planning for a complex environment
▪ Facilitating stakeholder collaboration as requested or needed

▪ The Scrum Master serves the organization in several ways, including:

▪ Leading, training, and coaching the organization in its Scrum adoption
▪ Planning and advising Scrum implementations within the organization
▪ Helping employees and stakeholders understand and enact an empirical approach for
complex work
▪ Removing barriers between stakeholders and Scrum Teams

17
18
Agile Delivery Using Engagement Delivery
Framework
What does EDF solve?

▪ Clarity/alignment of business outcomes

▪ Evolving business needs
▪ Evolving and dynamic development
▪ Complex team structures
▪ Inadequate engagement methods
▪ Lack of transparency, inspection, adaptation
▪ Lack of feedback processes

20
What is EDF?

▪ Engagement Delivery Framework

▪ Agile delivery methodology based on core Agile Manifesto “four tenants,” “12 Agile
principles,” and “Scrum Framework”
▪ Adopted by Amazon.com, Amazon Professional Services, and Onica to deliver
better outcomes
▪ Based on the core Amazonian principle of “Customer Obsession”
▪ Built on the foundation that business value delivered to the customer is the ultimate
measure of success

21
Why EDF?

▪ Change is inevitable
▪ Ideas are better conveyed through interaction
▪ Plans never survive first contact
▪ Customer Acceptance is the only true measure of progress
▪ Business value is the ultimate measure of success

22
EDF Essentials: Sprint Duration

Average new Scrum

team takes 4-6, 2 EDF shrinks this by
week iterations to 50% (4-6, 1 week
begin to norm. iterations to norm)

Sprint Duration – 1 Week

23
Two Weeks Sprint FAQs
▪ What do we do if our stories are longer than two sprint?
▪ What happens if a story “bleeds?” Is this a bad thing?
▪ Our QA process takes more than five days, can we still do two weeks sprints?
▪ If we do two weeks sprints, how much time do we spend on EDF ceremonies?
▪ What is the ideal size for a story in two week sprint? 3 Days / 3 Story Point / 3 Mandays
▪ Do we estimate “spikes”? YES > Min 0.5 Days or Max 3 Days

▪ Daily Scrum > 8 Days > 8 * 15 = 120 mins = 2 hours

▪ Grooming = 1.5 hours
▪ Planning = 2 hours
▪ Demo/Sprint Review/Show&Tell = 2 hours
▪ Retrospective = 30 minutes
▪ Total Hours for 5 Ceremonies = 7 Hours.

▪ Confluence Link: https://eilago2.atlassian.net/l/cp/hW6nNM2Z

24
EDF Delivery Model

Retrospective

Replenish
Backlog
Grooming Daily
Scrum

Product
Backlog

Sprint Sprint
Planning Review

Long Range Sprint Iterative

1 Week
Planning Backlog Delivery

Sprint

25
Long Range Planning (LRP)

Retrospective

Replenish
Backlog
Grooming Daily
Stand
Up
Product
Backlog

Sprint Sprint
Planning Review

Long Range Sprint Iterative

1 Week
Planning Backlog Delivery

Sprint

26
Long Range Planning

What is the purpose?

Converting notional ideas of what needs to be done into
tangible products (Features or Stories). Feature

What are the User

Who needs to do this? capabilities we Stories
LRP is done in close cooperation with the customer, usually want to build?
guided or directed by the project Product Owner with
participation from the Scrum Master and relevant team
members. Feature

When does this occur?

LRP is done at the beginning of a project (immediately
following or sometimes during discovery sessions), and on
an as-needed basis as the project progresses

Feature
How does it look when we’re done?
The product backlog is populated with a combination of
high-level Features and Stories. These are not in a state
where they are ready to be worked.
Customer(s) “Product”
Backlog

27
Long Range Planning – Key Activities

▪ Define LRP goals for 8/9 weeks duration

▪ Identify and prioritize product features for the LRP
▪ Break down features into high-level user stories for next 1-2 sprints/iterations
▪ Identify risks, issues, dependencies, and parking lot items for future discussions
▪ Enter the identified features into the ADO.

28
Long Range Planning – Output
Output

▪ Product Backlog is
produced
▪ Common vision
about what needs to
be achieved, and
when
▪ Collective ownership
and shared
understanding of
what it takes to hit
the key objectives in
the said time frame
▪ Insight into work-
streams prioritization
and sequencing of
work, via Features
and Stories
▪ Initial roadmap
▪ General sizing of
Stories and Features

29
Sprint Planning

Retrospective

Replenish
Backlog
Grooming Daily
Stand
Up
Product
Backlog

Sprint Sprint
Planning Review

Long Range Sprint Iterative

1 Week
Planning Backlog Delivery

Sprint

30
Sprint Planning

What is the purpose?

Feature
Sprint Planning is done to determine which items
from the Product Backlog will be worked during the
next sprint and to ensure clarity of scope / User Stories O S
acceptance / estimates by all parties.

Who needs to do this?

Sprint Planning is run by the Scrum Master with Feat
participation from the Product Owner and Delivery ure
Team
User Stories
Sprint
When does this occur? Planning
Sprint planning is conducted on the first day of a new
sprint, ideally weekly on Tue, Wed, or Thu.
Feat
How does it look when we’re done? ure
The Sprint Backlog (not the product backlog) is User Stories
populated with fully written and estimated stories that
are expected to be completed during the sprint. ”Product” Sprint
Backlog Backlog

31
Sprinting

Retrospective

Replenish
Backlog
Grooming Daily
Stand
Up
Product
Backlog

Sprint Sprint
Planning Review

Long Range Sprint Iterative

1 Week
Planning Backlog Delivery

Sprint

32
Sprinting

TFS
What is the purpose? Work In Progress
A Sprint serves to limit the amount of Work In
Progress and increase the frequency of of feedback
loops, reducing rework and waste.

Who needs to do this?

The whole team participates in the Sprint. The S
customer is usually only involved only to provide
clarifications for the team (as needed).

When does this occur?

In 1-week interval continuously for the duration of the
project.

How does it look when we’re done?

At the end of a Sprint, all of the work in the Sprint
Backlog should be “Ready for Acceptance.”
Ready for Acceptance
Sprint
Backlog

33
Sprint Cadence

THURSDAY FRIDAY MONDAY TUESDAY WEDNESDAY

SATURDAY SUNDAY
• Sprint Review
• Daily Stand • Daily Stand • Daily Stand • Daily Stand Up • Sprint Demo
Up Up Up • Backlog • Sprint
Refinement Retrospective
• Sprint Review • Sprint Planning
Prep

34
Daily Scrum

▪ The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the
Sprint Backlog as necessary, adjusting the upcoming planned work.
▪ The Daily Scrum is a 15-minutes event for the Developers of the Scrum Team.
▪ To reduce complexity, it is held at the same time and place every working day of the Sprint.
▪ If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they
participate as Developers.
▪ The Developers can select whatever structure and techniques they want, as long as their Daily
Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next
day of work.
▪ This creates focus and improves self-management.
▪ Daily Scrums improve communications, identify impediments, promote quick decision-making,
and consequently eliminate the need for other meetings.
▪ The Daily Scrum is not the only time Developers are allowed to adjust their plan.
▪ They often meet throughout the day for more detailed discussions about adapting or re-planning
the rest of the Sprint’s work.

35
Sprint Review

Retrospective

Replenish
Backlog
Grooming Daily
Stand
Up
Product
Backlog

Sprint Sprint
Planning Review

Long Range Sprint Iterative

1 Week
Planning Backlog Delivery

Sprint

36
 Sprint Review
What is the purpose?
To have the product owner validate that the
TFS
I agree. “Yes, I will
deliverable meets the acceptance criteria. buy story 123.”
Deliverables can be most anything, but must be
demonstrable (working features, code snippet,
template, document, config change, etc.). Great! I’ll mark it as
O Accepted!
Who needs to do this?
The entire team should participate in the Sprint
Review. Whoever completed the story should S
demonstrate it’s completion and “sell” it to the 123 123
product owner.

When does this occur? We have demonstrated

Upon the conclusion of a sprint. story 123 and that all
acceptance criteria are
met. Will you buy it?
How does it look when we’re done?
Ideally, a list of accepted stories in TFS that are now
considered “DONE”. Stories that do not meet the
acceptance criteria are returned to the backlog with
specific feedback and will be reconsidered during Sprint
Sprint Planning. Backlog Accepted

37
Sprint Retrospective

Retrospective

Replenish
Backlog
Grooming Daily
Stand
Up
Product
Backlog

Sprint Sprint
Planning Review

Long Range Sprint Iterative

1 Week
Planning Backlog Delivery

Sprint

38
 Sprint Retrospective

What is the purpose?

To gather constructive and actionable feedback that Bad There was too much This documentation lacks The customer is
will improve subsequent Sprints. planned for this Sprint. details unresponsive, so we can’t
Feedback move forward.
(Broad / Vague) Your code is crap.
Who needs to do this?
We really The networking diagrams We need the customer to
The entire team should participate in the Sprint underestimated the don’t show ingress/egress provide an updated
Retrospective. The Sprint Retro may or may not complexity of Oracle points and there are entire network diagram in order
include the Customer/Product Owner depending 11. segments of the architecture to us to finish the VPC
upon the dynamics of the team. missing. We need to plan a CloudFormation
Good We really need story to revisit this templates. We can do “X”
Feedback someone who knows document. until that’s done, but after
When does this occur? (Specific / Cloud Formation. Tuesday this will block us
Upon the conclusion of a sprint, generally after Sprint Actionable) Billy, your code isn’t from moving forward.
Our velocity isn’t what following our style guide and
Review. we expected…we your unit tests coverage is
need to build-in time to insufficient. Let’s take some
How does it look when we’re done? ramp-up on this tech time next sprint to do some
stack. peer-programming and
A compiled list of actionable feedback that will be improve things.
used to improve subsequent Sprints. Can be
captured in Confluence or any tool of the team’s
choosing.

39
Backlog Grooming

Retrospective

Replenish
Backlog
Grooming Daily
Stand
Up
Product
Backlog

Sprint Sprint
Planning Review

Long Range Sprint Iterative

1 Week
Planning Backlog Delivery

Sprint

40
 Backlog Grooming

What is the purpose?

Epic/
To ensure the Product Backlog is filled with
Feature
actionable items (Stories and Tasks). This is done by
breaking down Epics into stories, and stories into User Stories
tasks (where needed) S

Who needs to do this?

Grooming is performed by the Scrum Master, with
Epic/
input from other members of the team and Feature
occasionally the customer when needed
User Stories
When does this occur? Grooming
Grooming is done weekly and should be done at the
latest 1-day prior to sprint planning. It can be done
further in advance if desired User
Epic/
Feature Stories
How does it look when we’re done? User Stories
A Product Backlog populated with stories that are
ready to be moved into sprints and worked. Epics still ”Product” ”Product”
exist, but only as logical groups of stories.
Backlog Backlog

41
Scrum Artifacts

▪ Scrum’s artifacts represent work or value.

▪ They are designed to maximize transparency of key information.
▪ Thus, everyone inspecting them has the same basis for adaptation.
▪ Each artifact contains a commitment to ensure it provides information that enhances
transparency and focus against which progress can be measured:
▪ For the Product Backlog it is the Product Goal
▪ For the Sprint Backlog it is the Sprint Goal
▪ For the Increment it is the Definition of Done
▪ These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team
and their stakeholders.
▪ 3 Artifacts:
1. Product Backlog
2. Sprint Backlog
3. Increment
42
Product Backlog

▪ The Product Backlog is an emergent, ordered list of what is needed to improve the product.
▪ Product Backlog Refinement (Backlog Grooming) is the act of breaking down and further defining Product
Backlog items into smaller more precise items.
▪ This is an ongoing activity to add details, such as a description, order, and size.
▪ Attributes often vary with the domain of work.
▪ The Developers who will be doing the work are responsible for the sizing.
▪ The Product Owner may influence the Developers by helping them understand and select trade-offs.

Commitment: Product Goal

▪ The Product Goal describes a future state of the product which can serve as a target for the Scrum Team
to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to
define “what” will fulfill the Product Goal.

▪ A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or
customers. A product could be a service, a physical product, or something more abstract.

43
Sprint Backlog

▪ The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog
items selected for the Sprint (what), as well as an actionable plan for delivering the
Increment (how).

Commitment: Sprint Goal

▪ The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a
commitment by the Developers, it provides flexibility in terms of the exact work needed
to achieve it. The Sprint Goal also creates coherence and focus, encouraging the
Scrum Team to work together rather than on separate initiatives.

44
Increment

▪ An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all
prior Increments and thoroughly verified, ensuring that all Increments work together. In order to
provide value, the Increment must be usable.
▪ Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the
Sprint Review thus supporting empiricism.
▪ However, an Increment may be delivered to stakeholders prior to the end of the Sprint.
▪ The Sprint Review should never be considered a gate to releasing value.

Commitment: Definition Of Done

▪ The Definition of Done is a formal description of the state of the Increment when it meets the quality
measures required for the product.
▪ The moment a Product Backlog item meets the Definition of Done, an Increment is born.
▪ The Definition of Done creates transparency by providing everyone a shared understanding of what
work was completed as part of the Increment.
▪ If a Product Backlog item does not meet the Definition of Done, it cannot be released or even
presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration
45
Scrum Essentials

• Inspection
3 • Adaptation
Core Pillars • Transparency

• Commitment • Openness
5 • Courage • Respect
Core Values • Focus

• Scrum Master
Scrum Team • Product Owner
• The Developers

• The Sprint • Sprint Retrospective

5 • Sprint Planning
Events/Ceremonies • Daily Scrum Backlog Grooming (An Activity)
• Sprint Review

• Product Backlog
Scrum Artifacts • Sprint Backlog
• Product Increment
46
47
Q&A
49