Doing & Being Agile

Maisara Khedr
● Over 10 years experience in software industry
● Over 5 years as a Scrum Master in more than
15 teams.
● Certified Professional Scrum Master from
Scrum.org
● Certified Agile Coach from ICAgile
●
●
Certified Agile Professional from ICAgile
Certified Agile Team Facilitation from ICAgile
Maisara Khedr
Agenda ?
1970
Waterfall

History Timeline
Waterfall
● Originated in manufacturing and construction industries
● 1970, Cited by Winston W.Royce.
● 1976, Bell & Thayer firstly used the term.

Royce’s Paper
“I believe in this concept but the implementation
described above is risky and invites failure.”

W.Royce
1976
Waterfall

1991
Rapid Application
Development

History Timeline
Rapid Application Development
● 1986, Barry Boehm developed the Spiral model.
Rapid Application Development
● 1991, James Martin published RAD Book.
1976 1995
Waterfall Scrum

1991
Rapid Application
Development

History Timeline
Scrum
Scrum
● 1986, Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum.
● 1990s, Ken Schwaber used what would become Scrum at his company.
● 1990s, Jeff Sutherland, John Scumniotales and Jeff McKenna, developed a
similar approach at Easel Corporation, referring to it as Scrum.
● 1995, Sutherland and Schwaber jointly presented a paper describing the
Scrum framework.
● 2002, Schwaber, Sutherland, Mike Cohn and others founded the Scrum
Alliance.
1976 1995
Waterfall Scrum

1991 1996
Rapid Application Extreme
Development Programming

History Timeline
Extreme Programming
● 1993, The C3 project started in Chrysler.
● 1996, Kent Beck & Ron Jeffries was hired to get the thing working.
● System is delivered in 14 months. the development team adopted a way
of working which is now formalized as Extreme Programming
methodology.
● Extreme Programming Team
○ The Customer
○ The Developer
○ The Tracker
○ The Coach
Extreme Programming - Practices
● Every contributor to the project is an
integral part of the “Whole Team”
● Extreme programming teams use a
simple form of planning and tracking
to decide what should be done next
and to predict when the project will
be done. Focused on business value,
the team produces the software in a
series of small fully-integrated
releases that pass all the tests the
Customer has defined.
What is Extreme Programming? Ron Jeffries
Extreme Programming - Practices
● The Extreme Programming team
keeps the system integrated and
running all the time.
● The programmers code in a consistent
style so that everyone can understand
and improve all the code as needed.
● Extreme Programming is about team
responsibility for all code, for coding
in a consistent pattern so that
everyone can read everyone’s code.
● The Extreme Programming team
works at a pace that can be sustained What is Extreme Programming? Ron Jeffries
indefinitely.
Extreme Programming - Practices
● Extreme Programmers work
together in pairs and as a
group, with simple design and
obsessively tested code,
improving the design
continually to keep it always
just right for the current needs.

What is Extreme Programming? Ron Jeffries

 1997
1976 1995 Feature Driven
Waterfall Scrum Development

1991 1996
Rapid Application Extreme
Development Programming

History Timeline
Feature Driven Development
● 1997, initially devised by Jeff De Luca to meet the specific needs of a
15-month, 50-person software development project at a large Singapore
bank.
● FDD is a model-driven short-iteration process that consists of five basic
activities.
○ Develop overall model
○ Build feature list
○ Plan by feature
○ Design by feature
○ Build by feature
 1997
1976 1995 Feature Driven
Waterfall Scrum Development

1991 1996 2001

Rapid Application Extreme Agile Manifesto
Development Programming

History Timeline
Exercise 1: Build Table and Chairs with Popsicle Sticks
Exercise 1: Build Table and Chairs with Popsicle Sticks
Exercise 1: Build Table and Chairs with Popsicle Sticks
What is Agility?
● Flexibility
● The power of moving quickly and easily;
● Being able to navigate through constraints!!
Software Development is a Knowledge Work
1. Exact outcome is not knowable in advance (IKIWISI)
2. Outcome based on intangible thoughts and knowledge
3. Empirical process to realize the outcome
Product Development is a Knowledge Work!
● Outcome based on intangible thoughts and knowledge
● Exact outcome is not knowable in advance (IKIWISI)
● Empirical process to realize the outcome

That’s why we need Agility

Stages of Learning
Shu-Ha-Ri is a way of thinking about how you learn a technique. The name comes
from Japanese martial arts (particularly Aikido),

Shu (Follow the rule) Ha (Break the rule) Ri (Be the Rule)
The student follows the teachings the student begins to branch out. Now the student isn't learning from
of one master precisely. He With the basic practices working he other people, but from his own
concentrates on how to do the task, now starts to learn the underlying practice. He creates his own
without worrying too much about principles and theory behind the approaches and adapts what he's
the underlying theory. technique. He also starts learning learned to his own particular
from other masters and integrates circumstances.
that learning into his practice.
 On February 11-13, 2001 , at The Lodge at Snowbird ski resort

Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal,
Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an
alternative to documentation driven, heavyweight software development processes convened.

What emerged was the Agile ‘Software Development’ Manifesto.

The Agile 17 Authors
Agile Values
Individuals and Interactions Over Processes and Tools.

Working Software Over Comprehensive Documentation.

Customer Collaboration Over Contract Negotiation.

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.
Agile Principles
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
Agile Principles
5. Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
Agile Principles
9. Continuous attention to technical excellence and good design enhances
agility.
10. Simplicity --the art of maximizing the amount of work not done-- is
essential.
11. The best architectures, requirements, and designs emerge from
self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.
Agile Adoption vs Agile Transformation
Agile Adoption Agile Transformation
Is a change in process to one that is is the process of transforming an
consistent with the Agile Values and Principles organization’s culture and nature to one of
agility. Transformation is about a
fundamental change in the way people think
and feel.

Doing Agile Being Agile

Rubber Band Model By Ahmed Sidky
Rubber Band Model By Ahmed Sidky
 Sustainable
Transformation
What we really need?
Rubber Band Model By Ahmed Sidky
Rubber Band Model By Ahmed Sidky
Mindset Culture

?? ??
Mindset

Mindset (n) the established set of attitudes held by someone.

Fixed vs Growth Mindset
Fixed vs Growth Mindset
Fixed vs Growth Mindset
Theory-X vs Theory-Y Mindset
Theory-X Theory-Y
Work is inherently distasteful to most Most people find happiness in hard work
people, and they will attempt to avoid work under the right conditions.
whenever possible.

Most people avoid responsibility and need People enjoy taking ownership of their
constant direction. work.

People must be constantly directed, People are self-motivated and embrace

prompted, rewarded, or punished in order responsibility.
to complete their work.
Theory-X vs Theory-Y Mindset
Theory-X Theory-Y
Lack of ambition and laziness is more Creativity and problem-solving thrive when
common than ambition and creativity. employees are trusted.

People are motivated by money and fears People are motivated when they find value
about their job security. in their contributions and see an opportunity
to realize their own potential.
The Agile Mindset By Ahmed Sidky
Culture
Culture (N) the ideas and social behaviour of a particular people or society.

Culture (N) Set of beliefs and values shared by members of a group that
leads to certain patterns of behavior.

Culture is shared by group members, transferred from one member to

another and it affects thinking and behavior.
The Culture of Organizational Agility
Organizational Agility is a culture based on the values and principles of Agile
supported by the organization ecosystem (Leadership, Strategy, Structure,
Process and People) and manifested through personal and organizational
habits (how work really done in the organization)
 Mindset Culture

Organizational
Agile Mindset
Agility
Rubber Band Model By Ahmed Sidky
 1997
1976 1995 Feature Driven 2003
Waterfall Scrum Development Lean

1991 1996 2001

Rapid Application Extreme Agile Manifesto
Development Programming

History Timeline
2. The Lean Mindset
Toyota Production System
● Henry Ford was the first to truly integrate a production system called
‘mass-production’, which manufactures large quantities of standardized
products
● After studying Ford’s production system, Eiji Toyoda understood that the
mass production system employed by Ford cannot be used by Toyota.
The Japanese market was too small and diverse for mass production.
● 1930s, Kiichiro Toyoda, Taiichi Ohno, and others at Toyota revisited Ford’s
original thinking, and invented the Toyota Production System.
 what is needed,
Automation with
when it is needed,
a human touch
and in the amount
needed

Continuous
Production
Improvement
Leveling

Toyota Production System

Lean
● Lean is the concept of efficient manufacturing/operations that grew out of
the Toyota Production System in the middle of the 20th century.
● It is based on the philosophy of defining value from the customer’s
viewpoint, and continually improving the way in which value is
delivered, by eliminating every use of resources that is wasteful, or that
does not contribute to the value goal.
● Lean ultimate goal is providing perfect value to the customer through a
perfect value creation process that has zero waste.
5 Lean Principles
Lean Software Development
● 2003, Mary and Tom Poppendieck published “Lean Software Development: An Agile
Toolkit” book.
● Mary had worked in a manufacturing plant that had adopted lean
manufacturing and her husband Tom is an experienced software
developer.
Lean Software Development - Principles
● Eliminate waste

Manufacturing Waste Software Waste

Inventory Partially Done Work

Overproduction Extra Features

Extra-Processing Relearning

Transportation Handoffs

Waiting Delays

Motion Tasks Switching

Defects Defects
Lean Software Development - Principles
● Amplify learning
○ Improve software development by learning continuously.

● Decide as late as possible

○ Delay decisions - as possible - until they can be based on facts not assumptions &
predictions.
Lean Software Development - Principles
● Deliver as fast as possible
○ Customer value rapid and frequent delivery of a quality product.

● Empower the team

○ Find good people and let them do their job.
Lean Software Development - Principles
● Build integrity in
○ Maintain integrity by focusing in customer needs, keeping things simple and eliminating
waste.

● See the whole

○ Think big but act small. We build a large system by breaking it into smaller parts,but
attention needs to be given to the larger interactions with other components and
systems.
 1997
1976 1995 Feature Driven 2003
Waterfall Scrum Development Lean

1991 1996 2001 2009

Rapid Application Extreme Agile Manifesto DevOps
Development Programming

History Timeline
3. DevOps Culture
DevOps
● DevOps is a set of practices intended to reduce the time between
committing a change to a system and the change being placed into
normal production, while ensuring high quality
DevOps Culture
● DevOps is a culture, a movement, a philosophy.
● DevOps is the combination of cultural philosophies, practices, and tools
that increases an organization’s ability to deliver applications and services
at high velocity.
● Transitioning to DevOps requires a change in culture and mindset. At its
simplest, DevOps is about removing the barriers between two
traditionally siloed teams, development and operations.
DevOps
DevOps
Shared Development & Operations duties
● Software deployments
● Application support
Operations responsibilities
● IT buying
● Installation of server hardware and OS
● Configuration of servers, networks, storage, etc…
● Monitoring of servers
● Respond to outages
● IT security
● Backup and disaster recovery planning
So what part of the “Ops” duties should developers
be responsible for?
● Be involved in selecting the application stack
● Configure and deploy virtual or cloud servers (potentially)
● Deploy their applications
● Monitor application and system health
● Respond to applications problems as they arise.
So what does the operations team do then?
● Manage the hardware infrastructure
● Configure and monitor networking
● Enforce policies around backup, DR, security, compliance, change control,
etc
● Assist in monitoring the systems
DevOps Organizations
● First, Ops is focused on enabling people to reach goals by applying
strategic and tactical use of process and technological tools.
● Second, good DevOps organizations have learned to negotiate the
balance of velocity with stability in order to protect organizational values
without sacrificing flexibility or the ability to innovate.
● Third, they automate where possible, enable where necessary, but avoid
premature optimization.
Unless you currently do both Development AND
Operations separately, and do them well, AND
you’re now trying to synthesise a better, more
agile, more cloud-oriented way of working that
takes the best part of both disciplines … you
aren’t doing DevOps!
DevOps Practices
● Continuous Integration
● Continuous Delivery
● Microservices
● Infrastructure as Code
● Monitoring and Logging
● Communication and Collaboration
 1997
1976 1995 Feature Driven 2003 2009
Waterfall Scrum Development Lean Scrum Guide

1991 1996 2001 2009

Rapid Application Extreme Agile Manifesto DevOps
Development Programming

History Timeline
 1. Introduction
2. Scrum Team
Scrum 3.
4.
Scrum Artifacts
Scrum Sprint
5. Scrum Events
6. Flaccid Scrum
 Module 1

Introduction
 Module 1

Introduction 1.1 Scrum History

1986, Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum.
Over Years!
● 1990s, Ken Schwaber used what would become Scrum at his company.
● 1990s, Jeff Sutherland, John Scumniotales and Jeff McKenna, developed a
similar approach at Easel Corporation, referring to it as Scrum.
● 1995, Sutherland and Schwaber jointly presented a paper describing the
Scrum framework.
● 2002, Schwaber, Sutherland, Mike Cohn and others founded the Scrum
Alliance.
● 2009, publish Scrum body of knowledge “Scrum Guide”.
● 2009, Ken Schwaber founded Scrum.org
 Module 1

Introduction 1.2 Scrum Definition

Definition of Scrum

Scrum (n): A framework within which people can address

complex adaptive problems, while productively and
creatively delivering products of the highest possible
value.
Definition of Scrum
Scrum is:

● Lightweight
● Simple to understand
● Difficult to master

Scrum is not a process, technique, or definitive method. Rather, it is a

framework within which you can employ various processes and techniques.
 Module 1

Introduction 1.3 Scrum Theory

Scrum Theory
● Scrum is founded on empirical process control theory, or empiricism.
● Empiricism asserts that knowledge comes from experience and making
decisions based on what is known.
● Expect the unexpected.
● Progress is based on observation and experimentation instead of
detailed, upfront planning and defined processes
Scrum Theory
● Scrum Characteristics
○ Learn as we progress
○ Expect and embrace change
○ Inspect and adapt using short development cycles
○ Estimates are indicative only and may not be accurate
Scrum Theory
● Scrum employs an iterative, incremental approach to optimize
predictability and control risk.
● An iterative process is one that makes progress through successive
refinement. With each iteration, the software is improved through the
addition of greater detail.
Scrum Theory
● An incremental process is one in which software is built and delivered in
pieces. Each piece, or increment, represents a complete subset of
functionality.
● It’s iterative in that it plans for the work of one iteration to be improved
upon in subsequent iterations. It’s incremental because completed work
is delivered throughout the project.
Scrum Theory
● Three pillars uphold every implementation of empirical process control:
○ Transparency
○ Inspection
○ Adaptation.
 Module 1

Introduction 1.4 Scrum Values

Scrum Values
Successful use of Scrum depends on people becoming more proficient in
living these five values.

1. People personally commit to achieving the goals of the Scrum Team.

2. The Scrum Team members have courage to do the right thing and work
on tough problems.
Scrum Values
Successful use of Scrum depends on people becoming more proficient in
living these five values.

3. Everyone focuses on the work of the Sprint and the goals of the Scrum
Team. The Scrum Team and its stakeholders agree to be open about all
the work and the challenges with performing the work.
4. Scrum Team members respect each other to be capable, independent
people.
 Module 1

Introduction 1.5 Sprint

Sprint
● The heart of Scrum is a Sprint
● a time-box of one month or less during which a "Done", useable, and
potentially releasable product Increment is created.
● Sprints have consistent durations throughout a development effort. A
new Sprint starts immediately after the conclusion of the previous Sprint.
Sprint
● During the Sprint:
○ No changes are made that would endanger the Sprint Goal;
○ Quality goals do not decrease; and,
○ Scope may be clarified and re-negotiated between the Product Owner and Development
Team as more is learned.
Sprint
● Canceling a Sprint:
○ A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has
the authority to cancel the Sprint
○ A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the
company changes direction or if market or technology conditions change.
○ due to the short duration of Sprints, cancellation rarely makes sense.
 Module 2

Scrum Team
 Module 2

Scrum Team 2.1 Product Owner

Product Owner
● The Product Owner is responsible for maximizing the value of the product
resulting from work of the Development Team.
● The Product Owner is one person, not a committee. The Product Owner
may represent the desires of a committee in the Product Backlog.
● The Product Owner’s decisions are visible in the content and ordering of
the Product Backlog. No one can force the Development Team to work
from a different set of requirements.
Product Backlog Management
● The Product Owner is the sole person responsible for managing the
Product Backlog.
1. Clearly expressing Product Backlog items;
2. Ordering the items in the Product Backlog to best achieve goals and missions;
3. Optimizing the value of the work the Development Team performs;
Product Backlog Management
● The Product Owner is the sole person responsible for managing the
Product Backlog.
4. Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what
the Scrum Team will work on next; and,
5. Ensuring the Development Team understands items in the Product Backlog to the level
needed.
● The Product Owner may do the above work, or have the Development
Team do it. However, the Product Owner remains accountable.
Stakeholder Expectations
● Stakeholder lock the 3 aspects cost, time and scope, either sacrifice
quality or one of the 3 aspects.
● PO order the importance of the 3 aspects
Stakeholder Expectations
● Multiple stakeholders with different expectations.
● PO define project success aspects importance
○ Cost
○ Time
○ Scope
○ Quality
○ Stakeholder Satisfaction
○ Team Satisfaction
 Module 2

Scrum Team 2.4 Development Team

Development Team
● Development Teams are structured and empowered by the organization
to organize and manage their own work.
● They are self-organizing. No one (not even the Scrum Master) tells the
Development Team how to turn Product Backlog into Increments of
potentially releasable functionality;
● Development Teams are cross-functional, with all the skills as a team
necessary to create a product Increment;
Development Team
● Scrum recognizes no titles for Development Team members, regardless of
the work being performed by the person;
● Scrum recognizes no sub-teams in the Development Team, regardless of
domains that need to be addressed like testing, architecture, operations,
or business analysis; and,
● Individual Development Team members may have specialized skills and
areas of focus, but accountability belongs to the Development Team as a
whole.
 Module 2

Scrum Team 2.5 Scrum Master

Scrum Master
The Scrum Master is responsible for promoting and supporting Scrum as
defined in the Scrum Guide. Scrum Masters do this by helping everyone
understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master
helps those outside the Scrum Team understand which of their interactions
with the Scrum Team are helpful and which aren’t. The Scrum Master helps
everyone change these interactions to maximize the value created by the
Scrum Team.
Scrum Master Service to the Product Owner
● Ensuring that goals, scope, and product domain are understood by
everyone on the Scrum Team as well as possible;
● Finding techniques for effective Product Backlog management;
● Helping the Scrum Team understand the need for clear and concise
Product Backlog items;
● Understanding product planning in an empirical environment;
● Ensuring the Product Owner knows how to arrange the Product Backlog
to maximize value;
● Understanding and practicing agility; and,
● Facilitating Scrum events as requested or needed.
Scrum Master Service to the Development Team
● Coaching the Development Team in self-organization and
cross-functionality;
● Helping the Development Team to create high-value products;
● Removing impediments to the Development Team’s progress;
● Facilitating Scrum events as requested or needed; and,
● Coaching the Development Team in organizational environments in which
Scrum is not yet fully adopted and understood.
Scrum Master Service to the Organization
● Leading and coaching the organization in its Scrum adoption;
● Planning Scrum implementations within the organization;
● Helping employees and stakeholders understand and enact Scrum and
empirical product development;
● Causing change that increases the productivity of the Scrum Team; and,
● Working with other Scrum Masters to increase the effectiveness of the
application of Scrum in the organization.
 Module 3

Scrum Artifacts
 Module 3

Scrum Artifacts 3.1 Increment

Increment
● The Increment is the sum of all the Product Backlog items completed
during a Sprint and the value of the increments of all previous Sprints.
● The increment must be in useable condition regardless of whether the
Product Owner decides to release it.
 Module 3

Scrum Artifacts 3.2 Product Backlog

Product Backlog

The Product Backlog is an ordered list of

everything that is known to be needed in the
product. It is the single source of requirements
for any changes to be made to the product
Scrum Guide
Product Backlog
● The Product Owner is responsible for the Product Backlog, including its
content, availability, and ordering.
● The Product Backlog evolves as the product evolves.
● Product Backlog refinement is the act of adding detail, estimates, and
order to items in the Product Backlog. This is an ongoing process in which
the Product Owner and the Development Team collaborate on the details
of Product Backlog items.
Product Backlog Management
● Clearly expressing Product Backlog items;
● Ordering the items in the Product Backlog to best achieve goals and
missions;
● Optimizing the value of the work the Development Team performs;
● Ensuring that the Product Backlog is visible, transparent, and clear to
all, and shows what the Scrum Team will work on next; and,
● Ensuring the Development Team understands items in the Product
Backlog to the level needed.
Product Backlog
● Visible
● Ordered
● Groomed
● Categorized
Product Backlog
● Higher ordered Product Backlog items are usually clearer and more
detailed than lower ordered ones.
Monitoring Progress Toward Goals
● At any point in time, the total work remaining to reach a goal can be
summed.
● The Product Owner tracks this total work remaining at least every Sprint
Review.
● The Product Owner compares this amount with work remaining at
previous Sprint Reviews to assess progress toward completing projected
work by the desired time for the goal. This information is made
transparent to all stakeholders.
 Module 3

Scrum Artifacts 3.3 Sprint Backlog

Sprint Backlog
● The Sprint Backlog is the set of Product Backlog items selected for the
Sprint, plus a plan for delivering the product Increment and realizing the
Sprint Goal.
● The Sprint Backlog makes visible all the work that the Development Team
identifies as necessary to meet the Sprint Goal.
● The Development Team modifies the Sprint Backlog throughout the
Sprint
● Only the Development Team can change its Sprint Backlog during a
Sprint.
Monitoring Sprint Progress
● At any point in time in a Sprint, the total work remaining in the Sprint
Backlog can be summed.
● The Development Team tracks this total work remaining at least for every
Daily Scrum to project the likelihood of achieving the Sprint Goal.
● By tracking the remaining work throughout the Sprint, the Development
Team can manage its progress.
 Module 3

Scrum Artifacts 3.4 Backlog Item: User Story

Product Backlog Items
● User Stories
●
User Stories
● 2001, the 3C’s model is proposed by Ron Jeffries
to distinguish "social" user stories from
"documentary" requirements practices such as
User Story
use cases.
Card
● 3C’s are Card, Conversation and Confirmation.
● User stories are written on cards. The card does Conversation
not contain all the information that makes up Confirmation
the requirement. Instead, the card has just
enough text to identify the requirement, and to
remind everyone what the story is.
User Stories
● The requirement itself is communicated from customer to programmers
through conversation. The conversation is largely verbal, but can be
supplemented with documents. The best supplements are examples; the
best examples are executable, We call these examples confirmation.
● State intent not solution
● Just enough, Just in time
User Stories
● User perspective
● Short and simple
● Specific but not detailed (intent)
● Focus on discussion
● As a …. I want to …. So that ….
● Acceptance Criteria shows the happy path and other tests
INVEST
As a Buyer I want to register to the application
So that I can order product and ship it to my place.
● - Buyer should provide name, email and password.
● - Buyer should be able to reenter the password to confirm that both are
matching.
● - Password should have capital letter, number and special character and
at least 6 characters.
As a User (seller/Buyer) I want to be able to login
● User should enter his email and password correctly to login.
● in case user entered his email and password correctly, authenticate user
and forward him to last viewing page.
● in case user entered an incorrect email or password, system will show
validation message "You entered an incorrect email or password. Please
try again."
● In case user failed to login for the 3rd time, system should request user to
show Captcha.
● In case the logging user is seller, redirect user to seller dashboard.
SPIDR
Spike

Path

Interface

Data

Rule
Amount of details - Levels of Maturity
● Maturity 1 (Future Releases)

Reviewed & understood by PO, initial priority, high level acceptance criteria

● Maturty 2 (Next Release)

Review by the team, initial estimate, questions and assumptions, refined

priority

● Maurty 3 (Next Sprint)

Enough details to start work, no questions

Product Backlog Items
● User Stories
● Technical requirements (upgrades, the benefits and improvements)
● Code Spikes (questions to be answered)
● Technical Debt (current stage vs future state, risk to wait) quantified
● Bugs
Definition of Done
● Members must have a shared understanding of what it means for work to
be complete, to ensure transparency.
● The same definition guides the Development Team in knowing how many
Product Backlog items it can select during a Sprint Planning.
Example: Definition of Done
● Acceptance criterias of User Story are met
● Unit tests written and passing
● Code built successfully to staging environment
● Peer Code Review performed
● Tested devices/browsers listed in the project assumptions passed
● All major issues are fixed and closed
Non-Functional Requirements
● Think of non-functional requirements as "constraints" we put on the
system.
● “this system must perform with 100,000 concurrent users”
● Defined as User Story
○ As a Site Owner I want the system to perform with 100,000 concurrent users
● Add to DoD
○ Story needs to perform with 100,000 concurrent users
 Module 3 3.5 Sizing Sprint Backlog

Scrum Artifacts and Product Backlog in

different Units
Relative sizing
Relative sizing using story points
Relative Sizing - Planning Poker
Relative Sizing - Relative Sizing Grid
Relative Sizing - Crumb Scale
1. Size ordering
2. Points distribution
 Module 4

Scrum Sprint
 Module 4
4.1 Kanban for Scrum
Scrum Sprint Teams
 1997
1976 1995 Feature Driven 2003 2009
Waterfall Scrum Development Lean Scrum Guide

1991 1996 2001 2006 2009

Rapid Application Extreme Agile Manifesto Kanban DevOps
Development Programming

History Timeline
Kanban Board
Kanban
● Kanban is Japanese for “visual signal” or “card.”
● 1940s, Toyota developed Kanban.
● Kanban Principles
○ Visualize work - Kanban Board
○ Limit work in progress (WIP)
○ Focus on flow
○ Continuous Improvement
Kanban
● Scrum vs Kanban

Scrum Kanban
Pre-defined roles of Scrum master, Product owner No prescribed roles
and team member

Timeboxed sprints Continuous flow

At the end of each sprint if approved by the PO Continuous delivery or at the team's discretion

Velocity Cycle time

Teams should strive to not make changes to the sprint Change can happen at any time
forecast during the sprint.
 1997 2018
1976 1995 Feature Driven 2003 2009 Kanban for
Waterfall Scrum Development Lean Scrum Guide Scrum

1991 1996 2001 2006 2009

Rapid Application Extreme Agile Manifesto Kanban DevOps
Development Programming

History Timeline
Kanban in Scrum
Kanban (n): a strategy for optimizing the flow of stakeholder value through a
process that uses a visual, work-in-progress limited pull system.

Scrum mandates that the Sprint Backlog be transparent, but it provides

limited guidance on how to accomplish this
Kanban Guide for Scrum Teams
● The flow-based perspective of Kanban can enhance and complement the
Scrum framework and its implementation.
● This is where Kanban can help. By visualizing work in new way.
● Scrum team needs to define its workflow.
● The definition of "Workflow" includes a shared understanding within the
Scrum Team of how work is defined (work items), the start state of the
process, the active states for the work items, and the finished state of the
process.

Scrum.org: Kanban Guide for Scrum Team

Define Workflow
● Define start and finish points
● Define workflow states
● Set policies on how work flows through each state
● Define how WIP will be limited
Kanban Practices
● Visualization of the workflow
● Limiting WIP
● Active management of work items in progress
● Inspecting and adapting their definition of "Workflow"
The Basic Metrics of a Flow
● Work in Progress (WIP): The number of work items started but not
finished (according to the Scrum Team's definition of "Workflow").
● Cycle Time: The amount of elapsed time between when a work item
"starts" and when a work item "finishes."
● Work Item Age: The amount of elapsed time between when a work item
"started" and the current time.
● Throughput: The number of work items "finished" per unit of time. Note
the measurement of throughput is the exact count of work items.
 Module 4

Scrum Sprint 4.2 Information Radiators

Burn Down Chart
Sprint Health Gadget
Sprint Report
Sprint Retrospective
Release Burndown Chart
 Module 5

Scrum Events
 Module 5

Scrum Events 5.1 Sprint Planning

Sprint Planning
The work to be performed in the Sprint is planned at the Sprint Planning. This
plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month

Sprint. For shorter Sprints, the event is usually shorter.

Sprint Planning answers the following:

○ What can be delivered in the Increment resulting from the upcoming Sprint?
○ How will the work needed to deliver the Increment be achieved
What can be done this Sprint?
The Development Team works to forecast the functionality that will be
developed during the Sprint.

The Product Owner discusses the objective that the Sprint should achieve and
the Product Backlog items that, if completed in the Sprint, would achieve the
Sprint Goal.

The entire Scrum Team collaborates on understanding the work of the Sprint.

Only the Development Team can assess what it can accomplish over the
upcoming Sprint.
What can be done this Sprint?
During Sprint Planning the Scrum Team also crafts a Sprint Goal.

The Sprint Goal is an objective that will be met within the Sprint through the
implementation of the Product Backlog, and it provides guidance to the
Development Team on why it is building the Increment.
Velocity Driven Planning
● Determine the team’s historical average velocity.
● Select a number of product backlog items equal to that velocity.
● Identify the tasks involved in the selected user stories and see if it feels
like the right amount of work.
Sprint Velocity

1 12

2 10

3 12

4 15

5 11
Capacity Driven Planning
● Team members discuss the work involved, and identify the tasks that will
be necessary to deliver the product backlog item.
● Teams roughly estimate the hours to do each task.
● Stopping when they feel the sprint is full.
How will the chosen work get done?
The Development Team decides how it will build this functionality into a
"Done" product Increment during the Sprint.

However, enough work is planned during Sprint Planning for the Development
Team to forecast what it believes it can do in the upcoming Sprint

By the end of the Sprint Planning, the Development Team should be able to
explain to the Product Owner and Scrum Master how it intends to work as a
self-organizing team to accomplish the Sprint Goal and create the anticipated
Increment.
 Module 5

Scrum Events 5.2 Daily Scrum

Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team

Team is inspecting the work since the last Daily Scrum and forecasting
upcoming Sprint work.

The Development Team or team members often meet immediately after the
Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the
Sprint’s work.
Daily Scrum
The Scrum Master ensures that the Development Team has the meeting,

but the Development Team is responsible for conducting the Daily Scrum.

The Scrum Master teaches the Development Team to keep the Daily Scrum
within the 15-minute time-box.
 Module 5

Scrum Events 5.3 Sprint Review

Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and
adapt the Product Backlog if needed.

The purpose is to get feedback from stakeholders not to be appreciated nor to

prove that the team delivered value

The result of the Sprint Review is a revised Product Backlog that defines the
probable Product Backlog items for the next Sprint.
 Module 5

Scrum Events 5.4 Sprint Retrospective

Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself
and create a plan for improvements to be enacted during the next Sprint.

The purpose of the Sprint Retrospective is to:

○ Inspect how the last Sprint went with regards to people, relationships, process, and tools;
○ Identify and order the major items that went well and potential improvements; and,
○ Create a plan for implementing improvements to the way the Scrum Team does its work.
 Module 6

Scrum in Action
Project: Souq
● Sellers add items for selling
● Users browse marketplace, and buy items
● Buyers review items
 Module 6

Scrum in Action 6.1 Building Backlog

User Stories Mapping
It is a technique introduced by Jeff Patton, It’s a way to replace traditional flat
backlog. One of its objective is to collect requirement collaboratively by
enabling all participants from creating backlog on a wall.

Story map structure is Activities > Tasks > Stories, and it may look like the
following board.

Activities should show from left to right a complete user journey, Stories
should be ordered top-down by priority. each horizontal swim lane shows a
release.
User Stories Mapping
Exercise: Building a Backlog
 Module 6

Scrum in Action 6.2 Release Planning

Release Planning Goals
1. Define the scope
2. Estimate how long will it take.
Exercise: Stories Sizing
 Module 6

Scrum in Action 6.3 Sprint Planning

Exercise: Sprint Planning
 Module 7

Flaccid Scrum
 Module 6

Flaccid Scrum 7.1 XP Practices

Extreme Programming (XP)
● Pair Programming
● Test Driven Development
● Refactoring
● Simple Design
● Continuous Integration
Continuous Delivery
What is Continuous Delivery?
It's the ability to get changes of all types into production, safely and quickly in
a sustainable way.

Continuous delivery is ensuring that your solution is always production-ready,

not just tested, so that you can deploy your code to production with the push
of a button.
Water-Scrum-Fall
Drawbacks of current Agile
Implementation, Agile adoption didn't
get through the whole organization.

Continuous delivery concern is the last

part
Amazon and Continuous Delivery
What is the added value?
Decreasing lead time for changes (from commit to deploy) to achieve

● Frequent releases
● Get critical fixes or restore service quickly
● Validate if the feature is valuable
Why Continuous Delivery?
● Make releases painless
● Reduce time to market
● Increase software quality and stability
● Reduce cost of ongoing software development
● Increase customer and team satisfaction
Continuous Delivery Principles
● Build Quality in
● Work in small batches
● Computers Perform Repetitive Tasks, People Solve Problems
● Everyone is Responsible
Continuous Delivery Foundations
Continuous delivery is following the first principle in Agile Manifesto

Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
Configuration Management
Automate build, deploy and infrastructure provisioning

Version control should contain source code, deployment scripts, system and
infrastructure configuration
Configuration Management Goals
Reproducibility

○ We should be able to provision any environment in a fully automated fashion, and know
that any new environment reproduced from the same configuration is identical.

Traceability

○ We should be able to pick any environment and be able to determine quickly and
precisely the versions of every dependency used to create it.
○ We want to to be able to compare previous versions of an environment and see what has
changed between them.
Continuous Integration
CI follows the XP principle that

"if something is painful, we should do it more often, and bring the pain
forward".

So what is painful?

Long-lived branches often require code freezes, or even integration and

stabilization phases, as they work to integrate these branches prior to a
release
it’s entirely possible to do CI without using a CI
tool, and conversely, just because you’re using a
CI tool does not mean you are doing CI!
Continuous Integration Main Steps
● Developers integrate all their work into mainline on a regular basis (at
least daily).
● A set of automated tests is run both before and after the merge to
validate that no regressions are introduced.
● If these automated tests fail, the team stops what they are doing and
someone fixes the problem immediately
Continuous Testing
To building quality into software, testing is not something you do after the
development complete, it’s something you do all the time

Manual tests drawback

● Manual regression testing takes along time

● It's not reliable, since people are notoriously poor at performing
repetitive tasks
1. Agile Testing Quadrants
Operational Quality Attributes
● Performance ● Automated Tools
● Reliability ● Automated Scripts
● Load/stress ● Exploratory Testing
● Security
● Browser Compatibility
● Usability
Development Quality Attributes
● Portability ● Peer reviews
● Testability ● Code Reviews
● Maintainability ● Static analysis
● Modifiability
● Reusability
● Flexibility
Why Testing in Agile?

Build the right product

And

Get faster feedback

 Business Facing

Support development Critique the Product

to build the right thing
(Find Defects)
(Prevent Defects)

Technology Facing

Agile Testing Quadrants

 Business Facing

UAT

Exploratory Testing
Support development Critique the Product
to build the right thing
(Find Defects)
(Prevent Defects)

Technology Facing

Agile Testing Quadrants

Exploratory Testing
Exploratory testing is all about discovery, investigation, and learning. It
emphasizes personal freedom and responsibility of the individual tester. It is
defined as a type of testing where Test cases are not created in advance but
testers check system on the fly. They may note down ideas about what to test
before test execution. The focus of exploratory testing is more on testing as a
"thinking" activity.
Early Testing
● Conversation for better understanding
○ 3 Amigos
○ Ask questions
○ Personas
○ Story Map
 Business Facing

Story Tests UAT

(Written first)

Prototypes Exploratory Testing

Support development Critique the Product
to build the right thing
(Find Defects)
(Prevent Defects)

Technology Facing

Agile Testing Quadrants

Executable Testing

The requirement itself is communicated from customer to programmers

through conversation. The conversation is largely verbal, but can be
supplemented with documents. The best supplements are examples; the best
examples are executable, We call these examples confirmation.
 Business Facing

Story Tests UAT

(Written first)

Prototypes Exploratory Testing

Support development Critique the Product
to build the right thing
(Find Defects)
(Prevent Defects)
Unit Test

Component Test

Technology Facing

Agile Testing Quadrants

 Business Facing

Story Tests UAT

(Written first)

Prototypes Exploratory Testing

Support development Critique the Product
to build the right thing
(Find Defects)
(Prevent Defects)
Unit Test

Component Test

Technology Facing

Agile Testing Quadrants

Executable Testing (business facing)
● Acceptance Test Driven Development (ATDD)
○ is a development methodology based on communication between the business
customers, the developers, and the testers. And it highlights writing acceptance tests
before developers begin coding.
● Behavior-Driven Development (BDD)
○ is an Agile software development process that encourages collaboration among
developers, QA and non-technical or business participants in a software project.[1][2][3] It
encourages teams to use conversation and concrete examples to formalize a shared
understanding of how the application should behave
● Specification by example (SBE)
○ collaborative approach to defining requirements and business-oriented functional tests
for software products based on capturing and illustrating requirements using realistic
examples instead of abstract statements.
 Business Facing

Story Tests UAT

(Written first)

Prototypes Exploratory Testing

Support development Critique the Product
e2e
to build the right thing
(Find Defects)
(Prevent Defects)
Unit Test

Component Test

Technology Facing

Agile Testing Quadrants

Testing Non Functional Requirement

Separate stories

or

Story constraints (Acceptance criteria or DoD)

 Business Facing

Story Tests UAT

(Written first)

Prototypes Exploratory Testing

Support development Critique the Product
Simulations
to build the right thing
(Find Defects)
(Prevent Defects)
Unit Test Performance Test

Component Test Security Test

Technology Facing

Agile Testing Quadrants

Agile Testing Quadrants
Regression Testing
Regression testing is re-running functional and non-functional tests to ensure
that previously developed and tested software still performs after a change.
2. Types of Automation Testing
Automation Testing
● Repeatable, Reliable, Regression testing that helps refactoring
○ Reduce cycle time
○ Minimal Time Wasted
○ Less Risk. You KNOW your code is good with every build.
● Finding Issues Earlier in the SDLC.
● Improved Code Quality. You can test everything on every build.
● Executable living documentation
Unit Testing
● Unit Tests test small piece of the product in isolation. Unit tests are fast,
reliable and isolate failure.
Integration Testing
● Integration tests test a small group of units as a whole, verifying that
they coherently work together.
End-to-end Testing
● End-To-End tests test the system as a whole through the GUI.
3. The Testing Pyramid
Inverted pyramid/ice cream cone.
● The team relies primarily on end-to-end tests, using few integration tests
and even fewer unit tests
Strategy built around end-to-end test
● Good ideas often fail in practice, and in the world of testing, one pervasive
good idea that often fails in practice is a testing strategy built around
end-to-end tests.
Drawbacks of end-to-end test
● Finding the root cause for a failing end-to-end test is painful and can take
a long time.
● End-to-end tests were flaky at times.
● Developers had to wait until the following day to know if a fix worked or
not.
● GUI tests can frequently break, Since the GUI may change significantly.
Hourglass
● The team starts with a lot of unit tests, then uses end-to-end tests where
integration tests should be used.
Testing Pyramid
Testing Pyramid
● To find the right balance between all three test types, the best visual aid
to use is the testing pyramid.
● Google often suggests a 70/20/10 split:
○ 70% unit tests,
○ 20% integration tests, and
○ 10% end-to-end tests.
4. Testing Strategy
The ideal testing strategy
The ideal testing strategy should be

● Fast
● Reliable
● Isolate failures
 High benefit - Low cost High benefit - High cost

High Coverage Sufficient Coverage

Benefit
Low benefit - Low cost Low benefit - High cost

Limit Coverage Just Happy Path

Cost of Automation

What to automate?!
Automation Strategy - Regression Packs
Smoke Regression Pack

● Should last no longer than 5 minutes

● Runs on every deploy
● Can be a mixture of API and/or GUI tests
Automation Strategy - Regression Packs
Functional Regression Packs

● Should last no longer than 15 to 30 minutes

● Executed multiple times a day
● Majority of functional tests at API layer
Automation Strategy - Regression Packs
End-to-End Regression Pack

● Run once a day or night

● mainly executed through the GUI
● These tests are “light-weight” which just check the transitions from one
state to another, and a handful of the most important scenarios or user
journeys.
What about the tester role?
● QA shouldn’t be working on manual regression test, instead he should
focus in exploratory testing and maintaining automation testing
● QA is not a failed developer, he maintain test code as developer maintain
production code
● Testing code is as important as product code
How Atlassian does QA
Thank You!