AGILE FUNDAMENTALS

AGILE ROLES
 TRADITIONAL APPROACHES
Waterfall mind-set – usually, everybody is looking for his part in the project,
concentrating only on inputs and outputs of his layer, sometimes forgetting the end
goal or the context he is operating in.
Other traditional approaches: spiral development, V-model, unified process (RUP)

End
Goal

Requirements Analysts
- output and input Project
Architecture Managers
Architects
& Design
associated roles
Development Programmers

Software
Testers
Testing
Release &
Supporters
Support

3
 AGILE APPROACH
Agile mind-set – team members, with skills across all layers, work collaboratively, doing
their best in any circumstance, adapting in order to achieve the common end goal.

End
Analysis Analysis Analysis Analysis Goal
& Planning & Planning & Planning & Planning

Architecture Architecture Architecture Architecture

& Design & Design & Design & Design

Sprint n+1
Sprint 1

Sprint 3
Sprint 2

Sprint n
Plan

Coding Coding Coding Coding

Testing Testing Testing Testing

Release Release Release Release

intern intern intern intern

extern extern extern extern

4
 AGILE TEAM
PRIMARY FOCUS:
As a cohesive unit of professionals focused on
one objective at a time, the Product Goal.
Deliver products iteratively and incrementally
Maximise opportunities for feedback from
stakeholders or/and end-users
Ensure a potentially useful version of working
product is always available
MEMBERS:
Product Owner points the team at the right goal
Engineers turn requirements into usable
functionality with every Sprint
Scrum Master helps the team get to the target
as efficiently as possible
5
 CHARACTERISTICS OF AN AGILE TEAM
CROSS-FUNCTIONAL
members with skills and competencies in each of the
disciplines needed to create value each Sprint

SELF-MANAGED
ability to decide inside the team how best to
accomplish work, meaning they internally decide
who does what, when, and how to achieve the
Sprint Goal(s) and Product Goal

EMPOWERED
autonomy to own its work, authorised to make
decisions and to work independently

ACCOUNTABLE
for delivering a valuable increment at the end of the
sprint
6
 MEMBERS OF THE AGILE TEAM

ENGINEERS
Product Owner BUILD THE THING RIGHT

BUILD THE RIGHT THING turn requirements into usable functionality

with every Sprint
points the team at the right goal

SCRUM
MASTER
BUILD THE EFFECTIVENESS OF THE TEAM
helps the team get to the target as efficiently as possible

7
 PRODUCT OWNER
PRIMARY FOCUS
Envisioning the product - Maximizing the value of the product
Single voice to make a product decision
Maximizing the work of the Engineers

RESPONSIBILITIES:

Manages Product Backlog focusing on WHAT rather than HOW

Accountable for managing the Product Backlog even if he choses

to delegate this activity

Developing and explicitly communicating the Product Goal and

Product Vision

Represents the needs of all stakeholders: End Users, Senior

Management, Operational Staff, Domain Experts, Architects,
Auditors
http://agiletips.blogspot.com/2012_04_01_archive.html
Ralph Jocham
8
 ATTRIBUTES OF A GOOD PRODUCT OWNER
AVAILABLE
By far the most frequent complaint about their POs is that they are unavailable when needed.

BUSINESS-SAVVY
The PO must have a deep understanding of the business, market conditions, customers, and users.

COMMUNICATIVE
POs must be good communicators and must be able to work well with a diverse set of stakeholders.

DECISIVE
When team members go to the PO with an issue, they want a resolution.

EMPOWERED
PO must be someone empowered with the authority to make decisions and one who is held accountable for those
decisions.

Source: Succeeding with Agile: Software Development Using Scrum by Mike Cohn, 2009

9
 OVERCOMING COMMON PROBLEMS
THE PO DELEGATING DECISION MAKING BUT THEN OVERRULES THE DECISION MAKER
Product Owners should be sure they are really willing to delegate without later second-guessing.

THE PO PUSHING THE TEAM TOO HARD

Together with Scrum Master they need to set longer-term goals while ensuring teams have adequate degrees of
freedom in how these goals are achieved.

THE PO WANTING TO CUT QUALITY

No one except the Chief Executive has the authority to sacrifice quality in exchange for achieving a short-term goal
such as making a release date.

Source: Succeeding with Agile: Software Development Using Scrum by Mike Cohn, 2009

10
 ENGINEERS
PRIMARY FOCUS
Delivering a potentially shippable increment of “Done” functionality
each Sprint

RESPONSIBILITIES
Create the Sprint Backlog and commit on selected number of features
to be built in a Sprint
Adapting their plan each day toward the Sprint Goal
Focuses on technical excellence by adhering to the Definition of Done
Presents each Sprint achievements in a form of a review
Continuously looks to improve their efficiency and effectiveness
Contributes and helps the PO with Backlog Refinement
Collaborate with stakeholders and holding each other accountable as
professionals

11
 ATTRIBUTES OF A GOOD ENGINEERS
SELF-MANAGED
autonomy to determine how and when to complete its work
CROSS-FUNCTIONAL
having all the skills necessary to create a Product Increment
NO TITLES OTHER THAN ENGINEER
“Unus pro-omnibus, omnes pro uno”

TYPICALLY, 8 OR FEWER PEOPLE

optimal communication

SITTING TOGETHER
maximizing value of collaboration
LONG TERM MEMBERS
being high performance team
AGILE ATTITUDE
applying 5 values of Scrum. Inspect and adapt

12
 SCRUM MASTER
PRIMARY FOCUS:
Leader who serves for the team and the larger organisation
Managing Scrum Processes

RESPONSIBILITIES:
Enacting Scrum values and practices

Ensures the team is fully functional and productive

Shield the team and removes impediments

Facilitates Scrum ceremonies

Enable close cooperation between stakeholders and the

team

13
 ATTRIBUTES OF A GOOD SCRUM MASTER
LEADER WHO SERVES
facilitate the growth of people and organisation
RESPONSIBLE
responsibility that comes without power
HUMBLE
“look what I helped accomplish” rather than “look what I accomplished”
COLLABORATIVE
establishing collaboration as the team norm
COMMITTED
remaining in the role for the full duration of the project
INFLUENTIAL
convincing others, both on the team and outside it
KNOWLEDGEABLE
knowing enough about programming and marketing to be effective in leading the team

14

SCRUM MASTER SERVING THE PO
Helping find techniques for effective Product
Goal definition and Product Backlog
management
Helping the 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
SCRUM MASTER SERVING THE
SCRUM MASTER SERVING THE TEAM
ORGANISATION
Coaching the team members in self-management Leading, training and coaching the organisation
and cross-functionality in its Scrum adoption
Helping the team focus on creating high-value Planning and advising Scrum implementations
Increments that meet the Definition of Done within the organisation
Causing the removal of impediments to the Helping employees and stakeholders
team’s progress understand and enact an empirical approach
for complex work
Ensuring that all agile events take place and are
positive, productive, and kept within the timebox Removing barriers between stakeholders and
team(s)
15
Agile fundamentals
AGILE CEREMONIES
TEAM & PRODUCT INTERACTION MODEL - AGILE
CEREMONIES
SPRINT PLANNING @INTERACTION MODEL
 SPRINT PLANNING - PURPOSE

A collaborative effort so that the Agile Team members:

Initiates the Sprint by laying out the work to be

performed for the Sprint

Provide transparency and reach the same understanding

over the top items ordered in the product backlog

Define the vision for the sprint - by crafting a common

goal that would be respected over sprint's duration
Establish and unify Engineers’ plan work that will be
performed in the sprint to meet the Sprint Goal
▪ Time-boxed: ~4h per 2 weeks sprint
▪ (Usually shorter/longer for shorter/longer
sprints)

Define what will be delivered and how will the work be done
 SPRINT PLANNING: TOPIC ONE
WHY IS THIS SPRINT VALUABLE?
PRACTICES
Product Owner – proposes how the product could
increase its value and utility in the current Sprint.

Scrum Master - Facilitates the event

Engineers – work with the PO to define a realistic

and achievable Sprint Goal that communicates why
the Sprint is valuable to stakeholders.

ATTENDANTS
Product Owner Scrum Master
Engineers Subject Matter Experts (optional)
Other teams’ members are invited as needed
 SPRINT GOAL - HOW
Should be SMART ( Specific, Measurable, Attainable, Relevant, and Time-bound )

Addresses the most important challenges

Emphasis usually starts to shift from resolving uncertainty (goals during early phases of the product
development) to completing features so that they can be released (see picture bellow)

Sprint Goal: Sprint Goal: Product

Learning Feature-completion Goal

Examples:
“Our sprint goal is to implement buy now pay later alternative payment method.”
“Our sprint goal is sending additional payment fields (code, receiver, owner) into API
service, part of new gateway payments synchronization.”
Helps the team getting closer to the vision or release goal`
 SPRINT PLANNING: TOPIC TWO
WHAT CAN BE DONE IN THIS SPRINT?
OUTCOME
What can be delivered in the Increment resulting
from the upcoming Sprint?
Forecast of the items delivered by Engineers
Sprint Goal as crafted by the Agile Team
COMMON PITFALLS
Lack of PO involvement
PO not prepared - Backlog not prioritised
Product Backlog items (epics, stories, bugs) not
ready
No time is reserved for support activities
Ignoring Technical Debt
Unrealistic, vague or no Sprint Goal
Consider the team capacity for current sprint.
Don’t load your sprints at 100% to leave room to
react to unexpected changes.
If the event is organized online check TEAM Distributed work guidelines
PRACTICES
Product Owner – discusses the objective for the
Sprint, initial Sprint Goal, and the Product Backlog
items
Scrum Master - Facilitates the event
Engineers – work with the PO to select the items
for the current sprint and by refining increases the
understanding and confidence
Input for this event: Product Backlog; DOR; DOD;
last product Increment; Backlog Refinement output,
items from Sprint Retrospective, past performance
of the team (Velocity); capacity of the Engineers for
the Sprint
ATTENDANTS
Product Owner Scrum Master Engineers
Subject Matter Experts (optional)
Other teams’ members are invited as needed
 SPRINT PLANNING: TOPIC THREE
HOW WILL THE CHOSEN WORK GET DONE?
OUTCOME
How the work needed to be delivered in the
Increment will be achieved?
Sprint Backlog:
Product Backlog items selected
Plan for delivering them as a self managing team
Dependencies internals/externals confirmed and
handled
COMMON PITFALLS
First Item takes the longest to discuss
Going too deep into technical discussions
Dependencies are not considered
Not enough time to breakdown and estimate the
items
If the event is organised online check TEAM Distributed work guidelines
PRACTICES
Engineers plan the work necessary to create an
Increment that meets the Definition of Done
Task breakdown – units of one day or less
Enough work planned to forecast it can be done
in the Sprint
May renegotiate the scope with the PO
Scrum Master - Facilitates the event
Product Owner clarifies the selected Product
Backlog items and makes tradeoffs
ATTENDANTS
Scrum Master Product Owner (optional)
Engineers Subject Matter Experts (optional)
Other teams’ members are invited as needed
BACKLOG REFINEMENT @INTERACTION MODEL
 BACKLOG REFINEMENT - PURPOSE
Backlog refinement 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.
To help the Product Owner to manage variability of “work
items” that make the Product Backlog
To help the Product Owner get the top of the product backlog
ready for the next Sprint Planning sessions and to Look Ahead in
a high-level way to other 2-3 Sprints
To help Product Owner have a better estimation of the work to
be done. Help him have a Release Plan Usually consumes around 10% from the capacity
To have enough clarity for the next pieces of work, identify of the Engineers. Could be more or less, if it
serves to keep the Product Backlog in a
early the dependencies and issues, so that we can plan the next transparent state and establishes an initial shared
sprint and eliminate waste understanding of acceptance criteria for PBIs

The goal is to create product backlog items that meet Definition

of Ready and to create stories that are Independent, Negotiable,
Valuable, Estimable, Small, Testable.
DAILY STAND-UP @INTERACTION MODEL
 DAILY STAND-UP - PURPOSE
A daily opportunity for the team to synchronise and collaborate on achieving the
Sprint Goal

To obtain an understanding of the work that has been done and

the remained work
To inspect the progress towards the Sprint Goal and adapt the
Sprint Backlog as necessary, adjusting the plan.
Identify impediments to sprint progress for removal
Identify possible impediments that could impact the
dependent teams and Sprint Goals
Improve communication
Eliminate other meetings Time-boxed: 15 minutes
Highlight and promote quick decentralised decision-making
Improve Engineers’ level of knowledge
 DAILY STAND-UP - HOW
ATTENDANTS
Engineers
Scrum Master (makes sure event takes place)
Product Owner (optional, but recommended)
OUTCOME
Alignment and revised plan for the day/sprint
Revised impediments list and follow-up actions
agreed
Update of the ALM Tool (e.g., Jira) and Sprint Board
COMMON PITFALLS
Daily Stand-up transforms in a solve all issues meeting
Daily Stand-up transforms in a report meeting when
someone collects information about who and what is
behind schedule
Obstacles raised in the stand-up are not removed or
otherwise addressed in a timely fashion
External people derails the Daily Stand-up
Engineers are focused more on their individual work
rather than collaboration on the Sprint Goal
PRACTICES
Held at the same place, same hour; usually in the
morning
Everyone can attend, it is for Engineers to adjust the
plan to meet the Sprint Goal, the PO can help with
clarifications
Sometimes another client-facing meeting is needed to
update the PO with the progress - nearshore agile
optimisation technique
Pass the Token - each member of the Engineers
shares the update of their work by answering 3
questions:
What did I do yesterday that helped Engineers meet
the Sprint Goal?
What will I do today to advance the Sprint Goal?
Do I see any impediments that prevent me or anyone
in the Engineers from meeting the Sprint Goal?
Walk the Board – item approach; team members
provide updates on the items from the board
SPRINT REVIEW @INTERACTION MODEL
 SPRINT REVIEW - PURPOSE
Agile Team collaborates with Stakeholders to inspect the outcome of the Sprint and determine
future adjustments of Product Backlog to ensure progress toward the Product Goal

See how the product was improved by the addition of

new features and functionalities
A meeting when all participants collaborate and provide
feedback to improve the Product Backlog and the
Product
Confirm the priorities for the next Sprint to optimise
product value delivery towards Product Goal
A meeting when we learn from what has been Time-boxed: 2h per 2 weeks sprint
done/experienced during the sprint
(Usually shorter/longer for shorter/longer sprints)
 SPRINT REVIEW - HOW
ATTENDANTS
Scrum Master (Facilitator), Product Owner, End Users,
Customers, BA’s, Engineers, Project Managers, Project
Sponsors, Stakeholders
OUTCOME
User Stories that have been accepted (Done) by the
Product Owner or business users
Feedback regarding the value added by the new
functionalities
Next functionality that will add the most value to the
products identified
COMMON PITFALLS
The event could become a demo meeting and not
generate any feedback
Loosing the ideal moment of adding additional value
Story review becomes a full functional testing review
Show only a presentation instead of working software
Show not integrated code (e.g., from local environment)
If the event is organized online check TEAM Distributed work guidelines
PRACTICES
Takes place in the last day of the Sprint
Product Owner explains what has been done by the
Engineers and what obstacles they encountered
Engineers presents what was accomplished during
the Sprint, the working product
A User Story is considered done if the Product
Owner and business users confirm that acceptance
criteria are met
Stakeholders, Product Owner, Engineers look through
the product backlog and identify items that could be
implemented by the team next sprint
Feedback collected during the meeting is logged to be
validated & prioritised by the Product Owner
The Agile Team discuss the risks identified for the next
sprints
Agile Team celebrates the Success!
SPRINT RETROSPECTIVE @INTERACTION MODEL
 SPRINT RETROSPECTIVE - PURPOSE
Helps teams – even great ones – to keep improving
Enable whole-team learning, act as a catalyst for change
and generate action
Focus on inspecting and adapting the most valuable
asset in a software organization, the team itself
Opportunity to change behavior and team culture
Safe place for team members to share constructively
feedback

Internal retrospective (an optimization for near-shore

teams) benefits:
Time-boxed: ~1.5h per 2 weeks sprint
Face-To-Face contact
A better communication - using some visual materials (Usually shorter/longer for shorter/longer
Interpreting the body languages sprints)
Going faster through Tuckman's stages of group
development

If the event is organized online check TEAM Distributed work guidelines

 SPRINT RETROSPECTIVE - HOW
OUTCOME PRACTICES
Retrospective Notes and Actions, a plan for
The last activity done in a Sprint
improvements to be enacted during the next
Sprint Should start with reviewing actions from the
It’s a time for the team to learn: previous retrospective
▪ How to improve Pluses and deltas, relevant metrics
▪ How to work more efficiently Start-doing; Stop-doing; Continue-doing
▪ How to deliver at a higher Velocity and with
superior quality ATTENDANTS
▪ Update the Definition of Done, Definition of Engineers
Ready Scrum Master
Product Owner
COMMON PITFALLS
Just crying retro
Happy playing games retro
Post-mortem retro
Like Groundhog Day retro
 WAYS TO CONDUCT A SPRINT RETROSPECTIVE

4Ls Technique Start-doing; Stop-doing; Continue-doing Pluses and Deltas

"Life is growth.
If we stop growing, technically and spiritually, we are as good as dead“
Morihei Ueshiba
 TOOLS

6 Thinking Hats 5 WHY’s Root Cause Analysis

 AGILE ROLES ACCOUNTABILITIES 30 min

Map Accountabilities with appropriate Agile

Role or group. Be ready to explain WHY.

Time Frame
10 min : Read and move sticky notes in the
areas according with each role and
accountability
15 min : Discuss why the accountabilities are
assigned to a particular role
15 min : Exercise Debrief

40
 SCRUM CEREMONIES PUZZLE 30 min

Map the descriptions with appropriate

Scrum Ceremony. Be ready to explain
WHY.

Time Frame
10 min : Read and move sticky notes
in the areas according to each
ceremony
15 min : Discuss the main
characteristics of each ceremony
5 min : Exercise Debrief
 ATTRIBUTIONS
This material draws inspiration from a massive community of Agile enthusiasts, our own experience and that of many clients and
companies we've engaged with through the years.
People that have inspired us through many trainings, workshops , articles and webinars: Mike Cohn, Jeff Sutherland, Henrik
Kniberg, Ken Schwaber, Roman Pichler, Anna Forss, Serge Beaumont, Mike Beedle and many others we’ve not intentionally forgot
Sites and whitepapers with excellent knowledge: www.scrumguides.org ; www.agilealliance.org; www.mountaingoatsoftware.com;
www.scrumalliance.org; www.controlchaos.com; www.implementingscrum.com; www.jeffsutherland.org; www.agileforall.com;
www.infoq.com; www.rapidscrum.com; www.slideshare.net; www.agile42.com; scrum.jeffsutherland.com; www.agilemanifesto.org;
www.scrum.org; www.wikipedia.org; www.projectmanagement.com; www.romanpichler.com; www.cathycarleton.com;
Books that have added invaluable knowledge: Ken Schwaber - Agile 43 Project Management with Scrum; Mike Cohn - Agile
Estimating and Planning; Mike Cohn – Introduction to user stories; Roman Pichler - Agile product management with Scrum; Anna
Forss - Confessions of a serial product owner; Ken Schwaber - The Enterprise and Scrum; Mike Cohn - User Stories Applied; Carl
Larson and Frank LaFasto - Teamwork; Serge Beaumont - Practical Tools for the Product Owner: Focus, Value, Flow; Jim Highsmith
- Agile Project Management; Jeff Patton - Story Maps; Mike Cohn - Succeeding with Agile; 37 Signals: Getting Real; Jeff Sutherland
- The Power of Scrum ; Tobias Mayer - Scrum Roles; Donald Reinertsen - The Principles of Product Development Flow; C.
Jakobsen and J. Sutherland - Scrum and CMMI – Going from Good to Great; Donald Reinertsen - Managing The Design Factory;
Scrum Sense – What every product owner should know; Ken Schwaber, Beedle Mike - Agile Software Development with Scrum;
RSA Animate - Drive: The surprising truth about what motivates us video: http://www.youtube.com/watch?v=u6XAPnuFjJc

43
43