Agile Project Management

(PMP Preparation Training Program)

Dr. Duminda Weeraratne MBA (Sri J), PMP,PMI-RMP,PMI-ACP,PMI-PBA,CSM

1
 Agile Project Management

Agility
“Ability to quickly adjust and respond to
changing business needs.”

“Agility is more attitude than process,

more environment than methodology.”

2
What is Agility?
• A-gil-i-ty (ə-'ji-lə-tē) Property consisting of quickness,
lightness, and ease of movement; To be very nimble
• The ability to create and respond to change in order to
profit in a turbulent global business environment
• The ability to quickly reprioritize use of resources when
requirements, technology, and knowledge shift
• A very fast response to sudden market changes and
emerging threats by intensive customer interaction
• Use of evolutionary, incremental, and iterative delivery
to converge on an optimal customer solution
• Maximizing BUSINESS VALUE with right sized, just-
enough, and just-in-time processes and documentation
3
Copyright @ Project Management Solutions 4
 Challenges

• Today the business environment is increasingly;

– Volatile
– Uncertain
– Complex
– Ambiguous

Copyright @ Project Management Solutions 5

IT is eating the world
Source: Forbes
Source: Scrum.org
 Who Should Use Agile ?
Drivers for Adopting APM
• Volatile, uncertain, complex and ambiguous business
environment
• Continuous Innovation
• Product changes fast
• Reduced time of response
• Need to reduce cost
• Changing technology
• High level of risk
• Guaranteed Results

10
UNCERTAINTY, RISK, AND LIFE CYCLE
SELECTION

Degree of change in requirements

Agile

Degree of change in technology

Ralph Stacey's Agreement & Certainty Matrix

(modified from: Brenda Zimmerman)

11
 The Basic Approach of Agile

• Make a list of what you need to do

• Prioritize the list according to the value and size

• Work from the top of the list until you run out of time
• Repeat the process

15
 Estimating Relative Size

• Story points
– Relative size of a story(relative measurement
among User Stories)

– If a cat is assigned one story point size, a goat

would be 5 times bigger in size

– Story points are estimated based on how hard or

how much effort is required to complete

16
Assign animal points to following animals

• Rabbit
• Cat
• Cow
• Dog
• Giraffe
• Goat
• Bear

17
 Assign animal points to following
animals
Animal Story Point
Rabbit
Cat
Cow
Dog
Goat
bear
giraffe
18
 Traditional Lifecycle
(a) Waterfall Lifecycle
$$ $

Plan Analysis Design Code Test Deploy

3 -24 months

(b) Iterative and Incremental Lifecycle

$ $ $
Analysis

Analysis

Analysis
Deploy

Deploy

Deploy
Design

Design

Design
Code

Code

Code
Plan

Plan

Plan
Test

Test

Test
1-3 months 1-3 months 1-3 months

$= Potential release
19
Source : The Art of Agile Development- Shore & Warden
Sometimes, you want to build a road iteratively: a dirt track will suffice to begin with,
moving to gravel, then upgrading to tarmac as time allows.

20
Other times, the road from A to B may be most important. So you build incrementally:
the road from A to B first, then the road to C, then finally to D.

21
 The Cost of Traditional BDUF
“Successful” Projects Still Have Significant Waste

Source: Jim Johnson of the Standish Group, Keynote Speech XP 2002

22
Traditional Value Curves

23
Agile Value Curves

24
 Paradigm Shift to Agile
Most of your traditional PM skills can be converted to Agile
Traditional Project Management Agile Project Management
Comprehensive documentation, Customer collaboration and value
ceremonies and compliance
Structured change control process Flexible and adaptive
Predictive planning Adaptive planning (progressively
elaborated)
Scope is fixed Incremental delivery based on
customer priority
Authoritative top-down control Self-organized empowered teams

Process-centric heavyweight methods Light-weight, simple and flexible

process
Non-value added controls Value-focused metrics

25
Agile Values, Principles and Practices
 Agile
practices

Agile
principles

Agile
values

The need
to respond
to constant
change

The relationship between

agile values, principles, and practices
27
Source: Becoming Agile ... in an imperfect
world-Ggreg Smith Ahmed Sidky
 Need to Change

• Market is changing fast

• Organizations too need to change fast before
competitors
• Focus on what is important

If you are going for an expedition in Horton

plains, you pack light

28
 Agile Manifesto
• In year 2001, 17 software developer wanted to find a
change driven, real time feed back, more light weight
method
• Necessity to have a method where requirements and
solutions evolve through collaboration and
self-organizing, cross-functional teams were identified
• 17 software developers agreed on a set of values that
defined a culture and 12 principles that projects should
follow.
• Agile Manifesto forms the basis for most methods
currently in use today

29
Four Values of Agile Manifesto -Each project could develop their
best practices around these very simple considerations.
“We are uncovering better ways of developing products by doing it and helping
others do it. Through this work we have come to value ;

Individuals and Interactions Processes and Tools

Over

Working Products Comprehensive

Over
Documentation

Customer Collaboration Contract Negotiations

Over

Responding to Change Following a Plan

Over

That is while there is value in the item on the right, we value items on the left more”
31
Source : Agile Manifesto
 Individuals and Interactions over
Processes and Tools
• Work is done by people, process may help
• People initiate projects, projects are delivered to people,
requirements are negotiated by people, problems and issues
are solved by people, acceptance criteria is defined by people
• Without interactions and collaboration, the processes and
tools don’t work
• Peoples are the most important factor
• Team should focus on individuals and interactions
• Promote self management and shared ownership
• Train people and promote good interactions
32
 Working Products Over Comprehensive
Documentation
• Too many methodologies are focused on up-front planning,
setting hard due dates and baselines, and continual updates as
things change
• Focus on delivering working software

• Progress is tracked based on working software

• Documentation is necessary but documentation without good

software is valueless

• Do not let documentation to distract your attention from

creating good software.
33
 Customer Collaboration Over Contract
• Negotiations
Business requirements are changing
• Software is intangible, invisible, and difficult to reference
• Putting everything to be done on the contract at the beginning is
not practical
• Collaboration with the customer and working toward the right
solution is more important than locking down a contract that
doesn’t meet the needs of the customer in the end
• lack of flexibility in procurement counteracts flexibility of
requirements and customer needs
• Be flexible and accommodate change, join hands with customer to
achieve a shared goal
• Build trust and use flexible contracts 34
Responding to Change Over
Following a Plan

• Requirements and technology is changing

• Concrete up front plans are not feasible
• Change happens—it’s expected and embraced
• Start with initial high level plans developed with little
knowledge about the product and change them when
you learn more during the project.
• Get everyone involved in planning

35
 12 Principles
Agile Manifesto Advocates that;
Our highest priority is to
Simplicity--the art of
satisfy the customer thr Working software is the
maximizing the amount of
ough early and continuous primary measure of
work not done--is
delivery of valuable progress.
essential.
software

The most efficient and

The best architectures, Deliver working software
effective method of
requirements, and designs frequently, from a couple
conveying information to
emerge from of weeks to a couple of
and within a development
self-organizing teams. months, with a preference
team is face-to-face
to the shorter timescale
conversation.

Welcome changing Agile processes promote

requirements, even late in Continuous attention to sustainable development.
development. Agile technical excellence and The sponsors, developers,
processes harness change good design enhances and users should be able to
for the customer's agility. maintain a constant pace
competitive advantage indefinitely.

Build projects around At regular intervals, the

Business people and motivated individuals. Give team reflects on how to
developers must work them the environment and become more effective,
together daily throughout support they need, and then tunes and adjusts its
the project trust them to get the job behavior accordingly.
36
done. Source: Agile Manifesto
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software

• Primary focus;

– Satisfy customer early(not the internal

stakeholders eg; PMO etc)
– Early and continuous delivery (learn fast and
minimize risk)

– Valuable software( not documents or plans)

37
Welcome changing requirements
even late in development
Agile processes harness change for the
customer's competitive advantage

• Customer’s market is dynamic

• Change requirements for competitive advantage

• No integrated change control system
• Light weight, high visibility approach for prioritizing
changes

38
Deliver working software frequently
from a couple of weeks to a couple of months,
with a preference to the shorter timescale

• Get early feed back without going too far down the
wrong track

• Make changes where necessary

39
Business people and developers must work
together daily throughout the project

• Product owner works with the developers

• Share common goal of working software that adds

value to the customer
• Frequent demos

• Face to face communication

• Negotiate requirements and solutions

40
Build projects around motivated individuals
Give them the environment and support they
need and trust them to get the job done
• People make the difference, not merely the process

• Tell the team what to do, but not how to do( not the
top down approach)
• Empower, delegate, give autonomy, recognize

• Facilitate collaboration, team work,(self organizing

teams)

• Knowledge worker can not be micro managed

41
 The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation
• Written documents are slow and costly, and produce
miscommunication, misunderstanding
• Ambiguity is high due to lack of body language
• Face to face is the best
• Open communication is multidirectional

• Does not need much meetings which are unproductive

42
43
44
Working software is the primary measure of
progress
• Working software adds value to customer

• Main focus is software

• Shift from plan driven to value driven
• Planning, documentation and design become
supporting activities

• Evidence of progress is accepted software

45
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely
• Short iterations are repeated

• Efforts are distributed more consistently

• Less cumulated work
• Not necessary to work long hours, good work life
balance, do not burn out, less mistakes, less turn over

• Try to achieve a 40-hour work week and no overtime

46
Continuous attention to technical excellence
and good design enhances agility

• Strike a balance between high value and flexible

design
• Extensible design and architecture give flexibility
• Refactoring, automated testing and continuous
integration ensures technical excellence

47
Simplicity--the art of maximizing the amount of
work not done--is essential
• Build what we need today

• Do not build any thing with the assumption that we

will need them later
• Build only the simplest thing that could possibly
work.

48
The best architectures, requirements, and
designs emerge from self-organizing teams
• Teams are cross functional, self organized and self
managed
• Team decides who do what
• Team collaborate and plan
• Enjoys sense of ownership

• Increases commitment

49
Agile
Methodologies Scrum
extreme Feature Driven
Programming Development
(XP) (FDD)

Evolutionary
Project Dynamic System
Management Development
(Evo) Method (DSDM)
Agile
Methodologies
Kanban Adaptive Software
Development
(ASD)
Lean
Unified Development
Process (LD)
(UP) Crystal

50
Scrum

51
 Scrum
• Scrum is a lightweight framework that helps people, teams and
organizations generate value through adaptive solutions for
complex problems Scrum is:
• In a nutshell, Scrum requires a Scrum Master to foster an
environment where:

1. A Product Owner orders the work for a complex problem

into a Product Backlog.

2. The Scrum Team turns a selection of the work into an

Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results

and adjust for the next Sprint. 4. Repeat
(The Scrum Guide 2020) 52
 Components of Scrum
Roles Time boxes/ Process Artefacts
Product Owner Sprint Planning Product Backlog
Owns the vision, Owns the - Choose work to be done - What should we do?
priorities
Sprint (Heart of
Team Members Sprint Backlog
Scrum)Container
- Carries out work -What should we do
- Duration of the iteration?
immediately?
Scrum master Daily Scrum
- How are we going to do
Mange the scrum process - Coordinates team ‘s work
it ?
?
Sprint Review
Burn down chart
- Get feed back from
- How are we progressing ?
stakeholders?
Sprint Retrospective Product Increments
- How should we improve ? - What are we building?

53
 Scrum events

• The Sprint is a container for all other events

• Each event in Scrum is a formal opportunity to inspect

and adapt Scrum artefacts

• These events are specifically designed to enable the

transparency required

• Failure to operate any events as prescribed results in

lost opportunities to inspect and adapt.

54
 Scrum events

• Events are used in Scrum to create regularity and to

minimize the need for meetings not defined in Scrum.

• Optimally, all events are held at the same time and place
to reduce complexity.

• Scrum events are time boxed with maximum time fixed

but may end early except sprint

• Sprint can not be finished early or extended

55
 Artefacts

• Artefacts represent work or value to provide transparency

and opportunities for inspection and adaptation

• Transparency assures that every one has the same

understanding about work and value

56
 Scrum Team
• The Scrum Team consists of a Product Owner, the
Developers, and a Scrum Master.

• 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
each Sprint.
• They are also self-managing, meaning they internally
decide who does what, when, and how.
57
• The Scrum Team is small enough to remain nimble and
large enough to complete significant work within a
Sprint, typically 10 or fewer people

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

59
• 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, and the Scrum Master.

60
•Starting Scrum Projects
–Create awareness
–Train all on scrum
–Appoint Scrum roles
–Communicate the vision and goals to Team and stakeholders

–Create the Product Backlog

–Estimate back log (sizing)
–Priorities Product Backlog
– Release planning and budgeting

61
62
 Scrum Theory

Scrum is founded on empiricism and lean thinking

Empirical – learning throughout, knowledge come from

experience, make decisions based on what is known.
Lean thinking - Lean thinking reduces waste and focuses on
the essentials
• Scrum employs an iterative, incremental approach to
optimize predictability and to control risk.

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, and adaptation. 63
 Scrum Theory

Scrum is founded on empiricism and lean thinking

Transparency(Visibility)
– The emergent process and work must be visible to those
performing the work as well as those receiving the work.

– With Scrum, important decisions are based on the

perceived state of its three formal artefacts.

– Artefacts that have low transparency can lead to decisions

that diminish value and increase risk

– Transparency enables inspection

64
 Agile is founded on Empirical Process Control Theory
Inspection –
• The Scrum artefacts and the progress toward agreed
goals must be inspected frequently and diligently to
detect potentially undesirable variances or problems.

• To help with inspection, Scrum provides cadence in the

form of its five events. Inspection enables adaptation.

• Inspection without adaptation is considered pointless.

Scrum events are designed to provoke change.

65
Adaptation
• If any aspects of a process deviate outside acceptable
limits or if the resulting product is unacceptable, the
process being applied or the materials being produced
must be adjusted

• The adjustment must be made as soon as possible to

minimize further deviation

• Adaptation becomes more difficult when the people

involved are not empowered or self-managing

• A Scrum Team is expected to adapt the moment it learns

anything new through inspection
66
Product Scrum Roles
Owner
■ Is (or is the representative of) the Customer
■ Product owner is a person and not a committee, may
represent needs of many stakeholders, but changes to the
back log is done through PO
■ Owns the vision, responsible to optimize the value of the
work
Accountable for effective Product Backlog management,
■

which includes:
Developing and explicitly communicating the Product Goal
■

■ Creating and clearly communicating Product Backlog items;

67
 Product Owner
Ordering Product Backlog items; an
■

Ensuring that the Product Backlog is visible, transparent, and

■

understood

■ Ensuring the Development Team understands items in the

Product Backlog

Empowered to make decisions for all; customers and users

■

68
 Product Owner
■ Accept or reject work

■ Responsible for ROI(maximized business value)

■ Product owner is the authority for product back log

▪Interact on a continuous basis with the development team

▪Accept accountability for results and adapting constraints

▪Product owner may perform above work, or delegate to others,

however he is accountable

■ CRACK (Committed, Responsible, Authorized, Collaborative, and

Knowledgeable) 69
Developers Agile Roles
■ Performs the work directed by the PO

Committed to creating any aspect of a usable Increment each Sprint.

■

■ Self-organizing
■ Cross functional
■ Self managed
■ 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.

70
 Developer
No titles for team members
■

■ No sub teams
■ Whole team is accountable for results
10 – complexity, coordination difficulties
■

■ Responsible for estimating and deciding volume of work

■ Full autonomy and authority during a Sprint
■ Self-assigned tasks
■ Demonstrates done increment at the review
■ Team members are not changed during the sprint

71
 Cross functional
teams
Designer
Designer
Designer , coder,
Designer , coder,
Coder , coder, tester
tester
tester

tester
Designer
Coder
, coder,
tester Designer
Designer , coder,
Coder , coder, tester
tester

72
Scrum
Master Agile Roles
■ The Scrum Master is accountable for establishing Scrum as
defined in the Scrum Guide.
■ Helps everyone understand Scrum theory, practices, both within
the Scrum Team and the organization
■ Guides the Agile Execution (facilitates)
■ Responsible for the process
■ 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.
73
 Scrum Master

■ Make sure meeting are held

Representative to management and team
■

Characteristics of a sheepdog
■

■ Protects the teams from interferences

■ Remove road blocks
■ Servant leader, empower, delegate, light touch
■ Metaphor: The Scrum Master is a facilitator, coach, mentor and
bulldozer!

74
 Scrum Master Service to the Product Owner

• 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; and,

• Facilitating stakeholder collaboration as requested or needed.

(Scrum Guide, 2020)

75
Scrum Master Service to the Development Team

• 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; and,

• Ensuring that all Scrum events take place and are

positive, productive, and kept within the time box.
• (Scrum Guide, 2020)
76
Scrum Master Service to the Organization

• 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; and,
• Removing barriers between stakeholders and Scrum
Teams.

(Scrum Guide, 2020)

77
 Roles out side the team

• Business owner
– Person (or people) the Product Owner is (directly)
accountable to for the Team's Work Results, and
who often provides resources and assistance to the
team.
– Scrum master escalate impediments to the BO
– Product owner works with BO in order to;
• Prioritize work
• Finalize diverse need of stakeholders
• Modify release plans
• To get resources for the team
78
 Stakeholders

• Product is built for stakeholders

• Team tries to satisfy their needs, wants and desires
• They review the product and provide feed back

79
 SME
• External to the team
• Practically team may not have all the skills they need
• Provide special knowledge and skills team need(provide
missing knowledge)
• Can represent technical or business area
• Could be a expert on stakeholder needs
• They are not responsible or accountable to the product
owner.

80
 Interactions among the six stakeholders

Responsible Team members are responsible for doing the work the team has
agreed to do and for providing the product owner with the
information needed to make good decisions
Accountable The product owner is the only team member accountable
to the business for the product the team builds and for the
work the team has agreed to do
Supportive The scrum master is supportive of the team by facilitating
its self organization, coaching about scrum , helping the
team remove its impediments, and so on
Consulted External subject matter experts are consulted by team
members if necessary. The SMEs are neither responsible
nor accountable for work the team has agreed to do.
Informed All external stakeholders and the business owner are kept
informed of what the team has agreed to do and the
progress the team is making

81
• Other two accountabilities on the scrum team are:
– Each Team Member is Accountable to the other Team
Members (to the Team) for living the Team Values,
following the Team's agreed-to Practices, making their
own agreements and commitments, and developing
Quality Results
– The Scrum Master is Accountable to the Business to teach
Scrum to the Team, facilitate the Team's self-organization,
help the Team manage its impediments, and assure that
the Team follows its own, agreed-to, process.

82
Agile Planning
 User Stories
• Simple way of capturing user requirements throughout the
project (light weight, just in time, less doc more verbal)
• Written on a card
• Small piece of business functionality. Very slim and high-level
requirements artifacts.
• A simple, clear, brief descriptions of functionality that will add
value to the user or purchaser
• Complete opposite of writing detailed requirements at the
beginning which will not be read most of the time or
misunderstood
84
 User Stories
• Written in summary form and refined as planning
progresses and learning increases
• Written from the users’ perspective focusing value
• No technical aspects of implementation discussed
• Consist of 3 parts.
– Card
– Conversation
– Confirmation
85
 Elements of a User Story

• Card
– Name, description of the user story
– Reference numbers

• As a <user role>, I can

<story> so that <benefit>
– As an employee, I want to view my leave balance ,
so that I can decide how many days I can apply for

86
 Samples – Online Training System
As a policyholder (role), I can
see the account balances on To manage financial obligations
all of my policies (outcome) to (value), policyholders (role) can
manage my financial see the account balances on all of
obligations (value) their policies (outcome)

. .
As a trainee (role), I can see all classes that
cover topics in which I need training
(outcome) within the next six months
(quality requirement) so I can plan my
career development path (value)

87
As a loan approver (role), I can view all income and recurring
financial obligations the applicant has (outcome) rounded to
the nearest dollar (quality requirement) to make a fiscally
responsible decision (value)

As a business rules administrator, I can modify mortgage

conditions to allow the organization to adapt to changing
market conditions

As an applicant, I can navigate to the coverage screen to

select insurance coverage I need

As a reservationist, I can complete at least 12 non-holiday

reservations per hour during daily peak times to reduce
dropped calls caused by long wait times
88
• Conversation
– Notes to remind people about the feature

– Include more details, sketch or diagrams of the

feature

– Brief description of how it functions

• This is not the complete specification. The team
should collaborate to gather more details in
consultation with the PO at the time of
development

– More details will emerge during discussions with

PO and customer

89
 Conversation
#004 User login Size 05

Source: Test Strategies in Agile Projects; Anders Claesson

90
• Confirmation
– Write the test cases. This helps to ensure that
software is designed to pass.

Source: Test Strategies in Agile Projects; Anders Claesson

91
 Definition of Ready

• Definition of Ready involves creating clear criteria

that a user story must meet before being accepted
into an upcoming iteration. This is typically based on
the INVEST matrix.

92
 What Makes a Good User Story ?
The INVEST acronym can help you to remember
– Independent—ideally can be implemented in any
order
– Negotiable—able to discuss with customer various
trade offs based on cost and value, details of the reqmt
– Valuable—to the customer
– Estimatable—effort required to rank and schedule it
– Small—estimating, testing is easy, can be completed in
one iteration, (half a day to 10 days)
– Testable—I could write a test for it. To determine it is
completed
93
Estimating
• All team members get involved, If actual team is not yet
selected, then get a typical team to do it
• Everyone estimates overall size of the item (not just
their part of the work)

• Size = effort, complexity, uncertainty

• Scrum Master facilitates(contributes if he is doing

work)

• Product Owner should be available to clarify

94
requirements
Estimating Effort / Resources over time

Waterfall
ESTIMATING

Agile

Time

95
 Estimating Relative Size
• First estimate the relative size
• Derive duration using velocity
• Tow measures of size:
– Story Point ––relative measurement among User Stories
– Ideal Time ––how long a task takes if there were no
interruptions

96
Relative Size

97
• What is your size estimate for Madagascar?

• If Madagascar is size……. , what is the relative size if

Libya? What is the relative size of India?

98
 Estimating Relative Size
• Ideal Time
– How long will something will take if there is no
interruptions and you only perform that work.

– Ideal time of a foot ball game is 60 minute, elapse time

is 3 hrs

– If you go to work on a Sunday???

99
 Ideal days
• Ideal days are another measurement of size, just as the
story points
• Estimating in ideal hrs is easy, need not consider
interruptions, estimate only amount of time a story will
take

• Estimate the user story in ideal days and derive time

100
Planning Poker

101
• Estimating using planning poker
Story Point Scale

Value Meaning

? Cannot be Estimated
0 No effort Based on natural
½ Fibonacci scale
1
2
3
5 Common
8
13
Has no direct
20
relationship to man hrs.
40
Relative value only no
100 Too large
absolute value, and
α Need to be broken down consistent 102
Team Estimating using Planning Poker

Team Member 1st Round 2nd Round

Ravi 13 8

Kapila 8 5

Saman 5 5

Nelum 3 5

103
 Estimating Velocity

• Use historical data

• Run an iteration

• Make a forecast

104
 Use historical data

Running average of past iterations Analyzing historical data

Valid, only when little has • Mean Optimistic (Best 3) = 41

changed from one iteration • Mean Most likely(Last 8) = 36
to the next iteration • Mean Pessimistic (Worst 3) = 29
– Technology
– Domain If you are left with another 4 sprints
– Product Owner Best=4x41=164
– Tools Average=4x36=144
– Working Environment Worst =4x29=116
– Team Size and Makeup
– Estimators

106
• Long term average, defined as the mean of the last eight sprints
• Worst case average, defined as the mean of the worst three chosen among the
last eight sprints
• Best case average, defined as the mean of the best three chosen among the last
eight sprints

107
 Run an Iteration

• Essentially performs a trial(one to three)

• Observe the velocity

108
 Forecast

• Estimate ideal hours (per developer, per iteration)

• Determine ideal hours per iteration

• Expand user stories into tasks, estimate the tasks, fill

the iteration.

109
 Time Estimation Exercise
• The composition of the Project Alfa is 7 team members
plus scrum master. The estimate of the back log items
came to 200 story points. The velocity of the team is 50
story points per sprint. The duration of the sprint is 3
weeks.

• Calculate the total iterations and time estimation for this

project.

110
 Budget Estimating Exercise

• The project has 3 iterations. The duration of an

iteration is 20 days. The projects employs 8
developers who are paid at the rate of LKR 1000 per
day.

• What is the cost of the project?

111
Product Backlog

• Higher priority items elaborated into more details(ready

for next sprint)
• Multiple scrum team may work with the same back log

• It is the single source of work undertaken by the Scrum

Team

• Changes in business requirements, market conditions, or

technology may cause changes in the Product Backlog
113
Product Backlog
• Product Backlog items can be updated at any time by the
Product Owner or at the Product Owner’s discretion

• Refinement is breaking down and further defining

Product Backlog items into smaller more precise items

• Product backlog refinement is an on-going process

• Not more than 10% of the capacity of the development

team is invested for grooming

114
 Product Back Log
• A Product Backlog is never complete
• Product Backlog evolves
• Product Backlog is dynamic

Attributes of backlog:
• Description
• Size = effort, complexity, uncertainty
• Priority= effort, value, risk, reducing risk, learning
• Attributes vary with the domain of work
– Value= customer satisfaction, alignment with objectives,
attacking risks, improving performance

115
Product Back Log

• The Product Goal is in the Product Backlog

• The Product Goal describes a future state of the product

which can serve as a target for the Scrum Team to plan
against

• The rest of the Product Backlog emerges to define “what”

will fulfil the Product Goal

• A product is a vehicle to deliver value. It has a clear

boundary, known stakeholders, well-defined users or
customers
116
Product Back Log
• A product could be a service, a physical product, or
something more abstract.

• The Product Goal is the long-term objective for the Scrum

Team. They must fulfil (or abandon) one objective before
taking on the next.

• Eg;
– Increase user retention by 15% in Q1
– Double average weekly sessions on mobile by end of May
– Top-rated social fitness cycling app within 12 months
– Launch a website that allows sales to customers inside London.

117
• Product Goal 1 – Launch a website that allows sales to
customers inside London.
Sprint Goal 1 – Create basic website structure
Sprint Goal 2 – Build capability to list & purchase products
using a credit card
Sprint Goal 3+ – … as many more Sprint Goals as needed
Sprint Goal X – Launch the website and fulfil the first orders.
Product Goal 1 has now been fulfilled.

118
• Product Goal 2 – Expand production/delivery
capability to allow sales to customers UK wide.
Sprint Goal 1 – Find UK wide supply partners
Sprint Goal 2 – Review potential partners and select
1-3
Sprint Goal 3+– … as many more Sprint Goals as
needed
Sprint Goal X – Beta launch of national capability
with invited customers only and fulfil first orders.
Product Goal 2 has now been fulfilled.

119
 Features Size Value Prior
Product Back Log ity
A 2 6 1
B 3 5 2
Detailed
C 5 6 3
D 2 1 4
E 8 6 5
F 13 4 6

Prioritized
Estimated G 8 3 7

H 20 5 8

I 13 4 9

Emergent J New Feature 20 4 10

K 40 5 11

L 40 3 12 120
 Product Backlog
Item Priority Value Effort New estimate of effort remaining at end of sprint
1 2 3 4 5 6 7
A 1 10 15 0 0 0 0 0 0 0
B 2 8 10 0 0 0 0 0 0 0
C 3 9 12 12 0 0 0 0 0 0
D 4 9 13 13 0 0 0 0 0 0
E 5 6 14 14 14 0 0 0 0 0
F 6 5 11 11 11 0 0 0 0 0
G 7 6 16 16 16 16 0 0 0 0
H 8 8 09 09 09 09 0 0 0 0
I 9 5 08 08 08 08 08 6 0 0
J 10 7 17 17 17 17 17 12 0 0
K 11 8 13 13 13 13 13 13 10 0
M 12 6 12 12 12 12 12 12 07 0
N 13 5 15 15 15 15 15 15 15 0
O 14 4 10 10 10 10 10 10 10 0
Total 175 150 125 100 75 70 42 0
How do you prioritize stories in the product back log
• Factors to be considered
– Financial value of having the feature
– Cost of developing the new feature
– The amount of risk removed by developing the
features(technological risk and business risk)

• How to combine above factors when prioritizing

– First priorities by looking at value to cost ratio
– Second consider the risk to move forward or back ward
– Generally high value items with high and low risk should
be done first(see matrix in the next slide)
122
 Combining risk and value in prioritizing features.

High
Avoid
Do first

Risk
Do last Do second
Low

Low Value High

123
 Product Road Map

• A product roadmap is a plan of action for how a product

or solution will evolve over time

• Product owners use roadmaps to outline future product

functionality and when new features will be released

• It helps teams focus on where they are going and why

• Identifying high-priority themes will help you focus your

time and energy to do a few things really well

124
• Creating a Road map is a strategic level project
planning process

• A product road map Includes;

– Planned or proposed product releases
– List of high level functionality or release themes
– Rough timeframes for two to three releases

125
Product Road Map

126
Product Road Map

127
 Release
• Release is several iterations that that completes set of related
functionality
• Creating a very high-level plan that covers a period longer than an
iteration
• Three to six months and may be three to twelve or more iterations

• A iteration duration may not be sufficient to deliver a functionality

that satisfy customer
• Can decide how long that will take before they have a releasable
product

• Generally two to three months

• Release durations can vary within a project 128
• Eg; in an investment management system, one
release may include all of the functionality related to
buying and selling mutual funds and money market
funds.
• A second release may add stock and bond trading
and take four additional two-week iterations.

129
 Release Burn Down

60 Scrum Artifacts
50
Features Remaining

40

30

20

10

Sprint Sprint Sprint Sprint Sprint

1 2 3 4 5 130
 Burn Up Chart
• Burn-up chart tracks how much work is done

• It proves both the status and rate of progress

(“velocity”) in a way that is both clear and easy to
discuss.
• It shows more information than a burn-down chart .
That is work load and changes to the work load.

• In 'Burn-Up Chart' the bottom line is the work done

and the top line is the total scope(work load)

• Dotted lines show projections

131
 Burn Up Chart
Burn up chart shows the work that has already been completed.

132
 Sprint Planning
Sprint Planning Meeting
• Product Owner, the Scrum Master and the
Team takes part
• Conduct a collaborative meeting to plan
for the sprint
• Takes 8 hours and consists of 2 parts – 1st
half 4 hrs, 2nd half 4 hrs
• Sprint planning techniques
– Velocity-based
• Based on past velocity
– Capacity-based
• Based on team’s capacity in hours or
days 133
Parts of Sprint Planning Meeting
• 1st Part:
– PO helps to select work from product backlog
– Team makes a soft commitment
– Determine the Sprint Goal
– All agree to DOD
– Product Owner, Scrum Master, Scrum Team will attend

• 2nd Part:
– Scrum Master, Scrum Team will attend
– PO will be available on call
– Features will be broken down in to task and creates sprint
backlog
– Team makes a hard commitment
134
Work Time Available chart
Sprint Duration - 3 Name No of Days in No of hours Total Hours
the sprint per day
weeks
Ravi 13 6 78
No of days on the Saman 10 6 60
sprint - 13 Days Kapila 12 6 72
Nelum 13 5 65
Aravinda 9 5 36
Mahela 13 6 78
Total 389

Buffer 5-10% 39
Project Calendar Back log groom 5-10% 39
Total hours 311
Monday Tuesday Wednesday Thursday Friday
Sprint 1 2 3 4
planning
5 6 7 8 9

10 11 12 13 Product
review and
retrospectiv
e 135
 A Partial Iteration Plan

Iteration 1

Order
Entry
Tasks: Estimate Who:
Confirm Available Inventory. Hours Sue
Place Order Capture Customer Info. 15 Sue
Using Credit Capture Shipping Options 13 Rob
Card Validate Credit Card 8 Slu
Provide Status to User ( pass/fail) 2 Slu
Place Order 2
using Pay
pal
Access / Edit
Shopping
Cart

Cancel
Order
136
 Sprint Backlog
Story Task Volunteer Effort New Estimate of effort at end of day
1 2 3 4 5 6 7 8 9 10
Item A1 Ranjith 7 5 0 0 0 0 0 0 0 0 0
A A2 Kamal 5 3 0 0 0 0 0 0 0 0 0
A3 Kalana 6 6 4 0 0 0 0 0 0 0 0
Item B1 Suresh 10 10 10 6 0 0 0 0 0 0 0
B B2 Nelum 12 12 12 12 10 4 0 0 0 0 0
B3 Pramod 9 9 9 9 7 5 0 0 0 0 0
Item C1 Ranjith 7 7 7 7 7 7 7 4 0 0 0
C C2 Kamal 6 6 6 6 6 6 6 3 0 0 0
C3 Kalana 6 6 6 6 6 6 6 6 3 0 0
Item D1 Suresh 11 11 11 11 11 11 11 11 3 0 0
D D2 Nelum 09 09 09 09 09 09 09 09 09 09 0

Total Man hrs 88 84 74 66 56 48 39 33 15 09 0

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

• The Sprint Goal is created during the Sprint Planning event and
then added to the Sprint Backlog

• As the Developers work during the Sprint, they keep the Sprint
Goal in mind

• If the work turns out to be different than they expected, they

collaborate with the Product Owner to negotiate the scope of the
Sprint Backlog within the Sprint without affecting the Sprint Goal
138
 Sprint goals
The coherent function that is built using items committed
• 'We will get this Product in the hands of users this
Sprint!‘
• Show top-selling products on the homepage”
• “A visitor can order a product”
• “Allow customers to log in to the various products with
OpenID (single sign-on)”;

139
• Product Goal 3– Expand online presence via the
Apple and Google Play app stores.
Sprint Goal 1 – Build basic iOS app
Sprint Goal 2 – Build capability to list products
Sprint Goal 3+ – … as many more Sprint Goals as
needed
Sprint Goal X – Launch the app via the Apple App
Store

140
 Agree to the 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

• Creates transparency by creating a shared understanding

of what it means for work to be complete
• Helps to determine if work is complete
• DoD should be clear to make sure transparency 141
DOD
• If the definition of "Done" for an increment is part of
the conventions, standards or guidelines of the
development organization, all Scrum Teams must follow
it as a minimum

The definition of “Done” usually contains the following:

• Development processes (e.g. programming, testing,
documenting)
• Non-functional features (e.g. security, maintainability,
scalability)
• Quality criteria and acceptance criteria

142
 Agree to the Definition of Done

• When there are no conventions, team decides DOD

• If there are multiple Scrum Teams working on the

system or product release, the Development Teams
on all the Scrum Teams must mutually define the
definition of “Done.”
• PO and team may change the DOD

143
 Time Boxes Sprint

• A 1- 4 week long iteration, during which a product

functionality is created
• Sprints contain and consist of the Sprint Planning, Daily
Scrums, the development work, the Sprint Review, and
the Sprint Retrospective.

• When a Sprint’s horizon is too long the definition of what

is being built may change, complexity may rise, and risk
may increase.
144
 Sprint
• Sprints enable predictability by ensuring inspection and
adaptation of progress toward a Sprint Goal at least
every calendar month.
• Sprints also limit risk to one calendar month of cost.
• Sprint durations are consistent throughout the
development effort
• No changes are made that would endanger the Sprint
Goal
• Quality goals do not decrease
145
Sprint
• Scope may be clarified and re-negotiated between the
Product Owner and Development Team as more is
learned.

• A new Sprint starts immediately after the conclusion of

the previous Sprint.

• No outside influence can interfere with the Scrum team

during the Sprint
• Items can not be changed during the sprint
146
Sprint

Cancelling 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
(stakeholders, the Development Team, or the Scrum Master
may influence this decision but decision is made by PO)

• A Sprint would be cancelled if the Sprint Goal becomes

obsolete(this may happen in case company changes direction,
market or technology changes)

• Releasable items are accepted by the PO

• Incomplete work is estimated and put back on the product

backlog
147
 Backlog Refinement
• Product owner and some, or all, of the rest of the team review items on
the backlog to ensure the backlog contains the appropriate items

• That they are prioritized, and that the items at the top of the backlog are
ready for delivery

• This activity occurs on a regular basis and may be an officially scheduled

meeting or an ongoing activity

• Some of the activities that occur during this refinement of the backlog
include:
– removing user stories that no longer appear relevant
– creating new user stories in response to newly discovered needs
– re-assessing the relative priority of stories
– assigning estimates to stories which have yet to receive one
– correcting estimates in light of newly discovered information
– splitting user stories which are high priority but too coarse grained to fit
in an upcoming iteration
Expected Benefits of Refinement:
• Ensure that the backlog remains populated with
items that are relevant, detailed and estimated to a
degree appropriate with their priority, and in
keeping with current understanding of the project or
product and its objectives.
.
Sprint Burn down
55

50
45
Scrum Artifacts
40

35
Hours Remaining

30

25

20
15

10

Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8

150
 Cumulative Flow Diagram

• Valuable tools for tracking and forecasting agile

projects.

• Helps to identify issues, cycle times, and likely

completion dates.

• Flow diagram provides a graphic depiction of

how stories are moving through various statuses on
the way to being “Done”.

151
Cumulative Flow Diagrams

152
 CFD

• The yellow color section shows work started but not

yet completed
• This is work in progress
• The queue size is the height of the section
• The queue cycle time is the horizontal distance
(Little’s Law)
• Action should be taken to minimize WIP so that sunk
investment cost decreases and risk of increasing
defects is low

153
 A

155
 Cumulative Flow Diagrams

• From a cumulative flow diagram, we can see;

– How well we a delivering value(completing features)
– Where the bottlenecks are in our workflow
– If the scope of the project is changing
( constant, increasing, or decreasing)?
– If we need to continuously improve by limiting WIP
– What is our cycle time?

156
Task Board
• A grid that shows progress
• Maintained by the team
• Updated daily
Item Not Started In Progress Done

Prepare
Coding
Analysis Design Coding
study RaviRavi
– 20– 5 Design
Saman–1 Ravi – 20
materials for Hrs Hrs Saman–
9Hrs Hrs
one day 19Hrs
scrum
workshop
20hrs Testing
Kapila– 5
Hrs

157
 Time Boxes
Daily Scrum
• Is a short (15 minutes long) meeting, which is held
every day before the Team starts working
• Keep standing(to make it brief)
• Participants: Scrum Master ,Scrum Team, PO may
attend
• Helps team members to up date each other(self
organize, synchronize work, report obstacles and
coordinate)
• No discussions, listening only
• Every Team member should answer on 3 questions
158
 Time Boxes
Questions
• What did you do since the last Scrum?

• What are you doing until the next Scrum?

• What is stopping you getting on with the

work?

159
 Daily Standup Meeting

Task board Burn down chart

Burn up chart

160
Time Boxes Sprint Review Meeting

• Is held at the end of each Sprint

• Purpose is to inspect and adapt the product

• Business functionality which was created during the Sprint is

demonstrated to the Product Owner/Customer/stakeholders
invited by PO

– Try out completed product feature

– Inspect the quality and doneness
– Get customer feed back
– Identify improvements (added to Product Backlog)

161
 Sprint Review Meeting

• Informal, should not distract Team members of

doing their work

• Four hrs meeting for one months sprint

• Attendees: Product Owner, Team members, and

Scrum Master and customers, stakeholders, experts,
executives

162
 Sprint Review Meeting

• Based on review results and any changes to the Product

Backlog during the Sprint, attendees collaborate on the next
things that could be done to optimize value

• The result of the Sprint Review is a revised Product Backlog

that defines the probable Product Backlog items for the next
Sprint

163
The Sprint Review includes the following elements:

• The Product Owner explains what Product Backlog items have

been “Done” and what has not been “Done”

• The Development Team discusses what went well during the

Sprint, what problems it ran into, and how those problems were
solved

• The Development Team demonstrates the work that it has

“Done” and answers questions about the Increment

• The Product Owner discusses the Product Backlog as it stands.

He or she projects likely target and delivery dates based on
progress to date (if needed);
164
The Sprint Review includes the following elements:

• The entire group collaborates on what to do next, so that

the Sprint Review provides valuable input to subsequent
Sprint Planning

• Review of how the marketplace or potential use of the

product might have changed. What is the most valuable thing
to do next

• Review of the timeline, budget, potential capabilities, and

marketplace for the next anticipated releases of functionality
or capability of the product.

165
 Time Boxes Sprint Retrospective

• 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
– Create a plan for implementing improvements to the
way the Scrum Team does its work
• The Team, and Scrum Master participate

166
Sprint Retrospective

• Scrum master makes sure that the event happens and

all understand the purpose of it
• Scrum master take part as a team member
representing accountability for scrum process
• Feed back on each others role. Identify improvements
for the next sprint
• Typically takes 3 hours for a 4-week Sprint
• SM participate as a peer team member
167
 Stages of the Retrospective

• Set the stage

• Gather data
• Generate Insights
• Decide What to Do
• Close the retrospective

168
Retrospective
• Set the stage
– Welcome, Explain
purpose, Set goals for the
retrospective, define the
time box
– Safety check-ESVP:
Each participant reports ❑ Health check:
(anonymously) his or her o assess the team’s satisfaction
attitude toward the with the last sprint
retrospective as an o temperature checks (freezing,
cold, warm, hot), weather
Explorer, Shopper, patterns (thunderstorm, rain,
Vacationer, or Prisoner cloudy, sunshine)
(ESVP).

Continued….. 169
ESVP
• Ask the participants to report anonymously their attitude toward the
retrospective as an Explorer, Shopper, Vacationer or Prisoner.

* Explorers – Are eager to discover new ideas and insights. They want to
learn everything they can about the iteration/release/ project

* Shoppers – Will look over all the available information and be happy to
go home with one useful new idea

* Vacationers – Aren’t interested in the work of the retrospective, but are

happy to be away from the daily grind

* Prisoners – Feel they have been forced to attend and would rather be
doing something else

• Collect the results and create a histogram to show the data.

• Acknowledge the results and lead a discussion about what the results
mean for the group.
170
 Retrospective

• Gather data
– Gather data on what happened(events, metrics,
features or stories completed)

• Generate Insights
– Investigate reasons for success and failures

• Decide What to Do
– Make a list of action items to be implemented

171
• Close the Retrospective
– Ensure team document experience and learning
– Have a follow up plan
– Retrospective of retrospective
– ROTI
– Thank the team

• Activities for generating insights(problem solving)

172
Formats for gather data

What should we What should we What should we

start doing stop doing continue doing
Formats for gather data

• What Went Well – What To Improve – What We

Need To Find Out
• Try – Keep – Stop
• Fears – Hopes – Expectations
• Do the Same – Do More – Do Less

• Enjoyable – Frustrating – Puzzling

174
 Mood Timeline

• Team members feeling during the project

• Create a picture of work from many perspectives

• Shows level of satisfaction

175
Mood Timeline

176
Niko-niko Calendar

177
• Five Whys
– Team look at the issue and ask why five times to
find out the root cause
– Why is the employee turn over rate is high?
– …………………………………………………………………
– ………………………………………………………………….
– …………………………………………………………………
– …………………………………………………………………….
– ……………………………………………………………………
– …………………………………………………………………..
– …………………………………………………………………
– …………………………………………………………………….
– ……………………………………………………………………
– ………………………………………………………………….
178
 5 Whys
Why? Why? Why? Why? Why?
Inattentive Ratio of staff Unable to retain Staff turnover =
staff To patients too low Experienced staff unfamiliar with
process
Depressed, Patient’s mental No mental
Re-injury, or health not assessment
illness addressed performed
Doctors spread
Patients too thin
Are
Feel Patient not well Doctors not availible
dissatisfied
Treatment informed about too discuss
ineffective treatment program

Inexperienced Shortage of Hours too long,

Food cooks Pay too low
experienced cooks
distasteful Negative cash
Food budget cut Financial crunch flow

No other rooms Facility inadequate Explain plans

Roommate’s available to meet demands were rejected
Behaviour
disturbing Roommate not Staff do not know No knowledgeable
confronted about how to handle Person available
179
behaviour situation
Fish Bone Diagram

180
Fish Bone Diagram

181
Fish Bone Diagram

182
 Force Field Analysis

• Team brainstorm to identify forces for change and

forces against the change

• Decide actions that can be taken to increase the

forces that support the change and minimize the
threat from negative forces

183
 Mute Mapping
• Used to categorize a lot of ideas quickly

• Put related cards together

• Name the groups
• Vote and select a category for implementation in the
next iteration

185
 Agile Mind set

Being agile and doing agile

• The whole purpose of using agile is to improve business
performance. However, at times, Agilians tend to lose the
focus on delivering value by being too much process-centric
(compliance to the process). Team tend to forget the fact that
Agile is a means to an end, not the end itself(doing agile)

• Instead embrace Agile mind set(being agile)

• These practices are really easy to understand, are really hard

to make stick and get any real value out them.

186
 Being agile and doing agile

Agile mind-set:
• What is mind set?
– Ideas and attitudes with which a person approach
a situation
– Habits of mind formed by previous experience
– How we act, react and think

187
 What is Agile Mind set?
• An agile mind-set is the set of attitudes supporting an
agile working environment. These include respect,
collaboration, improvement and learning cycles, pride in
ownership, focus on delivering value, and the ability to
adapt to change. This mind-set is necessary to cultivate
high-performing teams, who in turn deliver amazing value
for their customers.(Susan McIntosh,2016)

• Agile mind-set is; Set of one’s attitudes, behaviours and

ways of thinking that enhance their and their team’s
effectiveness in working following the agile values and
principles to the benefit of the customers.(Jakub Miler
and Paulina Gaida,2019)
188
What is your mind set

189
 Agile Onion

Agile is a mind-set defined by the Agile Manifesto values, guided by the Agile
Manifesto principles, and enabled by various practices

Jimmie Butler(2019), Timeless Agility: Why "Doing" Agile is the Wrong Approach (Agile Mindset)[Blog post]. Retrieved
190
from https://www.youtube.com/channel/UCDFr5eGIC6puiA1wVwutF9A
 Agile Mind -Set

Being Agile Doing Agile

191
 Agile Mind-set?
• Mind-set is the most powerful of the layers that make up
agile. It is where ‘being agile’ comes from, rather than
‘doing agile’
• Inner rings of the onion reflect doing agile
• Mind set can not be learnt or taught
• Can be obtained by unlearning (command and control,
hierarchy, seniority)

192
 What are the indicators that your team has an Agile
Mind-set?
The attributes contributing to the agile mind-set are:
• They look at failure as a learning opportunity
• Teams welcome different perspectives and diversity of thought
• People are ‘Intrinsically’ Motivated
• People are having fun
• The workplace is sustainable
• The team members can accept change and adapt quickly
• The team is brutally transparent
• People want and need to collaborate and communicate
• Knowledge sharing is done willingly and freely
• Respect for team members
• Continual improvement and learning
• Autonomy
• Focus on delivering value
193
 Stakeholder Engagement

• Knowledge worker project are intangible, invisible,

and unique
• Team members should know what they are building
• Customer should know what he is asking for
• Misunderstanding is common
• Communication and stakeholder engagement is
important
• Uses a range of techniques

194
 Stakeholder Engagement

• According to the PMBOK Guide:

Stakeholders are persons or organizations (ex.,

customers, sponsors, the performing organization, or the
public), who are actively involved in the project or whose
interests may be positively or negatively affected by the
performance or completion of the project.

195
 Stakeholder Engagement

- +
External
stakeholders

+ + -
+
-
Team

+
 Stakeholder Management
• Manage Stakeholders
– In agile, stakeholder management emphasizes on
engagement and involvement and educating them
using inspect and adapt

– Creates an atmosphere of trust (can talk, comment,

highlight issues openly)

– Fist identify stakeholder interest, needs, and values

– Use face to face communication whenever possible,

otherwise use other tools when can not meet in person
197
 Stakeholder Management

• Road blocks beyond the capacity of the team is

posted on the radiator and referred to PM

• Stakeholders can look at changes to release plan

and product back log during planning meeting,
review or retrospective

198
 Stakeholder Engagement
• Get the right stakeholders
– Development team and other supporters

• Ensure stakeholder involvement

– Indicate in the charter importance of stakeholder’s
involvement
– Communicate with them, give feed back, get feed back

• Mange stakeholder expectations

– Satisfy their expectations
– Recognize
199
 Stakeholder Engagement
• Define DOD and discuss through out
– Discuss DOD with the team throughout
– Post the DOD on the radiation
– Reduce gaps and misunderstandings

• Demonstrate what you have done

– To confirm that what is built is correct
– To give progress to the customer

• Openly discuss the progress

– What is done and what is remaining
– Helps customer make important trade off decisions
200
 Communicating with Stakeholders

• Agile projects are intangible, invisible,

• Communication is difficult
• Frequent communication is mandatory
• Use visual tools to communicate so that stakeholders
are updated regularly

201
 Communication Management
• To create trust communication is important

• Determine who need what information, when

• Agile project manager facilitates communication

• After creating road map and release planning

information should be made visible to
stakeholders(releases and iteration dates etc)

• Communicate formally during vision meeting, road map

discussions, release planning, iteration planning and
daily stand up
202
 Communication Management

• After iteration planning meeting iteration goals

should be communicated to stake holders

• Team’s ongoing routine communication will be done

in the war room, if distributed using wikis, Skype, etc

203
 Communication Modes
Always Strive to Use the Most Effective Approach

High emotional
band with

Question and
answer capability

Source: Alistair Cockburn 204

 Daily Standup Meeting

Task board Burn down chart

Burn up chart

205
 Information for Stakeholders

• Details of project manager or agile team leader

• Details of delivery team, with photo, team name, and
mission
• Team war room and location
• Daily stand-up time/location
• Demo, review, and retrospective meeting
dates/times/locations

Source: Michele Sliger Stacia Broderick: The Software Project Manager's Bridge to
Agility
206
 Information for Stakeholders

• Release planning meeting date/time/location

• Iteration planning meeting date/time/location
• The iteration task board (or other tool in which
the team tracks its tasks)
• The current release plan
• Backlogs: product, release and iteration

207
 Information Distribution

• Face to face
• Radiator
• Iteration review
• Retrospective
High Bandwidth Communication: Face to face
communication is also refereed as high bandwidth
communication.

208
 Performance Reporting
• Make available following to stakeholders
– Release and iteration plans
– Customer reviews
– Task boards
– Burn down charts
– Prioritized back logs
– Retrospective findings
– Iteration summaries
– Reviewing release plan based on the performance
in the iteration

209
 Team Space
• Real time, dynamic communication is a key element of agile

• Team space is where people will perform their work

– Collocated or virtual(distributed)

• Team members are not separated from each other by offices or

cubicles

• Co-locate the team, and use low-tech communication tools that are
easy to understand, and easy for the team to keep up-to-date.

• Co-locate desks and facilitate shared access to plans, status, next

steps, and other project planning and management tools

• Best team space facilitates face to face communication

210
 Team Space
• Pairing stations
• Table structure
• Collaboration tools
• Conference space
• Windows

War Room/Bull pen

Shared team space for
conducting meetings and
sharing project planning tools in
a real-time and dynamic
manner
211
A Sample Workplace

Rolling Whiteboards

212
Source : The Art of Agile Development- Shore & Warden
 Team Space

Information
radiator Agile tooling

Knowledge
sharing

Collocated team
Information Radiator

214
 Information Radiator
• An Information radiator is a display posted in a place
where people can see it as they work or walk by

• Displayed in high traffic areas

• Display information using large charts, graphs, and tables

etc.

• Can obtain necessary information without having to ask

anyone a question

• Increased communication with less interruptions 215

 Information Radiator

• A Good Information Radiator

– Is large and easily visible to the casual, interested
observer
– Simple presentation facilitates quick
understanding
– Changes periodically, so that it is worth visiting
– Can easily be up dated(high touch light weight)

216
 Information Radiator

• What will you post on the radiator?

– The current iteration’s stories
– The current work assignments
– The number of tests written (or passed)
– The number of use cases (or stories) delivered
– Burn up/down charts
– The status of key servers (up, down, in
maintenance)
– The results of the last reflection workshop

Source: The Software Project Manager's Bridge to Agility; Michele Sliger Stacia Broderick
217
 Coaching

• Helping the team members continuously improve

their domain knowledge (technical, business),
self-discipline, and “teaming” skills

• Involves training or development in which a person

called a "coach" supports a learner (“coachee”) in
achieving a specific personal or professional goal.
218
 Coaching
.
• What does agile coach do? Teach, facilitate,
collaborate, and mentor

• An Agile Coach helps a team or individual adopt and

improve agile methods and practice

• A Coach helps people rethink and change the way they

go about development

• Acts as a trainer and consultant

219
Agile Coach’s Roles
Facilitator

Problem
solver Teacher

Agile coach

Collaboration
conductor Coach/
mentor

Conflict
navigator

220
 A Paradigm Shift
Coach will move away from Coach will move toward
Coordinating individual Coaching the whole team for
contributions collaboration
Being a subject matter expert Being a facilitator for the team
Being invested in specific Being invested in the team’s
customer overall performance
Knowing the answer Asking the team for the answer
Directing Letting the team find their own
way
Driving Guiding
Talking of deadlines and Talk of business value deliveries
technical options
Talk of doing the optimal thing Talk of doing the right thing for
the business right now
Fixing problems Taking problems to the team
Source: Adkins, Lyssa (2010-05-18). Coaching Agile Teams: 221
 Agile Coach’s Behaviors

Does Does not

Guides and facilitates Direct or drive
Keeps everyone focused on Stick to deadlines and
delivering business value approaches that no longer
work
Has a keen interest in the Become attached to specific
team’s overall performance outcomes from the team
Coaches the team for high Get involved in task- level
performance direction
Promotes the skills and Become the only voice of the
growth of every team team
memberSource: Adkins, Lyssa (2010-05-18). Coaching Agile Teams:
222
 Qualities of a coach
– Openness
– People orientation
– Deep and passionate pursuit of personal and professional
excellence

Two types of coaching

– Whole team coaching
• Generally done at the beginning or end of iteration. Coaching
during the sprint is light weight so that people can focuses
on work

– Individual coaching
• Generally done during iteration to help solve problems or
complaints
223
 Lean and the Kanban Method

• Agile is a set of different methodologies for getting

software built?
• Agile and the Kanban Method are subsets of lean
• Agile and the Kanban Method are descendants of lean
thinking
• This is because they share lean concepts such as: “focus
on value,” “small batch sizes,” and “elimination of
waste.”

224
Agile is a Blanket Term for Many Approaches

Lean
Agile

ScrumBan
Kanban

Crystal

Scrum AUP

FDD
XP

Scrum

225
 Lean
• Name given to Toyota’s method of both producing
and developing cars

• Focuses on value stream(from customer to

development to customer)

• Most errors come from our systems and not from

people

• Minimize work-in-process and maximize the speed at

which business value is created
226
 Lean
• Business strategy focused approach

• All members of the organization should contribute

• Strategic, business-down approach

Lean Scrum
Visioning Product Product Product Development Product Support and
Appl Staffing Deployment Feed back

227
 7 principles of lean
Make team responsible for the process. Helps
Respect people achieve process flexibility, CI, retention of people,
when team’s understanding of work changes,
process changes, process is the baseline.
Reduce non-value adding. Minimize defects, delays,
partially done work, unnecessary features etc.
Correct the system that create waste. • The time
from when a requirement is stated until it is verified
Eliminate waste
as correct • The time from when code is written
until it is tested • The time from when a developer
asks a question of a customer or analyst until she
gets an answer

Do not decide what to do at the beginning. Delay

Differ decisions to last responsible moments, Deliver
commitment most important features, and ones that create
technical risks, if not done early. 228
 7 principles of lean
Software is a discovery process not a building
Create
knowledge process, a product development process, Learn
what customer want from feedbacks, learn often

Means remove delays, delay is waste, deliver fast

Deliver fast with quality and sustainability, Value-based short
releases. Add value to the customer early

To the process and code, all together define

Build quality in acceptance tests before development starts,
automated testing, refactoring, continuous
integration

Not the step but the whole process, from beginning

Optimize the to end fast flexible flow, one piece flow. Inventory
whole hide problems,(requirement errors, design errors,229
229
code errors and integration errors)
 Lean Project Management
• Most errors come from our systems and not from people

• Process is not imposed on the team, it is own by the team

• Helps minimize work-in-process and maximize the speed at which

business value is created

• Lean principles suggest focusing on business value, speed, and

quality
• Value stream mapping is a key tool; focuses on optimizing the whole

• The essence of Lean thinking is “fast-flexible-flow.”

• Lean uses product champion instead of PO

230
 Optimize Whole

• Enterprise focus instead of team focus(product

portfolio management)

• Product focus instead of project focus. (projects are

enhancements to products)

231
 Just in Time
• Producing what you need, only just before we need
them.
• Take a prioritized story and analyze just before it is
built
• Errors in requirements leads to wasted effort to build
and test. This can be avoided when small pieces are
demonstrated to the customer.

232
 Value driven delivery

• Software development should be driven by business

needs
• Find answers to what product will bring maximum
value to the customer, and when can they be used.
• Do not focus on what we are capable of producing

233
 Resource Allocation

• Assign resource with product focus

• Project focus resource allocation leads to

multitasking

234
 What is Kanab?
Kanab is a method for defining, managing, and improving
services that deliver knowledge work, such as professional
services, creative endeavours, and the design of both
physical and software products.

It may be characterized as a “Get started right away”

“start from what you do now” method(start where you are
today) without changing anything; no new process, or
roles,—a catalyst for rapid and focused change within
organizations—that reduces resistance to beneficial change
in line with the organization’s goals.

235
A Work in process
Doing
To do Done

236

236
 Work in process
B
To do Doing Done
• What is work in process for software
development
– Specifications not yet being implemented(after
sometimes specs get out dated with the changes
in the busyness environment)
– Code that is not integrated
– Untested code
– Code not in production(developed and tested
only)

238
 Kanban
• Lean production technique at Toyota

• Kanban means sign board

• Based on pull system
• Work is pulled into the iteration when other work is
completed

• Focuses on work flow, limit work in progress, which helps

identify issues, minimize waste and cost that occur due to
changes during development.

239
 Knaban
• Team select features which are smallest and highest
value

• Uses development pipe lines that have small batches

and queues
• Focuses on entire value steam from concept to
consumption
• Limits work in progress(minimize average cycle time)

240
 Push System

Push and Pull System

Pull System Source: Weekly Diamond ’91.11.2
241 2
• The Kanban Method is less prescriptive than some
agile approaches and less disruptive, as it is the
original “start where- you-are” approach.

242
 Kanban Approach

Kanban Board
3 2 2
To do Analyze Dev Test Done

URGENT
•Principles for setting limits
• simple way to limit WIP is to “stop starting , start fishing”(it is
not “the more you start, the more finish,” it’s the more you
finish, the more you finish”

People idle or Work idle

WIP too high = Work idle WIP too low = People idle

244
 Metrics to guide improvements

• Lead time and cycle time

245
 Kanban Principles
• Visualize
– Visualize work flow on a board, Create sticky notes that represent
work items, track progress

• Limit work in process

– How many items team will work on at the same time
– It will expose problems- stickie moving slowly over the board, a lot of
stickies in certain columns or item stop completely

• Manage flow
– Continuously improve the work flow
– Focus on single piece flow(One piece continuous flow)
– There is no end to this CI effort
– Problems will be reflected on the board(waiting, bugs)
– Move of items from through value adding steps without waiting,
batching, building up inventory, just in time, at the right place and in
the right quantity; no more, no less
246
Hybrid Lifecycles
Concurrent Use of Traditional and Agile Methods:

• Some business units always use traditional methods (e.g.

consulting). Others always use agile methods (e.g.
software development)

• Some projects use a traditional approach, others an agile

one

• Some parts of a project are implemented in a traditional

way, other parts using agile methods

• High-level planning employs a traditional approach,

detailed planning an agile one.
Traditional, Agile and Hybrid Methods
Predictive Adaptive
Project Management Project Management

Traditional
Hybrid Agile
Methods
Methods Methods
Traditional, Hybrid and Blended Agile
Methods
Predictive Adaptive
Project Management Project Management

Traditional
Hybrid Blended
Methods
Methods Agile
 Life Cycle Selection

• No life cycle can be perfect for all projects

• Instead, each project finds a spot on the continuum that
provides an optimum balance of characteristics for its
context
• The Continuum of Life Cycles
High Agile
Incremental

um
Frequency of Delivery

ntinu
C o

Predictive
Low

Iterative

Low Degree of Change High

252
Continuum of Project Lifecycle
 Characteristics Of Hybrid Life Cycles
• It is not necessary to use a single approach for an entire project

• Projects often combine elements of different life cycles in order

to achieve certain goals

• A combination of predictive, iterative, incremental, and/or agile

approaches is a hybrid approach

• Objective is highest value, irrespective of the method used

• Combining flexibility of Agile and reliability of Waterfall. Hybrid

project management can give you the best of both

• Agile alone can be impractical for large teams. It lacks the

structure to hit long term goals with precision.
254
 Hybrid Life Cycles

• Waterfall by itself is not good at adapting to change.

It doesn’t produce working software until close to
the end of the project

• The goal of hybrid project management is to blend

both approaches to get rid of their weaknesses
Hybrid Life Cycles

• Hybrid project management works for every kind of

project and every type of team

• Oftentimes, not all deliverables are fixed and defined.

Costs and resources may not be fully thought out or
dedicated when you start

• Being able to apply Agile to uncertain aspects and

Waterfall to fixed deliverables means having a flexible
project that’s better built for success.
 Hybrid Life Cycles

• As with all hybrid models both sides must

compromise, where the Waterfall development
sacrifice some fixed expectations, to accommodate
flexibility and freedoms of the Agile methods

• The agile will operate with less freedom, targeting a

fixed deadline, with a cost forecast
Hybrid Life Cycles

• Identify the parts of your project that are fixed and

clearly defined.
• Look for deliverables, deadlines, requirements, and
constraints that must be done exactly as defined.
• Use a Waterfall approach for these
• Next, look at the parts of your project that lack fixed
definitions.
 Hybrid Life Cycles

• These are deliverables, requirements, or resources

that might change or haven’t been fully developed
yet.
• These parts of your project belong in an Agile
framework.
• Divide the project in to phases and sub phases
• Define tasks grossly, make space for some flexibility.
 Hybrid Project Management

• Use traditional methods for high-level planning as a

kind of superstructure.
• Add an iterative element afterward using agile work
methods.
Copyright @ Project Management Solutions 261
Copyright @ Project Management Solutions 262
 Hybrid Approach

• PM set the goal for the project

• Project is divided in to phases according to deliverable to be
built
• Each phase gets its backlog, but only the first one is firmly
defined.
• The phases can run in sequence or in parallel, provided there
are no dependencies
• The phases are then split into several sprints.
• The outcome of each sprint modifies the input to the
following sprint, as the team has gained new knowledge and
the product owner has made some changes in the
requirements, accordingly the next sprint gets readjusted.
 Hybrid Approach
• The hybrid sprints commonly last between 4 and 6 weeks

• Overall project responsibility is given to a Project Manager using

WBS methodology whereas the sprints are run by Scrum Masters

• The PM also assumes the role of the product manager, and is

considered the business owner of the project

• He or she is mainly concerned with the front end of the project

flow, including requirements, customer feedback, components
definition and WBS, while Scrum Masters have a hold on the
back end, managing backlogs, sprints and releases.
• The project manager gathers the scrum masters, who in return
form their own teams
• Backlog is managed by project manager and Scrum
Masters.
• Weekly project meeting to review status of overall
project plan.
• ‘Daily stand up Sprint meeting is managed by each
Scrum Master.
• Daily status reporting by each Scrum Master and weekly
brief to management by Project Manager.
When to use hybrid

1. Hybrids as Transitional Stages:

1. Transition should be done gradually
2. Form of a agile approach within a predictive
structure
3. Step by step introduction of agile practices

266
• Agile as a transition strategy helps mitigate risk
of sudden change.
– Gaining agile capabilities takes some times
– Difficult to get the new methodology right first time
– Reducing resistance for change

– Quick, and small wins justify the business case for

the new initiative and build confidence.

267
02. Concerns about Agile Project Management
– Predictive practices helps to overcome some
drawbacks inherent in Agile.

– Add element of predictive method where

necessary

268
03. Concerns about Predictive Project Management
– Use agile elements to address weaknesses of waterfall

269
Some typical concerns Some typical concerns about
about Agile PM Predictive PM

Too customer focused (at the

Lack of response to user needs
expense of shareholders).

Not very clear about long term Lack of flexibility for long term
results results
Inability to estimate cost and
Too large and complex to plan
schedule accurately
and predict

Much historical data on poor

schedule and cost estimates

Top down management

270
04. Choosing an Approach that is Fit for Purpose
– Mix and match according to project factors,
organizational factors, and environmental factors

– Some parts of the project can be delivered early,

project is risky, requirements are changing

271
Agile Development Followed by a Predictive Rollout

Agile Agile Agile Predictive Predictive Predictive

• In the early phases agile is used and latter part of the project uses predictive
practices
• Used when initial part of the project is complex and risky and roll out phase is
repeatable with training of large number of users.

272
A Combined Agile and Predictive Approach Used
Simultaneously

Agile Agile Agile

Predictive Predictive Predictive

• Some times used when team is incrementally transitioning to agile

• Uses short iterations, daily stand-ups, retrospectives as well as predictive practices
like upfront estimation, work assignments and progress tracking

273
A Largely Predictive Approach with Agile
Components

Agile Agile Agile

Predictive Predictive Predictive

• Large part of the project has predictive characteristics, however certain

small area is complex, unfamiliar and uncertain

274
A Largely Agile Approach with a Predictive
Component
Predictive Predictive Predictive

Agile Agile Agile

275
 Agile transformation
• Transforming an organization’s form or nature
gradually to one that is able to embrace and thrive in
a flexible, collaborative, self-organizing, fast changing
environment

• Agile transformation is a sustained process of helping

companies and individuals get the necessary mindset
shift in order to reap the full benefits of agility
 Agile adoption and transformation

• Agile adoption – is doing agile (events processes)

• Agile transformation is “being, becoming or changing

character or condition to one of agility”. t involves a
mind-set change in all people in an organization
 Agile Transformation

• If the organization has been traditionally

managed, the journey will include radical
shifts in attitudes, values, mindsets, ways of
thinking and ways of interacting with the
world—in effect a change in organizational
culture.
• Only 10% org are highly agile
 Main Pillars of Agile Transformation

• Clear understanding and support of Agile values by top

management of the company

• Accumulation of knowledge, skills, and expertise by

people involved ( at all organizational layers)

• Enterprise-level and team-level coaching at several

organizational levels: top management, mid-level
management, and teams
• Readiness to eliminate all impediments and systemic
dysfunctions that the Agile transformation may
reveal.
• With the help of Agile frameworks, companies may
bring to spotlight problems that have been hidden
for a long time.
 Steps of Agile Transformation?

• Define a clear vision; structure, governance,

• Create a leadership coalition.; collaborate with
leadership
• Prepare a transformation roadmap; plans and
schedule in one clear picture
• Adapt and learn; re -asses the final vision based
on the progress
• Provide safety for all involved; make sure all
understand how they will fit in to the new
system and what are the benefits
 Agile Transformation Roadmap

Every transformation is different, but a typical roadmap for

transformation will have several common features:
• Analysis of where the organization is today –
technologically, culturally, in the market, etc.
• Discovery of where the organization would like to be at
some point in the future
• An area of the business where they can pilot a
mini-transformation, from which to gain learning
• A vision to guide the transformation
• Governance as guard rails for the initiation
 Agile Transformation Roadmap

• A communication strategy for those affected directly as

well as indirect effects the rest of the organization may
see
• A change management strategy for working with and
supporting the individuals and teams who will be living
and working within the parameters of the pilot

• A high-level plan for what training, coaching, and

consulting will be provided to these individuals and
teams to make the intended initiative results stick
 Challenges to Overcome

• No leadership buy-in
• Unclear transformation vision-Why are you
transforming? Remind yourself, remind others – often
• No alignment among stakeholders-understanding the
vision
• Culture adverse to agility; policies, governance, reward
• Resistance to change; due to lack of good change
management program
 ORGANIZATIONAL CONSIDERATIONS FOR PROJECT
AGILITY

• Every project exists in an organizational context

• Cultures, structures, and policies can influence both
the direction and the outcome of any project
• These dynamics can challenge project leaders
• Project agility is more effective and sustained as the
organization adjusts to support it
 READINESS FOR CHANGE
• Some organizations may already have
characteristics that support organizational Agility
– Executive management’s willingness to change
– Organization’s willingness to shift the way it views,
reviews, and assesses employees
– Centralization or decentralization of project, program,
and portfolio management functions
– Focus on short-term budgeting and metrics versus
long-term goals
– Talent management maturity and capabilities
• Institutional characteristics that may be roadblocks to
achieving the changes associated with organizational
agility
– Rigid departmentalization that obstruct cross functionality
– Procurement strategies are based on short-term pricing
strategies, rather than long-term competencies
– Leaders are rewarded for local efficiencies rather than
end-to-end flow of project delivery or optimizing the whole
(in regard to the organization)
– Employees are specialized contributors with limited tools or
incentives to diversify their skills instead of building T-shaped
specialists.
– Decentralized portfolios pull employees simultaneously onto
too many projects at once instead of keeping them focused
on one project at a time.
 Approaches project leaders can try to accelerate a
cultural compatibility

• Visible and active executive sponsorship

• Change management practices, including
communication and coaching
• Progressively pacing the adoption of agile practices
on a project-by-project basis
• Incremental introduction of agile practices to the
team
• Leading by example by using agile techniques and
practices where possible.