AN INTRODUCTION

TO AGILE
• What is Agile?
• Uncertainty, Risk & Life Cycle Selection
• Scrum

1
What is Agile
TOPIC A

2
What is Agile?

“Agile is the ability to create and respond to change. It is a

way of dealing with, and ultimately succeeding in, an
uncertain and turbulent environment.”

3
What is Agile?

• Agile is an iterative approach to project management and software development that

helps teams deliver value faster and with fewer headaches.
• Instead of betting everything on a big launch, agile teams deliver work in small,
consumable increments.
• There are numerous widely used agile methodologies, including Scrum, Extreme
Programming, and the Dynamic Systems Development Method.

4
How Did Agile Come About?

• The frustrations of applying sequential project

management methods to software development
resulted in the emergence of Agile.
• A group of leading software developers met in
Snowbird, Utah, USA in 2001 to discuss their
challenges. They ultimately created the Agile
Manifesto.
• Agile uses rolling wave planning, iterative and
incremental delivery, rapid and flexible response to
change, and open communication between teams,
stakeholders, and customers.

5
Agile Manifesto Values, Principles & Common
Practices
• The embodiment of the agile mindset, values, and principles defines what constitutes an
agile approach.
• The various agile approaches in use today share common roots with the agile mindset,
values, and principles.

6
Being Agile v Doing Agile
Beware!
“Culture eats strategy for breakfast” – Peter Drucker*

7
Agile Values

8
Individuals and interactions
over processes and tools

• While processes and tools will likely be

necessary on our projects, we should focus
the team's attention on the individuals and
interactions involved.
• Projects are undertaken by people, not tools
• Problems get solved by people, not
processes
• Projects are ultimately about people

9
Working software over
comprehensive
documentation
• Focus on delivering value vs.
paperwork.
• Agile documents should be barely
sufficient
• Delivering software that does what it
should comes first, before creating
documentation.
• Agile dramatically simplifies the
administrative paperwork relating to
time, cost, and scope control

10
11
Customer collaboration
over contract negotiation
• Be flexible and accommodating, instead
of fixed and uncooperative
• Manage change, don’t suppress it!
• A shared definition of “done”
• Requires trusting relationship

12
Responding to change
over following a plan

• Spend effort and energy responding

to changes
• Software projects tend to have high
rates of change

13
Agile Guiding Principles 1-4

1. Our highest priority is to satisfy the

customer through the early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late
in development. Agile processes harness
change for the customer's competitive
advantage.
3. Deliver working software frequently, from
a couple of weeks to a couple of months,
with a preference for a shorter timescale.
4. Business people and developers must
work together daily throughout the project.

14
Agile Guiding Principles 5-9

5. Build projects around motivated individuals.

Give them the environment and support
they need, and trust them to get the job
done.
6. The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
7. Working software is the primary measure
of progress.
8. Agile processes promote sustainable
development. The sponsors, developers,
and users should be able to maintain a
constant pace indefinitely.
9. Continuous attention to technical
excellence and good design enhances
agility.

15
Agile Guiding Principles 10-12

10. Simplicity, the art of maximizing the

amount of work not done, is essential.
11. The best architectures, requirements, and
designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on
how to become more effective then tunes
and adjusts its behavior accordingly.
NB: Although originating from the software
industry, these principles have since spread to
many other industries such as aerospace,
pharma, banking & finance, engineering &
product development among others.

16
Agile Mindset
• Welcoming change
• Working in small value increments
• Learning through discovery
• Value-driven development
• Failing fast with learning
• Continuous delivery
• Continuous improvement

17
 Agile Approaches & Methods
• “Agile approaches” and “agile methods” are umbrella terms that cover a variety of frameworks
and methods.
• Agile and the Kanban method are descendants of Lean thinking.
• The shared heritage is very similar and focuses on delivering value, respect for people,
minimizing waste, being transparent, adapting to change, and continuously improving

18
 Agile vs. Predictive/Traditional Approach
• Agile builds in increments while
traditional project management builds
as one whole.
• Agile does planning throughout while in
traditional project management,
detailed planning is done all at once
and upfront.
• Agile delivers products over time while
traditional delivers the final product all
at once.
• Agile delivers value faster while
traditional delivers value later – usually
at the end
• Agile embraces changes while
traditional project management
“discourages” changes

19
Benefits of Agile

• Continuous involvement of the customer

through the product development cycle
• Early, measurable return on investment
through defined, iterative delivery of
product increments
• High visibility of project progress, allows
early identification and resolution or
monitoring of problems
• Reduced product and process waste
• Empowerment of the business owner to
make decisions needed to meet goals

20
UNCERTAINTY, RISK, AND LIFE CYCLE SELECTION
TOPIC B

21
Definable Work vs. High Uncertainty Work
• Project work ranges from definable work to high-uncertainty work
• Definable work projects are characterized by clear procedures that have proved successful on
similar projects in the past e.g., the production of a car.
• The production domain and processes involved there are usually well understood and there
are typically low levels of execution uncertainty and risk.
• New design, problem-solving, and not-done-before work is exploratory. It requires Subject
Matter Experts (SMEs) to collaborate and solve problems to create a solution e.g., doctors,
lawyers, and many problem solving-engineers.
• As more definable work is getting automated, project teams are undertaking more high-
uncertainty work.
• High-uncertainty project work has high rates of change, complexity, and risk. These
characteristics can present problems for traditional predictive approaches that aim to
determine the bulk of the requirements upfront and control changes through a change request
process.
• Agile processes were created to explore feasibility in short cycles and quickly adapt based on
evaluation and feedback.

22
Uncertainty, Risk, & Life Cycle Selection

Far from
agreement
CHAOS
Fundamentally
risky

COMPLEX
Requirements

Adaptive
approaches
COMPLICATED work well here

Linear
SIMPLE approaches
Close to work well here
agreement
Close to Far from
certainty Technical Capability
certainty

23
When to Apply Agile Methodilogies

24
Uncertainty, Risk, & Life
Cycle Selection
• Some projects have considerable
uncertainty around project requirements
and how to fulfill those requirements with
current knowledge and technology.
• These uncertainties can contribute to
high rates of change and project
complexity.
• As project uncertainty increases, so too
does the risk of rework and the need to
use a different approach.
•To mitigate the impacts of these risks,
teams select life cycles that allow them to
tackle projects with high amounts of
uncertainty via small increments of work.
•Teams can verify their work when they
use small increments and can change what
they do next.
•When teams deliver small increments,
they are better able to understand the true
customer requirements faster and more
accurately than with a static written
specification 25
 Uncertainty, Risk, & Life Cycle Selection
• Many teams discover that when they explore the requirements iteratively and deliver
more often incrementally, the teams adapt to changes more easily.
• These iterative and incremental approaches reduce waste and rework because the
teams gain feedback. These approaches use:
ü Very short feedback loops
ü Frequent adaptation of process
ü Reprioritization
ü Regularly updated plans, and
ü Frequent delivery

• These iterative, incremental, and agile approaches work well for projects that involve
new or novel tools, techniques, materials, or application domains. They also work
well for projects that:
Ø Require research and development
Ø Have high rates of change
Ø Have unclear or unknown requirements, uncertainty, or risk; or
Ø Have a final goal that is hard to describe

• By building a small increment and then testing and reviewing it, the team can
explore uncertainty at a low cost in a short time, reduce risk, and maximize business
value delivery.
26
Uncertainty, Risk, & Life Cycle Selection

§ Uncertainty may be centered on:

§ Suitability and requirements (is the right product being built?)

§ Technical feasibility and performance (can this product be built this way?)
§ Processes and people (is this an effective way for the team to work?)

• All three of these characteristics – product specification, production capability, and

process suitability – typically have elements of high uncertainty.

• However, iterative and incremental approaches have their limits of applicability.

When both technical uncertainty and requirements uncertainty are very high, the
project moves beyond complex to chaotic.

• In order for the project to become reliably possible, it needs one of the uncertainty
variables to be contained.

27
Life Cycle Selection

• Projects come in many shapes and there are a variety of ways to undertake them.
Project teams need awareness of the characteristics and options available to select
the approach most likely to be successful for the situation.

• The Agile Practice Guide refers to four types of life cycles:

1. Predictive life cycle. A more traditional approach, with the bulk of planning
occurring upfront, then executing in a single pass; a sequential process.

2. Iterative life cycle. An approach that allows feedback for unfinished work to
improve and modify that work.

3. Incremental life cycle. An approach that provides finished deliverables that the
customer may be able to use immediately.

4. Agile life cycle. An approach that is both iterative and incremental to refine work
items and deliver frequently.

28
Characteristics of Project Life Cycles

29
The Continuum of Life Cycles

30
The Continuum of Project Life Cycles

31
 Characteristics of Project Life Cycles

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

v Predictive life cycle. Take advantage of things that are known and proven. This
reduced uncertainty and complexity allows teams to segment work into a sequence
of predictable groupings.

v Iterative life cycle. Allow feedback on partially completed work to improve and
modify that work.

v Incremental life cycle. Provide finished deliverables that the customer may be able
to use immediately.

v Agile life cycle. Leverage both the aspects of iterative and incremental
characteristics. When teams use agile approaches, they iterate over the product to
create finished deliverables. The team gains early feedback and provides customer
visibility, confidence, and control of the product.

• Because the agile team can deliver earlier, the project may provide an earlier return
on investment because the team delivers the highest value work first.
32
34
35
 Planning Horizons of Various Project
Approaches

v Predictive life cycle/Waterfall. Detailed planning for the entire project is done early
during the project. Implementation/execution of the project work follows the plan in a
“predicted” way, with minimal changes.

v Adaptive life cycle/Rolling-wave/Progressive elaboration. Detailed planning is done

for immediate project work, leaving future work that is not properly defined for later. The
plan is progressively detailed or elaborated as more details/information becomes
available with time.

v Agile life cycle. Because of high level of uncertainty characterizing agile projects just a
few days of work (usually 1-2 weeks) can be planned in detail, with most of the project’s
work remaining open to allow for changes and modification.

36
Planning Horizons of Various Project
Approaches

Credit: Oliver Lehman

37
 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.
• This approach can be used when there
is uncertainty, complexity, and risk in the
development portion of the project that
would benefit from an agile approach,
followed by a defined, repeatable rollout
phase that is appropriate to undertake
in a predictive way, perhaps by a
different team.
• For example, the development of a new
high-tech product followed by rollout
and training to thousands of users.
Agile Development + Predictive Rollout

39
Combined Agile + Predictive Approach
Simultaneously

• Daily stand-ups
• Retrospectives
• Short iterations

40
Predominantly Predictive Approach with
some Agile Simultaneously

• A portion of the project with uncertainty, complexity or opportunity for scope creep is
being tackled in an agile way but the rest of the project is managed using predictive
approaches.
• For example, an engineering firm building a facility with a new component or
technology. While the majority of the project may be routine and predictable, this
project incorporates a new roofing material.
• The contractor may plan for small-scale installation trials on the ground first to
determine the best installation method and to uncover issues while there is plenty of
time to solve them and incrementally improve processes through experimentation
and adaptation.
41
Largely Agile Approach with a Predictive Component

• This approach might be used when a particular element is non-negotiable or not

executable using an agile approach.
• For example, integrating an external component developed by a different vendor that
cannot or will not partner in a collaborative or incremental way. A single integration is
required after the component is delivered.

42
Inverting the Triangle

43
Common Agile Terms
• Product Owner - Designated person that represents the customer on the project
• Agile Project Manager/Scrum Master – Manages the agile project
• Product Backlog - Project requirements from the stakeholders
• Sprint Planning Meeting- Meeting done by the agile team to determine what features will be
done in the next sprint
• Sprint Backlog – Work the team selects to get done in the next sprint
Sprint - A short iteration where the project teams work to complete the work in the sprint
backlog, (1-4 weeks typical)
• Daily Stand Up Meeting - A quick meeting each day to discuss project statuses, led by the
Scrum Master. Usually 15 minutes
• Sprint Review – An inspection done at the end of the sprint by the customers Retrospective
– Meeting done to determine what went wrong during the sprint and what when right. Lesson
learned for the sprint.
• Partial Completed Product - Customers Demo the product and provides feedback. This
feedback adjust the next Sprint priorities
• Release - Several Sprints worth of work directed to operations for possible rollout and testing
NB: Refer to glossary from page 957 of the PMBOK Guide 6th Edition for more agile terms

44
 Scrum
TOPIC C

45
Scrum Definition
• Scrum is a lightweight framework that helps
people, teams, and organizations generate
value through adaptive solutions for complex
problems.
• 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

• Scrum is the most common method of agile.

Others include as Extreme Programming
(XP), Crystal, and Scaled Agile Framework
(SAFe).

46
 The Three Pillars of Empiricism
Empiricism means working in a fact-based, experience-based, and evidence-based
manner.

Scrum implements an empirical process where progress is based on observations of

reality, not fictitious plans. Scrum also places great emphasis on mindset and cultural shift
to achieve business and organizational Agility.

47
 The Three Pillars of Empiricism

1. Transparency
• All people involved are transparent in their day-to-day dealings with others.
They all trust each other, and they have the courage to share good news as
well as bad news. All are focused on the organizational objective
2. Inspection
• Timely checks – by everyone on the team - on how well a project is
progressing toward goals.
• The inspection can be done for the product, processes, people aspects,
practices, and continuous improvements. For example, the team openly and
transparently shows the product at the end of each Sprint to the customer in
order to gather valuable feedback
3. Adaptation
• Adaptation is in the context of continuous improvement based on the results
of the inspection. Everyone in the organization must ask this question
regularly: “Are we better off than yesterday?”

48
 History of Scrum

• Ken Schwaber and Jeff Sutherland presented a paper on Scrum at the

OOPSLA* Conference in 1995
• Created as a framework for developing and sustaining complex
products.

The Body of Knowledge of Scrum:

A framework within which people can

address complex adaptive problems,
while productively and creatively
delivering products of the highest
possible value

*Object-Oriented Programming, Systems, Languages &

Applications

https://scrumguides.org 49
50
Scrum Requires Courage

51
 Roles, Artifacts, and Events in the Scrum Framework

Roles

• Product Owner
• Development Team
• Scrum Master
Artifacts

• Product Backlog
• Sprint Backlog
• Increment

Events

• Sprint Planning
• Sprint
• Daily Scrum
• Sprint Review
• Sprint Retrospective

52
Scrum Roles

1. Product Owner
• Owns Product vision
• Chooses what and when to
release
• Maximizes the value of the product
• Responsible for market success
• Manages product backlog and
prioritizes features according to
market value
• Represents stakeholders and
customers to the development
team
• Ideally, the Product Owner has
profit and loss accountability for
the product
53
User Stories

An informal, general explanation of a software

feature written from the perspective of the end user.
Its purpose is to articulate how a software feature
will provide value to the customer.

54
User Stories - Examples

“As a payroll clerk, I want to be able to view a report of all payroll

taxes, so that I can pay them on time”

“As a salesperson, I want to be able to see a current list of leads, so

that I can call them back quickly”

55
User Stories Should Be “INVEST”

• Independent - Should be independent so it can reprioritize

• Negotiable - Should allow for trade-offs based on cost and function
• Valuable - Should clearly state the value of it
• Estimatable - Should be able to estimate how long to complete
• Small - Stories should be between 4-40 hours of work
• Testable - Should be testable to ensure it will be accepted once competed

56
2. Scrum Master
• Responsible for facilitating the
process
• Promotes and supports Scrum as
defined in the Scrum Guide
• Helps everyone understand Scrum
theory, values, practices, and rules
• Focuses Team and protects them
from external interruption
• Looks for ways to enhance
productivity
• Servant leader

• Personifies agility and

professionalism

57
3. Development Team
• Creates the product increment
• A small group containing all necessary
project skills
• Focuses on steady delivery of high-
quality features
• Operates in a series of Sprints
• Organizes itself and its work
• Collaborates with Product Owner to
maximize value

58
Scrum Team

59
Scrum Artifacts

*Each one contains specific information

1. Product • Holds the requirements for the product

Backlog • Managed by the Product Owner
2. Sprint Backlog • Holds all work for the Sprint Goal
• Managed by the Development Team
3. Increment • Working addition to the product
• Potentially releasable

60
1. Scrum Artifacts: Product Backlog

• Prioritized list of all work that needs to be done

to complete the product
• Transparent unit of deliverable work
• Contains clear acceptable criteria
• Criteria for successful completion

• Answering what will be true when this works

• Items in it are prioritized by the Product Owner

and are sorted by value
• The backlog is dynamic, it evolves as more
work is added and prioritized

61
Product Backlog Refinement

• Product 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.
• Top ordered Product Backlog items are
well understood and easily selected in
Sprint Planning

62
2. Scrum Artifacts: Sprint Backlog

• The Sprint Backlog is composed of:

• The Sprint Goal (why?)

• The set of Product Backlog items selected for the Sprint (what?)

• An actionable plan for delivering the Increment (how?)

• It’s owned and managed by the Development Team

• It is a highly visible, real-time picture of the work that the Developers plan to
accomplish during the Sprint in order to achieve the Sprint Goal
• It is updated throughout the Sprint as more is learned.
• It should have enough detail that Development Team can inspect their progress
in the Daily Scrum.
• It should contain at least one high-priority process improvement that was
identified in the previous Sprint Retrospective

63
3. Scrum Artifacts: Increment

• The Increment is the sum of all the Product Backlog items

completed during the Sprint
• The product is the sum of all Increments
• Is usable and works
• Is potentially releasable
• Must be “done” – as per the Scrum Team standards and
with no work remaining.

64
Scrum Events

*Each one has a specific purpose

1. Sprint Planning • To: Forecast, Sprint Goal, Sprint Backlog

2. Sprint • Container event
• 30 Days, or less, in duration
3. Daily Scrum • To: Update Daily Plan
4. Sprint Review • To: Update Product Backlog
5. Sprint Retrospective • Improvements for next Sprint

65
Roles, Artifacts, and Events in the Scrum Framework

66
1. Scrum Events: Sprint
Planning Meeting (1/3)
• Initiates the Sprint by laying out
the work to be performed for the
Sprint.
• Scrum Team discuss the most
important Product Backlog items
and how they map to the Product
Goal.
• Addresses the following topics:
1. Why is this Sprint valuable?
• The Product Owner proposes
how the product could increase
its value or utility in the current
Sprint
• The Scrum team defines a Sprint
Goal that communicates why the
Sprint is valuable to Stakeholders
• The Sprint Goal must be defined
by the end of Sprint Planning

67
1. Scrum Events: Sprint
Planning Meeting (2/3)
2. What can be done in this
Sprint?
• In discussion with the Product
Owner, the Developers select
items from the Product Backlog to
include in the current Sprint
• The Scrum Team may refine these
items during this process, which
increases understanding and
confidence
• Selecting how much can be
completed within a Sprint may be
challenging. The more the
Developers know about their past
performance, their upcoming
capacity, and their Definition of
Done, the more confident they will
be in their Sprint forecasts.

68
1. Scrum Events: Sprint Planning
Meeting (3/3)
3. How will the chosen work get
done?
• For each selected Product
Backlog item, the Developers plan
the work necessary to create an
Increment that meets the
Definition of Done.
• How this is done is at the sole
discretion of the Developers. No
one else tells them how to turn
Product Backlog items into
Increments of value.
• The Sprint Goal, the Product
Backlog items selected for the
Sprint, plus the plan for delivering
them are together referred to as
the Sprint Backlog.
• Sprint Planning is timeboxed to a
maximum of eight hours for a one-
month Sprint. For shorter Sprints,
the event is usually shorter
69
Definition of Done (DoD)

• Definition of “Done” (DoD) is a formal description

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

70
2. Scrum Events: Sprint
• Sprints are the heartbeat of Scrum, where ideas are turned into value.
• They are fixed-length events of one month, or less, to create consistency.
• A new Sprint starts immediately after the conclusion of the previous Sprint.
• All the work necessary to achieve the Product Goal, including Sprint Planning, Daily
Scrum, Sprint Review, and Sprint Retrospective, happen within Sprints.
• Starts with Sprint Planning
• Ends with Sprint Retrospective

During the Sprint:

ü No changes are made that would endanger the Sprint Goal
ü The Development Team members are kept the same throughout
ü The Product Backlog is refined as needed
ü The scope may be clarified and renegotiated with the Product Owner as more is learned.

71
Sprint Goal

An objective to be met in the • Through the implementation of the Product

Sprint Backlog Items (PBIs) selected in Sprint Planning
• Provides guidance to the Development Team
Allows flexibility in delivering • Allows wiggle room for exact implementation of
the Increment PBIs
Is fixed throughout the Sprint • The Development Team keeps this goal in mind as
it works
• The Development Team inspects and adapts their
plan to meet the Sprint Goal in every Daily Scrum

72
3. Scrum Events: Daily Scrum

• A 15-minute time-boxed activity for the

Development Team to synchronize
activities and create a plan for the next
24 hours
• Inspects progress toward the Sprint
Goal
• Inspects how progress is trending
toward completing work in the Sprint
Backlog
• Should be held at the same time and
place each day
• Each team member should answer 3
questions:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your
way?

73
Why Daily Scrum?
• Development Team share commitments
• Identify impediments
• Create focus
• Increase and maintain situational
awareness

74
4. Scrum Events: Sprint
Review
• The Product Increment is inspected
with the stakeholders (customer,
marketing, sales, etc)
• Designed to gather feedback from
stakeholders on what the
Development Team has completed in
the Sprint
• To create a conversation between the
Team and the stakeholders about
how to make the product better.
• The Product Backlog is updated with
new insights
• Should be time-boxed to no more
than an hour per week of Sprint

75
What Happens at Sprint Reviews?

Product Owner Shares Development Team Shares Everyone

• What was done • The actual Increment of • Provides and
• What wasn’t done software hears feedback
• State of the product • What happened in the
Backlog Sprint
• Projections of likely • How problems were
release targets addressed and the effect
on the Increment

76
 5. Scrum Events: Sprint
Retrospective
• The purpose of the Sprint Retrospective is to
plan ways to increase quality and
effectiveness.
• The Scrum Team inspects how the last Sprint
went with regard to individuals, interactions,
processes, tools, and their Definition of Done.
• The Scrum Team discusses what went well
during the Sprint, what problems it
encountered, and how those problems were
(or were not) solved.
• The Scrum Team identifies the most helpful
changes to improve its effectiveness. The
most impactful improvements are addressed
as soon as possible. They may even be
added to the Sprint Backlog for the next
Sprint.
• The Sprint Retrospective concludes the
Sprint.

77
Other “Agile” Approaches
TOPIC D

79
Other “Agile” Approaches

80
1. Kanban
• Also known as a “Pull System” is a
system for visually managing workflow
as it moves through your process.
• “Kanban” is a Japanese word that
loosely translates to “sign” or
“billboard”
• Was developed by Toyota in the 1950s
for manufacturing
• Kanban does not use time-boxed
iterations
• A Kanban system is intended to send
signals to the entire value chain from
the supplier to the end consumer.
• It helps prevent supply disruption,
overproduction, and excess inventory
at various stages of the manufacturing
process.
• Originally intended for manufacturing
but is now used in many non-
manufacturing applications, especially
in software development.
81
1. Kanban

https://youtu.be/jf0tlbt9lx0
82
Kanban Board
• An "information radiator" - ensures efficient diffusion of
information
• Can be drawn on a whiteboard or even a section of wall
• Makes iteration backlog visible
• Serves as a focal point for the daily meeting

Limit Work In Progress (WIP)

• Represents money spent with no
return
• Hides process bottlenecks that
slow the processes
• Agile processes aim to limit and
optimize WIP
• Optimal WIP makes processes
efficient
Core Principles of Kanban
The four core principles of Kanban are:
• Visualize work
• Limit work-in-progress
• Focus on flow
• Continuous improvement

84
2. Extreme Programming (XP)
• Extreme Programming is a software development methodology intended to
improve software quality and responsiveness to changing customer requirements.
• As a type of agile software development, it advocates frequent releases in short
development cycles, intended to improve productivity and introduce checkpoints at which
new customer requirements can be adopted

85
 XP Core Values
• Simplicity – reduce complexity, extra features, and waste. “what is the
simplest thing that will work?”
• Communication – Software development is inherently a team effort that relies
on communication to transfer knowledge from one team member to everyone
else on the team. XP prefers face-to-face discussion with the aid of a
whiteboard
• Feedback - gives the team an opportunity to improve. The team builds
something, gathers feedback on your design and implementation, and then
adjusts your product going forward
• Courage – You need courage to raise organizational issues that reduce your
team’s effectiveness; to stop doing something that doesn’t work and try
something else; to accept and act on feedback, even when it’s difficult to
accept.
• Respect – members of your team need to respect each other in order to
communicate with each other, provide and accept feedback, and to work
together to identify simple designs and solutions.

http://www.extremeprogramming.org/start.html

86
XP Team Roles
1. The Coach: Usually an outside consultant or someone from elsewhere in
your organization who has used XP before. Mentors the other team
members on the XP Practices
2. The Customer: Provides requirements, defines acceptance criteria,
defines business case, and prioritizes features. Is actively engaged and
ideally becomes part of the team.
3. The Developer: The developers who write the code. Responsible for
realizing the stories identified by the Customer. Cross-functional teams.
4. Trackers: In addition to programming, they track relevant Agile metrics,
such as velocity, burndown charts etc. This helps them track their team’s
progress and identify where the team can improve.

87
XP Core Practices (1/2)

Whole Team
• Team members are colocated
• Generalizing specialists, not role specialist
• Efficient sharing of information
Customer Tests
• The customer specifies scenarios to test when a user story has been correctly
implemented.
• A story can have one or many acceptance tests, whatever it takes to ensure
the functionality works.
Collective Code Ownership
• Any developer can improve or amend the code or fix bugs
• Multiple people will work on all the code
• Improves defect discovery and resolution
• Knowledge is shared, not hoarded.

88
XP Core Practices (1/2)

Sustainable Pace
• Productivity is optimized through a sustainable pace
• Consistent overtime and long hours are not sustainable
Refactoring
• Cleaning up the code by removing redundancy, eliminating unused
functionality, and rejuvenating obsolete designs

89
3. Lean Product Development
• Lean is a way of thinking about creating needed value with fewer
resources and less waste.
• The focus of Lean is on reducing waste in all business processes. The
result is the reduction of cost and lead time as well as an increase in
quality.
• To be lean is to provide what is needed, when it is needed, with the
minimum amount of materials, equipment, labour, and space.
• Lean thinking always starts with the customer. Ask: “What problem does
the customer need to solve?”
• The Toyota Production System is widely acclaimed as the most successful
implementation of Lean manufacturing

90
Seven Lean Core Concepts
1. Eliminate waste
2. Empower the team
3. Deliver fast
4. Build quality in
5. Defer decisions - to the last responsible moment
6. Amplify learning
7. See the whole - Be flashlight focused rather than laser-focused

91
Seven Wastes of Lean

Image credit: https://kanbanize.com 92

Seven Eight Wastes of
Lean

Behold the eighth waste of lean!

8. Unutilized talent

93
Summing Up
• 50% of the PMP exam questions are on agile and hybrid approaches
• Agile approaches use rolling-wave planning, iterative, and incremental
delivery to deliver value early in projects characterized by uncertainty and
complexity
• There are four project life cycles that project teams can harness for the
successful delivery of value: predictive, iterative, incremental, and agile.
• A hybrid approach leverages the strengths of the four main life cycles
• Project teams should select the right project life cycle based on the
characteristics of the project.
• “Agile” is not a methodology or framework. Rather, it’s an umbrella term
covering a variety of frameworks and methods.

94
Go Ye Forth and Be Agile…

https://www.pmi.org/certifications/become-a-project-manager/certification-
framework
95