The Scrum Guide: Ken Schwaber & Jeff Sutherland

Ken Schwaber & Jeff Sutherland
The Scrum Guide

The Definitive Guide to Scrum: The Rules of the Game
November 2020
Purpose of the Scrum Guide
We developed Scrum in the early 1990s. We wrote the first version of the Scrum Guide in 2010 to help
people worldwide understand Scrum. We have evolved the Guide since then through small, functional
updates. Together, we stand behind it.
The Scrum Guide contains the definition of Scrum. Each element of the framework serves a specific
purpose that is essential to the overall value and results realized with Scrum. Changing the core design
or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and
limits the benefits of Scrum, potentially even rendering it useless.
We follow the growing use of Scrum within an ever-growing complex world. We are humbled to see
Scrum being adopted in many domains holding essentially complex work, beyond software product
development where Scrum has its roots. As Scrum’s use spreads, developers, researchers, analysts,
scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude,
but to simplify. If you get value from Scrum, consider yourself included.
As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in
this document, may be found, applied and devised. Their description is beyond the purpose of the
Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for
using within the Scrum framework vary widely and are described elsewhere.
Ken Schwaber & Jeff Sutherland November 2020
© 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share-Alike license of Creative Commons,
accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary
form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution
Share-Alike license of Creative Commons.
1
Purpose of the Scrum Guide .......................................................................................................................... 1
Scrum Definition ............................................................................................................................................ 3
Scrum Theory ................................................................................................................................................. 3
Transparency ............................................................................................................................................. 3
Inspection .................................................................................................................................................. 4
Adaptation ................................................................................................................................................. 4
Scrum Values ................................................................................................................................................. 4
Scrum Team ................................................................................................................................................... 5
Developers ................................................................................................................................................. 5
Product Owner ........................................................................................................................................... 5
Scrum Master............................................................................................................................................. 6
Scrum Events ................................................................................................................................................. 7
The Sprint ................................................................................................................................................... 7
Sprint Planning ........................................................................................................................................... 8
Daily Scrum ................................................................................................................................................ 9
Sprint Review ............................................................................................................................................. 9
Sprint Retrospective ................................................................................................................................10
Scrum Artifacts.............................................................................................................................................10
Product Backlog .......................................................................................................................................10
Commitment: Product Goal .................................................................................................................11
Sprint Backlog ..........................................................................................................................................11
Commitment: Sprint Goal ....................................................................................................................11
Increment.................................................................................................................................................11
Commitment: Definition of Done ........................................................................................................12
End Note ......................................................................................................................................................13
Acknowledgements .................................................................................................................................13
People ..................................................................................................................................................13
Scrum Guide History ............................................................................................................................13
2
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 simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals
and create value. The Scrum framework is purposefully incomplete, only defining the parts required to
implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather
than provide people with detailed instructions, the rules of Scrum guide their relationships and
interactions.
Various processes, techniques and methods can be employed within the framework. Scrum wraps
around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of
current management, environment, and work techniques, so that improvements can be made.
Scrum Theory
Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from
experience and making decisions based on what is observed. Lean thinking reduces waste and focuses
on the essentials.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk. Scrum
engages groups of people who collectively have all the skills and expertise to do the work and share or
acquire such skills as needed.
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.
Transparency
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 artifacts.
Artifacts that have low transparency can lead to decisions that diminish value and increase risk.
3
Transparency enables inspection. Inspection without transparency is misleading and wasteful.
Inspection
The Scrum artifacts 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.
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.
Scrum Values
Successful use of Scrum depends on people becoming more proficient in living five values:
Commitment, Focus, Openness, Respect, and Courage
The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on
the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its
stakeholders are open about the work and the challenges. Scrum Team members respect each other to
be capable, independent people, and are respected as such by the people with whom they work. The
Scrum Team members have the courage to do the right thing, to work on tough problems.
These values give direction to the Scrum Team with regard to their work, actions, and behavior. The
decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not
diminish or undermine them. The Scrum Team members learn and explore the values as they work with
the Scrum events and artifacts. When these values are embodied by the Scrum Team and the people
they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life
building trust.
4
Scrum Team
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of
one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams
or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value
each Sprint. They are also self-managing, meaning they internally decide who does what, when, and
how.
The Scrum Team is small enough to remain nimble and large enough to complete significant work within
a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better
and are more productive. If Scrum Teams become too large, they should consider reorganizing into
multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the
same Product Goal, Product Backlog, and Product Owner.
The Scrum Team is responsible for all product-related activities from stakeholder collaboration,
verification, maintenance, operation, experimentation, research and development, and anything else
that might be required. They are structured and empowered by the organization to manage their own
work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum
defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and
the Scrum Master.
Developers
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable
Increment each Sprint.
The specific skills needed by the Developers are often broad and will vary with the domain of work.
However, the Developers are always accountable for:
● Creating a plan for the Sprint, the Sprint Backlog;

● Instilling quality by adhering to a Definition of Done;
● Adapting their plan each day toward the Sprint Goal; and,
● Holding each other accountable as professionals.
Product Owner
The Product Owner is accountable for maximizing the value of the product resulting from the work of
the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
5
The Product Owner is also accountable for effective Product Backlog management, which includes:
● Developing and explicitly communicating the Product Goal;

● Creating and clearly communicating Product Backlog items;
● Ordering Product Backlog items; and,
● Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the
Product Owner remains accountable.
For Product Owners to succeed, the entire organization must respect their decisions. These decisions
are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at
the Sprint Review.
The Product Owner is one person, not a committee. The Product Owner may represent the needs of
many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by
trying to convince the Product Owner.
Scrum Master
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by
helping everyone understand Scrum theory and practice, both within the Scrum Team and the
organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the
Scrum Team to improve its practices, within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
The Scrum Master serves the Scrum Team in several ways, including:
● Coaching the team members in self-management and cross-functionality;

● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of
Done;
● Causing the removal of impediments to the Scrum Team’s progress; and,
● Ensuring that all Scrum events take place and are positive, productive, and kept within the
timebox.
The Scrum Master serves the Product Owner in several ways, including:
6
● 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.
The Scrum Master serves the organization in several ways, including:
● Leading, training, and coaching the organization in its Scrum adoption;

● Planning and advising Scrum implementations within the organization;
● Helping employees and stakeholders understand and enact an empirical approach for complex
work; and,
● Removing barriers between stakeholders and Scrum Teams.
Scrum Events
The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and
adapt Scrum artifacts. 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. 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.
The 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 Scrums, Sprint
Review, and Sprint Retrospective, happen within Sprints.
During the Sprint:
● No changes are made that would endanger the Sprint Goal;

● Quality does not decrease;
● The Product Backlog is refined as needed; and,
● Scope may be clarified and renegotiated with the Product Owner as more is learned.
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at
least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid,
complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning
7
cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short
project.
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While
proven useful, these do not replace the importance of empiricism. In complex environments, what will
happen is unknown. Only what has already happened may be used for forward-looking decision making.
A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the
authority to cancel the Sprint.
Sprint Planning
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting
plan is created by the collaborative work of the entire Scrum Team.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog
items and how they map to the Product Goal. The Scrum Team may also invite other people to attend
Sprint Planning to provide advice.
Sprint Planning addresses the following topics:
Topic One: Why is this Sprint valuable?

The Product Owner proposes how the product could increase its value and utility in the current Sprint.
The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is
valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.
Topic Two: What can be Done this Sprint?

Through 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. However, 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.
Topic Three: 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. This is often done by decomposing Product Backlog items into
smaller work items of one day or less. 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.
8
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.
Daily Scrum
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint
Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is
held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master
are actively working on items in the Sprint Backlog, they participate as Developers.
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum
focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.
This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-making, and
consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet
throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s
work.
Sprint Review
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future
adaptations. The Scrum Team presents the results of their work to key stakeholders and progress
toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and
what has changed in their environment. Based on this information, attendees collaborate on what to do
next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a
working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours
for a one-month Sprint. For shorter Sprints, the event is usually shorter.
9
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 regards to individuals, interactions, processes,
tools, and their Definition of Done. Inspected elements often vary with the domain of work.
Assumptions that led them astray are identified and their origins explored. 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. It is timeboxed to a maximum of three hours for a one-
month Sprint. For shorter Sprints, the event is usually shorter.
Scrum Artifacts
Scrum’s artifacts represent work or value. They are designed to maximize transparency of key
information. Thus, everyone inspecting them has the same basis for adaptation.
Each artifact contains a commitment to ensure it provides information that enhances transparency and
focus against which progress can be measured:
● For the Product Backlog it is the Product Goal.

● For the Sprint Backlog it is the Sprint Goal.
● For the Increment it is the Definition of Done.
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their
stakeholders.
Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the
single source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for
selection in a Sprint Planning event. They usually acquire this degree of transparency after refining
activities. 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. Attributes often vary with the domain of work.
10
The Developers who will be doing the work are responsible for the sizing. The Product Owner may
influence the Developers by helping them understand and select trade-offs.
Commitment: Product Goal

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team
to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to
define “what” will fulfill the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined
users or customers. A product could be a service, a physical product, or something more abstract.
The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one
objective before taking on the next.
Sprint Backlog
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for
the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Sprint Backlog is a plan by and for the Developers. 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.
Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have
enough detail that they can inspect their progress in the Daily Scrum.
Commitment: Sprint Goal

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the
Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also
creates coherence and focus, encouraging the Scrum Team to work together rather than on separate
initiatives.
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.
Increment
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all
prior Increments and thoroughly verified, ensuring that all Increments work together. In order to
provide value, the Increment must be usable.
11
Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the
Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders
prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Work cannot be considered part of an Increment unless it meets the Definition of Done.
Commitment: Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality
measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what
work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of
Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product
Backlog for future consideration.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams
must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a
Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams
working together on a product, they must mutually define and comply with the same Definition of Done.
12
End Note
Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While
implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety
and functions well as a container for other techniques, methodologies, and practices.
Acknowledgements
People
Of the thousands of people who have contributed to Scrum, we should single out those who were
instrumental at the start: Jeff Sutherland worked with Jeff McKenna and John Scumniotales, and Ken
Schwaber worked with Mike Smith and Chris Martin, and all of them worked together. Many others
contributed in the ensuing years and without their help Scrum would not be refined as it is today.
Scrum Guide History

Ken Schwaber and Jeff Sutherland first co-presented Scrum at the OOPSLA Conference in 1995. It
essentially documented the learning that Ken and Jeff gained over the previous few years and made
public the first formal definition of Scrum.
The Scrum Guide documents Scrum as developed, evolved, and sustained for 30-plus years by Jeff
Sutherland and Ken Schwaber. Other sources provide patterns, processes, and insights that complement
the Scrum framework. These may increase productivity, value, creativity, and satisfaction with the
results.
The complete history of Scrum is described elsewhere. To honor the first places where it was tried and
proven, we recognize Individual Inc., Newspage, Fidelity Investments, and IDX (now GE Medical).
© 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share-Alike license of Creative Commons,
accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary
form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution
Share-Alike license of Creative Commons.
13
9/8/2021
Some Stats!
• Almost 25% of the world gross product is spent on projects ($10 trillion
out of $40.7 trillion).
• More than 16 million PMs1 out there!
• The overall information and communications technology market grew by
6 percent to almost $3 trillion in 2010
• In the U.S. the size of the IT workforce topped 4 million workers in 2008,
and the unemployment rate for IT professionals is half the rate for the
overall labor market
• In 2011 the total compensation for the average senior project manager in
U.S. dollars was $105,000 per year in the United States and $160,409 in
the Switzerland.
• The number of people earning their Project Management Professional
(PMP) certification continues to increase. 44 percent of employers listed
project management as a skill they looked for in new college grads,
behind only communication and technical skills
• A PricewaterhouseCoopers study found that overall half of all projects fail
and only 2.5% of corporations consistently meet their targets for scope,
time, and cost goals for all types of project.
15
1. People who consider Project Management as their profession.
Public
Project Management Framework
16
Public
Public 8
9/8/2021
What Helps Projects to Succeed?1

1. User involvement
2. Executive support
3. Clear business objectives
4. Emotional maturity
5. Optimizing scope
6. Agile process
7. Project management expertise
8. Skilled resources
9. Execution
10. Tools and infrastructure
1. The Standish Group, “CHAOS Activity News” (August 2011).
17
Public
What the Winners Do?
18
Public
Public 9
9/8/2021
Project, Program & Portfolio Management
Portfolio Manager:
Am I choosing the right projects for a given investment?
Am I considering business value and competitive advantage when
choosing projects?
Do I have the resource capacity and capability to execute by project
portfolio?
Are my projects aligning with corporate strategy, vision and mission?
Program Manager:
Am I providing adequate support to PMs?
Am I optimizing a set of dependent projects?
Am I able to perform time & cost prioritization / trade-off within a
given program?
Am I able to contribute to fixing process inefficiencies?
Project Manager:
Am I meeting the triple constraints: scope, time & cost?
Am I following the project management processes?
Am I delivering based on the quality requirements?
Am I holding the required functional team accountable and
keeping the stakeholders informed?
19
Public
Organization Structures
Sample Organization
Functional Project Matrix

• Each staff has one • Staff directly report • Blend of functional
into the PMs and and projectized
clear supervisor. consequently to organization.
• Staff members are Program Managers. • Most resources will
groped by the area of • PMs have higher have multiple
expertise at the top independence and reporting
level. authority. relationships.
20
Public
Public 10
9/8/2021
Sample Organization Structures
21
Public
Team Diversity in IT Projects

• Contemporary IT project teams are globally dispersed and
encompasses multi-generation staff.
• IT project managers must develop the skills to work with:

– staff with diverse cultures
– staff with different mother tongues
– staff who hold different values
– staff who represent various generations
22
Public
Public 11
9/21/2020
Overview
• This module introduces the learner to the System
Development Life Cycle (SDLC) and common roles and
responsibilities involved during the SDLC phases.
• An overview of various project life cycles and their

advantages and disadvantages are discussed.
• Concept of Systems Thinking and its applicability to IT

project management is introduced.
Public
What is Systems Development Methodology?

• “A systems development methodology is a recommended means to achieve the development, or
part of the development, of information systems based on a set of rationales and an underlying
philosophy that supports, justifies and makes coherent such a recommendation for a particular
context. The recommended means usually includes the identification of phases, procedures, tasks,
rules, techniques, guidelines, documentation and tools. They might also include recommendations
concerning the management and organization of the approach and the identification and training of
the participants”
- Source: Avison, D., & Fitzgerald, G. (2006). Information systems development: Methodologies, techniques and tools (4th ed.). London: McGraw-Hill .
• “A system development methodology refers to the framework that is used to structure, plan, and
control the process of developing an information system”
- Selecting A Development Approach. (2008, March 27). Retrieved January 11, 2016, from https://www.cms.gov/research-statistics-data-and-systems/cms-information-
technology/xlc/downloads/selectingdevelopmentapproach.pdf
Public
Public 2
9/21/2020
System Development Life Cycle (SDLC) Phases
Planning & Requirements Design

• System and software design
• Review Projects & Prioritize
prepared
• Identify Resources
• Hardware & software acquired if
• Business Requirements Gathered
necessary
Support / Maintenance
• Conduct post-implementation Implementation & Coding
review • Actual development starts and
• Identify defects or enhancements product built (s/w code generated)
Deployment Testing
• Product (code) is tested against
• Product is delivered (deployed) in
requirements
production environment for
• Defects reported, fixed and re-
5 customer use
tested
This document is marked Confidential
Participants in SDLC
Customer
Developers
Systems Analysts
BAs
Vendor
Web Master
Project Manager
QA
Network Engineer
Product Owner
Users
Steering
Committee
6
Public 3
9/21/2020
SLC Activities
Project Life Cycles

“A project life cycle is the series of phases that a project passes through from its start to its
completion. It provides the basic framework for managing the project. The basic framework
applies regardless of the specific project work involved. The phases may be sequential,
iterative, or overlapping.”
(PMBok, 2017; p.19)
 Predictive Life Cycle

 Iterative Life Cycle
 Incremental Life Cycle
 Adaptive Life Cycle
 Hybrid Life Cycle
Public 4
9/21/2020
Predictive Life Cycle (Waterfall)

“In a predictive life cycle, the project scope, time, and cost are determined in the early
phase of the life cycle. Any changes to the scope are carefully managed. Predictive life
cycles may also be referred to as waterfall life cycles.”
(PMBok, 2017; p.19)
Concept
> Project is divided into sequence of phases that are usually done one after the other (minimal overlap may
be possible)
> Scope, requirements, schedule and budget are usually defined at the beginning of the project and is
expected to delivery within the originally defined variance.
> Project control is rigid using “Gate” reviews and extensive documentation sign-off process.
PROS CONS
> Rigid structure and controls makes it inflexible,
slow and costly.
> Provides structure and a repeatable framework
> Early identification of business requirement are
for less experienced Project managers and
needed.
teams.
> Any discovery of inconsistencies during the design
> Gate reviews and approval enables quality,
and coding phase are cumbersome to fix.
reliability and maintainability of the system.
> Issues may not come to light till system testing.
> Project progress can be quantified.
> Hard to respond to changes.
> Resource can be planned and levelled.
> Excessive documentation that may not provide
value.
9 > Gap between development team and users.
Waterfall Methodology
Feasibility Study
Requirements Gathering
Design
Unit Test
System Integration Test
Client Acceptance Test
Delivery & Maintenance

10
10
Public 5
9/21/2020
Requirements Gathering (Waterfall)

Functional Requirements:
 Specifies something that the system can do

 Typically, functional requirements will specify a behavior or function
(e.g.: Adding a Customer’s Social Insurance Number to their account in a banking
application).
 Typical functional requirements can include:
 Business requirements and rules
 Administrative functions
 Authentications
 Authorization levels
 Audit tracking
 External interfaces
 Certification requirements
 Reporting requirements
 Historical data
 Legal and regulatory requirements
11
Public
11
Requirements Gathering (Waterfall)
• Non-Functional Requirements:
 Specifies how the system should behave
 Typically, non-functional requirements are quality attributes of a system (e.g.: All transactions
made by the client should be processes within 2 seconds from the time of submission through
the banking application).
 Typical non-functional requirements can include:
 Security
 Performance
 Usability
 Availability
 Confidentiality
 Reliability
 Operability
 Traceability
 Recoverability
 Visibility
12
Public
12
Public 6
9/21/2020
Iterative Life Cycle

“In an iterative life cycle, the project scope is generally determined early in the project life
cycle, but time and cost estimates are routinely modified as the project team’s
understanding of the product increases. Iterations develop the product through a series of
repeated cycles, while increments successively add to the functionality of the product.
(PMBok, 2017; p.19)
Concept
> Project requirements are divided and prioritized into smaller segments, providing flexibility to change
during the development phase.
> User is involved throughout the lifecycle of the project.
> Each iteration provides a small scale mock-ups of the system until the prototype evolves to meet the user’s
requirement.
PROS CONS
> Detailed requirements for the entire system
does not need to be specified at the beginning > Lack of governance over approval process.
of the project. > Requirements may frequently change
> Improves user participation and significantly.
communication between stakeholders. > Identification of non-functional elements is
> Potential to exploit knowledge gained in the difficult to document.
earlier iteration as later iterations are > Designers may neglect documentation, resulting
developed. in insufficient justification for the final product
> Encourages innovation and flexible design. and inadequate records for future.
> Helps easily identify confusing or difficult > Can lead to a false expectation of a complete
functions and missing functionality. system being built when only partial
functionalities are complete.
13
13
Incremental Life Cycle

“In an incremental life cycle, the deliverable is produced through a series of iterations
that successively add functionality within a predetermined time frame. The deliverable
contains the necessary and sufficient capability to be considered complete only after the
final iteration.”
(PMBok, 2017; p.19)
Concept
> The primary objective of this methodology is to reduce the risk of the project by breaking a project into
smaller segments and making it easy to changes during the development.
> Every iteration is a “mini-waterfall”.
> Each iteration provides a usable component until the iterations evolve to fulfill all user requirements.
PROS CONS
> Detailed requirements for the entire system > Lack of overall consideration for the business
does not need to be specified at the beginning problem and technical requirements.
of the project. > Requirements may frequently change
> Improves user participation and communication significantly.
between stakeholders. > Difficult problems tend to be pushed to future
> Potential to exploit knowledge gained in the to demonstrate early success to management.
earlier iteration as later iterations are > Designers may neglect documentation, resulting
developed. in insufficient justification for the final product
> Encourages innovation and flexible design. and inadequate records for future.
> Provides the ability for quick implementation of > Can lead to a false expectation of a complete
a functional component of a system. system being built when only partial
functionalities are complete.
14 > Moderate control is maintained over the life of
the project through essential artifacts.
14
Public 7
9/21/2020
Adaptive Life Cycle

“A hybrid life cycle is a combination of predictive and an adaptive life cycle. Those
elements of the project that are well known or have fixed requirements follow a
predictive development life cycle, and those elements that are still evolving follow an
adaptive development life cycle.”
(PMBok, 2017; p.19)
15
Public
15
Hybrid Life Cycle

“Adaptive life cycles are agile, iterative, or incremental. The detailed scope is defined
and approved before the start of an iteration. Adaptive life cycles are also referred to as
agile or change-driven life cycles.
(PMBok, 2017; p.19)
16
Public
16
Public 8
9/21/2020
Definitions of Systems Thinking
• Merriam - Webster Dictionary: a system (not systems thinking!) is defined as a

regularly interacting or interdependent group of items forming a unified whole.
• Barry Richmond (the originator of the systems thinking term): the art and
science of making reliable inferences about behavior by developing an
increasingly deep understanding of underlying structure.
• Peter Senge (leader in the field / MIT): discipline for seeing wholes and a
framework for seeing interrelationships rather than things, for seeing patterns of
change rather than static snapshot.
• Sweeney & Sterman (authors & researchers): involves the ability to represent
and assess dynamic complexity (e.g., behavior that arises from the interaction
of a system’s agents over time), both textually and graphically.
• Kopainsky, Alessi & Davidsen: systems thinking should include appreciation for
long term planning, feedback loops, non-linear relationships between variables,
and collaborative planning across areas of an organization.
17
Public
17
Can you see a pattern…

• Slumber
• Pillow
• Dream
This Photo by Unknown Author is licensed under CC BY-SA
• Night
• Bed
• Blanket
• Quiet
• Pajamas
• Nap
• Snooze
18
Public
18
Public 9
9/21/2020
Characteristics of Systems Thinking
1. Recognizing Interconnections
2. Identifying Feedback
3. Understanding Dynamic Behavior
4. Differentiating types of flows and variables
5. Using Conceptual Models
6. Creating Simulation Models
7. Testing Policies
19
This Photo by Unknown Author is licensed under CC BY-SA-NC
Public
19
Operation Cat Drop
• https://www.youtube.com/watch?v=17BP9n6g1F0
20
Public
20
Public 10
9/21/2020
Causal Loop Diagrams

• Causal Loop Diagram provides an overview on how one element of the
system effects the rest of the system.
• It is a visual representation that enables the understanding of how

different elements interact with each other in a system.
• Causal Loop Diagrams are useful to illustrate and understand complex

systems; examine the details of the interaction of various elements and
can be a tool of education for those who are unfamiliar with the system.
• It may become too complex to illustrate every element that interacts with
the system; so it is only represents the broadest view of the system.
• Types of loops:
– Reinforcement Loops (R)
– Balancing Loops (B)
21
Public
21
Draw your Systems Diagram
22
Public
22
Public 11
9/21/2020
General Principles Controlling Complex Systems
1. Today's problems come from yesterday's solutions.

2. The harder you push, the harder the system pushes back.
3. Behavior grows better before it grows worse.
4. The easy way out leads back in.
5. The cure can be worse than the disease.
6. Faster is slower.
7. Cause and effect are not always closely related in time and space.
8. Small changes can produce big results -- but the areas of highest
leverage are often the least obvious.
9. You can have your cake and eat it too -- but not all at once.
10. Dividing an elephant in half does not produce two small elephants.
11. There is no blame.
Source: Senge, P. M. (1993). The Fifth Discipline: The Art and Practice of the Learning Organization: Book review. Consulting Psychology Journal:
Practice and Research, 45(4),
23
Public
23
Exercise
Based on your knowledge with Loblaw; identify one project that Loblaw can
undertake for the next fiscal year and complete the Business Requirements
Document.
Loblaw Company Limited is the largest Canadian food retailer currently

operating under 22 regional and market segment banners. In addition to
being the biggest grocery, Loblaw Company Limited is also in health care
(owns Shoppers Drug Mart), Fashion (owns Joe Fresh) and Financial Services
(owns PC Financial) sectors.
24
Public
24
Public 12
9/28/2020
Module Overview
Public
What is Agile Manifesto?
• 1986: In an article called “New Product Development” in the Harvard Business Review by
Hirotaka Tekeuchi and Ikujiro Nonaka, the authors describe a rapid, flexible development
strategy to meet faced-paced product demands.
• 2001: A group of software and product experts got together to talk about what their
successful project had in common; this group created the Agile Manifesto and the Agile
Principles.
• Agile Manifesto is an internationally streamlined expression of the core values of agile

project management.
• Agile principles are 12 practices that help support the values in the Agile Manifesto.
Public
Public 2
9/28/2020
Manifesto for Agile Software Development
5
©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
This declaration may be freely copied in any form, but only in its entirety through this notice.
Public
The 12 Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
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.
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.
Public
Public 3
9/28/2020
What is Unique in Agile?

• Use empirical control method – a process where decision making is based on realities
observed a project progresses.
• Transparency: constant interaction with all stakeholders enables all parties to be well
aware of the progress of the project at any one time.
• Frequent Inspection: product is evaluated at regular intervals.
• Adaptation: enable adjustments to be made quickly to minimize issues and any change
can be immediate.
• Agile has to go through all the phases of “Waterfall” as well, but instead of completing
the phases for all of the product features at once, project is broken down into iterations,
called “sprints”
Public
Benefits of Agile
• Greater flexibility and stability
• Reduced non-productive tasks
• Higher quality, delivered faster
• Improved team performance
• Tighter project control
• Faster and less costly failure
Public
Public 4
9/28/2020
Major Agile Approaches
Public
Agile Environment
• Physical environment
– Collocating the team
– Setting up a dedicated area
– Removing distractions
– Going mobile
• Low- Tech Communication

– White board
– Sticky notes
– Colorful pens
– Kanban board (optional)
• High-Tech Communication
– Video conferencing and webcam
– Instant messaging
– Web-based desktop sharing
– Collaboration websites
10
Public
10
Public 5
9/28/2020
Discuss the Agile Environment
• How do you remove distraction?

• How do you “Go Mobile”
• What are some collaboration
websites?
11
Public
11
Agile Behaviors
• Establishing Agile Roles
– Development team
– Product owner
– Scrum master
– Stakeholders
– Agile mentor
• Establishing New Values

– Commitment
– Focus
– Openness
– Respect
– Courage
• Changing Team Philosophy

– Cross functionality
– Self-organization
– Self-management
– Size-limited teams
– Mature behavior
12
Public
12
Public 6
9/28/2020
The Agile Roadmap to Value
Source: The agile roadmap to value diagrams - Google Search. (n.d.). Retrieved January 18, 2016, from https://www.google.ca/search?q=the agile
13 roadmap to value
diagrams&biw=1420&bih=724&tbm=isch&imgil=7D92FF5UBAXBeM%3A%3BQlvkOvmr74uxQM%3Bhttps%253A%252F%252Fwww.linkedin.com%252Fp
ulse%252Fvalueweb-roadmap-connected-economy-indranil-nath&sou
Public
13
The Agile Roadmap to Value – Stage 1
14
Public
14
Public 7
9/28/2020
15
Public
15
16
Public
16
Public 8
9/28/2020
17
Public
17
18
Public
18
Public 9
9/28/2020
19
Public
19
20
Public
20
Public 10
5/7/2021
Overview
• This module explores one of the agile manifesto values,
“working software over comprehensive documentation”
and one of the agile manifesto principles, “working
software is the primary measure of progress”.
• Topics such as assessing value, prioritizing value, delivering

incrementally, agile contracting, verifying and validating
value will be elaborated in this section.
Public
Value-Driven Delivery
• “A project is a temporary endeavor undertaken to create a unique product, service or
result” (Project Management Institute, 2017).
• The intent of the unique product, service or result is to generate business value.
• Business value can range from increasing the profitability of the organization to
reducing the risk to the organization.
• Value delivery can act as a guiding principle for portfolio mix decision making or even
within project task decision making: ‘which project / project task provides the most
business value?’
• One of the value propositions of agile is early delivery of business value; that is, deliver
the functions that provide the highest business value as soon as possible.
• Delivering early value also garners early stakeholder satisfaction and consequently
committed support from sponsors and other parties which has interest or influence
over the project.
4
Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide): And, Agile practice guide (Sixth edition., Vol. 1–1 online resource : illustrations.). Project
Management Institute. Public
Public 2
5/7/2021
Agile
Business Value
Traditional
Time
Public
How to Minimize Waste?

One way to enhance value is by reducing waste (“Muda”). Lean Manufacturing
Principles have identified seven major categories of waste, which is mapped to lean
software development by Mary and Tom Poppendeick.
Wastes Identified in Lean Manufacturing Poppendiecks’ List of Software Waste

Inventory Incomplete / Partial work done
Extra Processing Extra or not need Features
Overproduction Additional Processor / Documentatio
Transportation Task Switching
Waiting Waiting / Delay
Motion Hand-off
Defects Defects
Public
Public 3
5/7/2021
Accessing Value
• Project values are usually assessed in financial terms:
• Return on Investment (ROI)
• Net Present Value (NPV)
• Internal Rate of Return (IRR)
• Regulatory projects can be measured by the ramifications of not doing it.
Public
Earned Value Management - Agile
Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide): And, Agile practice guide (Sixth edition., Vol. 1–1
online resource : illustrations.). Project Management Institute. P.69
8
Public
Public 4
5/7/2021
Issues with Earned Value Management - Agile

• Earned value management is based on ‘baseline’ and if the baseline is not
accurate, then EVM doesn’t measure precisely.
• EVM doesn’t inform if the project is brining value.
Public
Key Performance Indicators (KPIs)
• Rate of Progress
• Remaining Work
• Likely Completion Date
• Likely Costs Remaining
This Photo by Unknown Author is licensed under CC BY-NC-ND
10
Public
10
Public 5
5/7/2021
Risk Management Process
• Anything that can potentially reduce value delivery can be considered as a risk.
Plan Risk Identify

Management Risks
Perform
Monitor Qualitative
Risks Risk
Analysis
Implement
Plan Risk
Risk
Response
Responses
11
Public
11
Prioritizing Value
“Accommodate changing requirements throughout the development process”
• Customer-Valued Prioritization
• Scrum – backlog
Which
• FDD – feature list feature do
• DSDM – requirements list you want to
do next?
12
Public
12
Public 6
5/7/2021
Prioritization Schemes
• MoSCoW
• Must have
• Should have
• Could have
• Would like to have, but not at this time
• Monopoly Money
• Dot Voting (Multi-voting)
• Kano Analysis
13
Public
13
Minimal Viable Product (MVP)
• The smallest deliverable that can add value to users.
• It is also known as Minimum Marketable Feature (MMF); a single MMF is typically

comprised of a group of user stories. By focusing on breaking the project into
MMFs, the team can focus on a small set of valuable functionality that can be
delivered to the customer quickly.
• The team may also decide to deliver the MVP to a subset of clients to first get
feedback before providing further features.
Crowe, A. (2018). The PMI-ACP Exam: How To Pass On Your First Try, Iteration 3. Velociteach.
14
Public
14
Public 7
5/7/2021
Kanban Boards
• These are visual representation that can be used for planning, monitoring and
controlling project tasks.
• A Kanban board usually has 3 columns: “To-Do”, “In-Progress (Doing)” and “Done”
• All activities that needs to be released to production is tracked here and the visual
representation provides a clear view of the status to team and other stakeholders.
15
This Photo by Unknown Author is licensed under CC BY

Public
15
Kanban Boards - WIP

• WIP – Work In Progress (or ‘In Progress’, ‘Doing’) is the active work that is currently
being undertaken, but not completed.
• WIP item consume resources; however, they do not bring ‘value’ till they are
moved to “Done”
• WIP may also mask bottleneck in the process and provides a false sense of
efficiency.
• A common way to deal with the above problems is to limit the WIP.
16
Public
16
Public 8
5/7/2021
Little’s Law
L=λ*W
L = Average number of items in the system
λ = Average arrival rate
W= Average wait time in the system
17
Public
17
Little’s Law in a Steady State System
L=λ*W
L = Work in Progress
λ = Customer Demand Rate
W= Lead Time
Finished
Raw
Goods
Material
18
Public
18
Public 9
5/7/2021
Agile Contracting
• Agile teams must ensure that vendor contracts are carefully crafted to ensure that
the major vendors (stakeholders in the project) are informed that they are
expected to work based on the agile principles; this can be articulated in the
Request for Proposal (RFP).
• Since in agile projects, requirements can change, and scope is negotiable,

traditional fixed price contracts may not serve the purpose; hence tailored
contracts specifically made for agile projects must be used:
• Fixed-price work package
• Graduated fixed-price contracts
19
Public
19
THANK YOU.
Public
20
Public 10
5/7/2021
IT
ProjecT
managemenT
Public
Enabling Continuous
Improvement:
Assessing Organization Culture, Tailoring
Process, Removing Non-Value Add Work &
Developing Maturing Assessment Models
Public
Public 1
5/7/2021
Overview
“working software over comprehensive documentation”
and one of the agile manifesto principles, “working
software is the primary measure of progress”.
• Topics such as assessing value, prioritizing value, delivering

incrementally, agile contracting, verifying and validating
value will be elaborated in this section.
Public
• “A project is a temporary endeavor undertaken to create a unique product, service or
result” (Project Management Institute, 2017).
• The intent of the unique product, service or result is to generate business value.
• Business value can range from increasing the profitability of the organization to
reducing the risk to the organization.
• Value delivery can act as a guiding principle for portfolio mix decision making or even
within project task decision making: ‘which project / project task provides the most
business value?’
• One of the value propositions of agile is early delivery of business value; that is, deliver
the functions that provide the highest business value as soon as possible.
• Delivering early value also garners early stakeholder satisfaction and consequently
committed support from sponsors and other parties which has interest or influence
over the project.
4
Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide): And, Agile practice guide (Sixth edition., Vol. 1–1 online resource : illustrations.). Project
Management Institute. Public
Public 2
5/7/2021
Agile
Business Value
Traditional
Time
Public
How to Minimize Waste?

One way to enhance value is by reducing waste (“Muda”). Lean Manufacturing
Principles have identified seven major categories of waste, which is mapped to lean
software development by Mary and Tom Poppendeick.
Wastes Identified in Lean Manufacturing Poppendiecks’ List of Software Waste

Inventory Incomplete / Partial work done
Extra Processing Extra or not need Features
Overproduction Additional Processor / Documentatio
Transportation Task Switching
Waiting Waiting / Delay
Motion Hand-off
Defects Defects
Public
Public 3
5/7/2021
Accessing Value
• Project values are usually assessed in financial terms:
• Return on Investment (ROI)
• Net Present Value (NPV)
• Internal Rate of Return (IRR)
• Regulatory projects can be measured by the ramifications of not doing it.
Public
Earned Value Management - Agile
Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide): And, Agile practice guide (Sixth edition., Vol. 1–1
online resource : illustrations.). Project Management Institute. P.69
8
Public
Public 4
5/7/2021
Issues with Earned Value Management - Agile

• Earned value management is based on ‘baseline’ and if the baseline is not
accurate, then EVM doesn’t measure precisely.
• EVM doesn’t inform if the project is brining value.
Public
Key Performance Indicators (KPIs)
• Rate of Progress
• Remaining Work
• Likely Completion Date
• Likely Costs Remaining
10
Public
10
Public 5
5/7/2021
Risk Management Process
• Anything that can potentially reduce value delivery can be considered as a risk.
Plan Risk Identify

Management Risks
Perform
Monitor Qualitative
Risks Risk
Analysis
Implement
Plan Risk
Risk
Response
Responses
11
Public
11
Prioritizing Value
“Accommodate changing requirements throughout the development process”
• Customer-Valued Prioritization
• Scrum – backlog
Which
• FDD – feature list feature do
• DSDM – requirements list you want to
do next?
12
Public
12
Public 6
5/7/2021
Prioritization Schemes
• MoSCoW
• Must have
• Should have
• Could have
• Would like to have, but not at this time
• Monopoly Money
• Dot Voting (Multi-voting)
• Kano Analysis
13
Public
13
Minimal Viable Product (MVP)
• The smallest deliverable that can add value to users.
• It is also known as Minimum Marketable Feature (MMF); a single MMF is typically

comprised of a group of user stories. By focusing on breaking the project into
MMFs, the team can focus on a small set of valuable functionality that can be
delivered to the customer quickly.
• The team may also decide to deliver the MVP to a subset of clients to first get
feedback before providing further features.
Crowe, A. (2018). The PMI-ACP Exam: How To Pass On Your First Try, Iteration 3. Velociteach.
14
Public
14
Public 7
5/7/2021
Kanban Boards
• These are visual representation that can be used for planning, monitoring and
controlling project tasks.
• A Kanban board usually has 3 columns: “To-Do”, “In-Progress (Doing)” and “Done”
• All activities that needs to be released to production is tracked here and the visual
representation provides a clear view of the status to team and other stakeholders.
15

Public
15
Kanban Boards - WIP

• WIP – Work In Progress (or ‘In Progress’, ‘Doing’) is the active work that is currently
being undertaken, but not completed.
• WIP item consume resources; however, they do not bring ‘value’ till they are
moved to “Done”
• WIP may also mask bottleneck in the process and provides a false sense of
efficiency.
• A common way to deal with the above problems is to limit the WIP.
16
Public
16
Public 8
5/7/2021
Little’s Law
L=λ*W
L = Average number of items in the system
λ = Average arrival rate
W= Average wait time in the system
17
Public
17
Little’s Law in a Steady State System
L=λ*W
L = Work in Progress
λ = Customer Demand Rate
W= Lead Time
Finished
Raw
Goods
Material
18
Public
18
Public 9
5/7/2021
Agile Contracting
• Agile teams must ensure that vendor contracts are carefully crafted to ensure that
the major vendors (stakeholders in the project) are informed that they are
expected to work based on the agile principles; this can be articulated in the
Request for Proposal (RFP).
• Since in agile projects, requirements can change, and scope is negotiable,

traditional fixed price contracts may not serve the purpose; hence tailored
contracts specifically made for agile projects must be used:
• Fixed-price work package
• Graduated fixed-price contracts
19
Public
19
THANK YOU.
Public
20
Public 10
5/7/2021
IT
ProjecT
managemenT
Public
Maintaining Stakeholder
Engagement:
Engaging empowered business stakeholders
and promote participation and collaboration
throughout the project life cycle
Public
Public 1
5/7/2021
Coming Soon….
Public
THANK YOU.
Public
Public 2
5/7/2021
IT
ProjecT
managemenT
Public
Enhancing Team
Performance:
Establishing Cross-Functional Teams,
Empowering Teams to Self-Organize and
Nurturing High-Performance Teams
Public
Public 1
5/7/2021
Overview
“Individuals and interactions over processes and tools” by
studying how teams are organized, motivated and makes
decisions.
• This section also divulge into building self-organizing teams

and tracking team performance.
Public
Building Self-Organizing Teams

• After the world war II, management paradigm started changing from the top-down
scientific model (“Taylorism”) to more humanistic approach where the workers had
more input into decisions; this change started with the Japanese management
approach guided by Deming and others.
• Agile teams advocate for small teams of generalizing specialists; that is, team members
are highly flexible and adaptive who can fulfill cross-functional roles.
• Teams will have a shard common purpose and also will hold each other accountable for
the outcome of the project. That is, team is either successful or failed!
Public
Public 2
5/7/2021
Team Development Models

• Shu-Ha-Ri Model
• Dreyfus Model
• Tuckman Model
Public
Shu-Ha-Ri Model
• Alistair Cockburn conceived this three-step skill mastery process
Ri
Ha
Shu
Shu: Obey the rules
6 Ha: Consciously move away from the rules
Ri: Unconsciously find an individual path
Public
Public 3
5/7/2021
Dreyfus Model
• Stuart E. Dreyfus hypothesized that adults learn new skills over five stages.
Expert
Proficient
Competent
Advanced Beginner
Novice
Public
Tuckman Model
• Bruce Tuckman originated the team formation and development model.
Adjourning
Performing
Norming
Storming
Forming
Public
Public 4
5/7/2021
Leadership Styles
Delegating
Directing
Supporting
Coaching
Public
Coaching Guidelines
• Lyssa Adkins provided some expert advise on how to perform one-on-one

coaching:
• Meet them a half-step ahead

• Guarantee safety
• Partner with managers
• Create positive regard
10
Public
10
Public 5
5/7/2021
Team Performance
Burndown Chart
11
Public
11
Team Performance
Burn-up Chart

12
Public
12
Public 6
5/7/2021
Velocity
• Velocity is a common way of measuring progress within agile projects.
• It usually represents how many points were completed within one

iteration.
• Usually the velocity increases iteration after iteration and then stabilizes at
some point; once it reaches the stabilization point, it is easier to forecast
the future completion dates.
• In the case below, the velocity for iteration #1 is 12, iteration #2 is 13 and
so on.
Iteration #1 #2 #3 #4 #5 #6 #7 #8
Points 12 13 16 20 24 25 26 26
13
Public
13
THANK YOU.
Public
14
Public 7
5/7/2021
IT
ProjecT
managemenT
Public
Enhancing Team
Performance:
Establishing Cross-Functional Teams,
Empowering Teams to Self-Organize and
Nurturing High-Performance Teams
Public
Public 1
5/7/2021
Overview
“Individuals and interactions over processes and tools” by
studying how teams are organized, motivated and makes
decisions.
• This section also divulge into building self-organizing teams

and tracking team performance.
Public
Building Self-Organizing Teams

• After the world war II, management paradigm started changing from the top-down
scientific model (“Taylorism”) to more humanistic approach where the workers had
more input into decisions; this change started with the Japanese management
approach guided by Deming and others.
• Agile teams advocate for small teams of generalizing specialists; that is, team members
are highly flexible and adaptive who can fulfill cross-functional roles.
• Teams will have a shard common purpose and also will hold each other accountable for
the outcome of the project. That is, team is either successful or failed!
Public
Public 2
5/7/2021
Team Development Models

• Shu-Ha-Ri Model
• Dreyfus Model
• Tuckman Model
Public
Shu-Ha-Ri Model
• Alistair Cockburn conceived this three-step skill mastery process
Ri
Ha
Shu
Shu: Obey the rules
6 Ha: Consciously move away from the rules
Ri: Unconsciously find an individual path
Public
Public 3
5/7/2021
Dreyfus Model
• Stuart E. Dreyfus hypothesized that adults learn new skills over five stages.
Expert
Proficient
Competent
Advanced Beginner
Novice
Public
Tuckman Model
• Bruce Tuckman originated the team formation and development model.
Adjourning
Performing
Norming
Storming
Forming
Public
Public 4
5/7/2021
Leadership Styles
Delegating
Directing
Supporting
Coaching
Public
Coaching Guidelines
• Lyssa Adkins provided some expert advise on how to perform one-on-one

coaching:
• Meet them a half-step ahead

• Guarantee safety
• Partner with managers
• Create positive regard
10
Public
10
Public 5
5/7/2021
Team Performance
Burndown Chart
11
Public
11
Team Performance
Burn-up Chart

12
Public
12
Public 6
5/7/2021
Velocity
• Velocity is a common way of measuring progress within agile projects.
• It usually represents how many points were completed within one

iteration.
• Usually the velocity increases iteration after iteration and then stabilizes at
some point; once it reaches the stabilization point, it is easier to forecast
the future completion dates.
• In the case below, the velocity for iteration #1 is 12, iteration #2 is 13 and
so on.
Iteration #1 #2 #3 #4 #5 #6 #7 #8
Points 12 13 16 20 24 25 26 26
13
Public
13
THANK YOU.
Public
14
Public 7
7/7/2021
IT
ProjecT
managemenT
Public
Facilitating Adaptive
Planning:
Producing and Maintaining an Empirical Plan
Public
Public 1
7/7/2021
Overview
• This module details the planning for agile projects,
acknowledging that this is an on-going endeavor
throughout the life cycle of the project.
• Agile planning concepts, requirement decomposition,

estimation, iteration and release planning will be covered
herewith.
Public
Agile Planning Concepts

• Adaptive planning takes place at multiple levels (strategic, release, iteration, daily)
creating appropriate detail by using rolling wave planning and progressive elaboration
to balance predictability of outcomes with ability to exploit opportunities.
• Rolling wave planning is a form of progressive planning activity where the team plans
for one wave in order to execute with the understanding that the next wave should be
clearer once this wave is completed.
• Strategic plans do not change frequently and drives towards organizational objectives,
but still be nimble enough to adapt to change in the external eco-system for
unexpected events such as a COVID-19 pandemic.
• Release plans are usually stable and do not undergo repeated changes, but any
progression on the completion of the requirements or changes in the internal or
external environment can necessitate changes in the release plan.
• Iteration plans are more fluid and daily plans are often extremely dynamic.
4
Public
Public 2
7/7/2021
Defining Production Vision & Roadmap

Product Vision
Themes Themes Themes
Features Features Features
Epics Epics Epics
5
User Stories User Stories User Stories
Public
Production Vision & Roadmap - Simplified
Product Vision
Epics Epics Epics
User Stories User Stories User Stories
Public
Public 3
7/7/2021

Product Vision
For XYZ Bank Customers who want access to online banking capability while on the go, the MyXYZ mobile
banking application by XYZ Bank is a mobile application that can be downloaded and used on smart phones and
tablets that allows bank customers to conduct secure, on-demand banking 24 hours a day. Unlike traditional
banking at branch or online banking from your home or office computer, our product allows users immediate 24
hour access to their financial accounts wherever they have mobile carrier service.
Themes Themes Themes

Transactions Account Information Customer Service Functions
Features Features Features Features

See a List of Recent See my Upcoming Automatic
See Account Balance See a List of Recent Deposits
Withdrawals Bill Payment
Epics Epics Epics

See Saving Account See Checking Account See Investment Account
Balances Balances Balances
User Stories
• Log into mobile account
• See a list of my accounts
• Select and view my checking account
• See account balance changes after withdrawal
• See account balance changes after purchases
• See available account balance
7 • See mobile application navigation items
• Change account view
• Log out of mobile application
Internal
Public
Product Vision
For XYZ Bank Customers who want access to online banking capability while on the go, the MyXYZ mobile
banking application by XYZ Bank is a mobile application that can be downloaded and used on smart phones and
tablets that allows bank customers to conduct secure, on-demand banking 24 hours a day. Unlike traditional
banking at branch or online banking from your home or office computer, our product allows users immediate 24
hour access to their financial accounts wherever they have mobile carrier service.
Epics Epics Epics

See Saving Account See Checking Account See Investment Account
Balances Balances Balances
User Stories User Stories

• Log into mobile account • Log into mobile account
• See a list of my accounts • See a list of my accounts
• Select and view my savings account • Select and view my checking account
• See account balance changes after withdrawal • See account balance changes after withdrawal
• See account balance changes after purchases • See account balance changes after purchases
• See available account balance • See available account balance
• See mobile application navigation items • See mobile application navigation items
• Change account view • Change account view
• Log out of mobile application • Log out of mobile application
User Stories
8 • Log into mobile account
• See a list of my investment accounts
• Log out of mobile application
Internal
Public
Public 4
7/7/2021
Developing Product Vision

• Key Product Goals: How will this product benefit the company
that is creating it?
• Customer: Who will use this product?
• Need: Why does the customer need the product? What features
are critical to the customer?
• Competition: How does this product compare with similar

products?
• Primary Differentiation: What makes this product different than

the current state or the competition?
Public
Developing Product Vision

Vision Statement for Product
For: (Target Customer)

who: (needs)
the: (product name)
is a: (product category)
that: (Product benefit, reason to buy)
unlike: (competitors)
our product: (differentiator / value proposition)
Example:
For XYZ Bank Customers who want access to online banking capability
while on the go, the MyXYZ mobile banking application by XYZ Bank is a
mobile application that can be downloaded and used on smart phones
and tablets that allows bank customers to conduct secure, on-demand
banking 24 hours a day. Unlike traditional banking at branch or online
banking from your home or office computer, our product allows users
immediate 24 hour access to their financial accounts wherever they have
10 mobile carrier service.
Public
Public 5
7/7/2021
Creating a User Story

• A user story is a simple description of a product requirement
in terms of what that requirement must accomplish and for
whom.
• Components of a user story:
– Title: <a name for user story>

– As a <user or a persona>
– I want to <take this action>
– So that <I get this result>
• Validation of a user story:

• When I <take this action>, this happens <description of
action>
11
Public
Creating a User Story - Example
Title: See bank account balance
As a busy, tech savvy, on-the-go customer of XYZ bank (Jason)
I want to see my checking account balance on my smartphone
So that I can see how much money I have in my checking account
Validation:
When I sign into the XYZ Bank mobile application, my checking

account balance appears at the top of the page.
When I sign into the XYZ Bank mobile application after making a
purchase or a deposit, my checking account balance reflects that
12 purchase or deposit.
Public
Public 6
7/7/2021
Decomposing a Requirement
Theme: See Account Data with a Mobile Application
Features:
• See account balances
• See a list of recent withdrawals or purchases
• See a list of recent deposits
• See my upcoming automatic bill payment
• See my account alerts
13
Public
Decomposing a Epic User Story
Epic: See Account Balances
Features:
• See checking account balances
• See savings account balances
• See investment account balances
• See retirement account balances
14
Public
Public 7
7/7/2021
Decomposing a User Story
User Story: See Checking Account Balance
Features:
• Log into mobile account
• Securely log into mobile account
• See a list of my accounts
• Select and view my checking account
• See account balance changes after withdrawals
• See account balance changes after purchases
• See day’s end account balances
15
Public
THANK YOU.
Public
Public 8
11/9/2020
IT
ProjecT
managemenT
Public
Problem Detection &

Resolution:
Continuous Recognition & Response to Risk,
Monitoring & Controlling through Burn-down
Charts
Public
Public 1
11/9/2020
Overview
• Information technology project professionals should be
always vigilant of any threats that prevents from adding
value and be well versed with tools, techniques and
developing a culture of transparency which can lead to
detection of risks effectively.
• In addition, an IT Project Manager or a Scrum Master

should have in-depth understanding of various quality
assurance processes and methodologies in practice.
Public
Cost of Change
• There is significant impact on time to market and the cost of delivery, when
issues are not identified as early as possible.
• When issues are identified, project lags from the baseline schedule due to
the effort for detection, analysis and fix.
• In addition, the cost of fix also increases as we uncover issues at later
stages of the project.
Public
Public 2
11/9/2020
Agile Vs. Traditional Methods
Public
Technical Debt
• A term originally used by Ward Cunningham, one of the 17 signatories of the agile
manifesto. He used it as a metaphor to illustrate rushing a software application to
release without coding best practices are applied throughout the system is like
using the borrowed money to do something sooner and then you need to pay the
debt with the interest.
• Technical debt is the backlog of work that needs to be refactored at a later stage
and hence the project team needs to make sure that every project is budgeted
and scheduled for handling this technical debt.
Public
Public 3
11/9/2020
Definition of Project Quality
• “the degree to which a set of inherent characteristics fulfill

requirements”
– ISO9000: 2000
• Conformance to requirements: to which level of deviation does a

product, service of process meet the required baseline specification.
• Fitness to use: Can a product or service be used as it was intended.
Public
Quality Vs Grade
• Low quality is always a problem, but low grade cannot necessarily
deemed as a problem.
• Example: If you are buying a car with basic features and did not buy any
upgrade package and the car drives with no issues, it is deemed to be
high quality, but low grade; however, if you buy a luxury car with all
upgraded features, but the car has number of defects and does not work
as stated by the original specification, the car is low quality, but higher
grade.
• Example: Software products work the same way; you could purchase a
software with limited functions, but the software performs those functions
with no issues and comes with good user documentation, it can be
considered as a high quality software; where as, if you purchase a
software with a large number of features, but continuously “crashes”, it is
a low quality, high grade software product.
8
Public
Public 4
11/9/2020
Components of Quality Management
• User satisfaction
• Prevention versus correction
• Continuous improvement
• Management commitment
Public
Quality Management Processes
Performing
Planning Quality Performing
Quality
Measurements Quality Control
Assurance
• Identifying which • Periodically • Monitoring
quality standards evaluating specific project
are relevant to the overall project results to ensure
project and how to performance to that they comply
satisfy them; a ensure the with the relevant
metric is a project will quality standards.
standard of satisfy the
measurement. relevant quality
standards.
10
Public
10
Public 5
11/9/2020
Project Quality Management Summary
11
Reproduced from: Schwalbe, K. (2016). Information technology Project Management (8th ed.). Boston, MA: Course
Technology/Cengage Learning.
Public
11
Planning Quality
• User Requirements
• Functional Requirements
• Technical Requirements
• Acceptance Criteria
• Quality Metrics
• Quality Checklist
12
Public
12
Public 6
11/9/2020
Is Requirements Important?
13
Public
13
Project Life Cycle Artifacts
Develop
Code
Convert into
Technical
Requirements
Test (QA)
Gather Business
Requirements Create Test
Case Matrix
14
Public
14
Public 7
11/9/2020
Scope Aspects of IT Projects

• Functionality
• Features
• System Outputs
• Performance
• Reliability
• Maintainability
15
Public
15
Performing Quality Assurance
• Benchmarking: comparison of specific project practices or product /

service characteristics to those of other projects or industry standards.
• Quality Audit: structured review of specific quality management activities

that help identify lessons learned that could improve performance on
current or future projects.
16
Public
16
Public 8
11/9/2020
Controlling Quality
• Output of this process:
– Acceptance decisions
– Rework
– Process adjustments
• Tools used for quality control:

– Cause & effect diagrams
– Quality control charts
– The seven-run rule
– Checksheet
– Scatter diagram
– Histograms
– Pareto charts
– Flow charts
– Run charts
17
Public
17
Testing – Life Cycle
18
Reproduced from: Schwalbe, K. (2016). Information technology Project Management (8th ed.). Boston, MA: Course Technology/Cengage
Learning. Public
18
Public 9
11/9/2020
Testing – Artifacts
Scope
Business
Requirements
Technical
Requirements
Test Plan / Strategy
Test Case Matrix
Unit Testing
Integration Testing
Systems Testing
User Acceptance
Testing
Production
Acceptance Testing
19
Public
19
The Cost of Quality

• The cost of quality is the cost of conformance plus the cost of
nonconformance:
– Conformance: delivering products or services that meet
requirements and fitness for use.
– Cost of nonconformance: taking responsibility for failures or not
meeting quality expectations.
20 Cost of fixing software defects graph - Google Search. (n.d.). Retrieved January 11, 2016, from https://www.google.ca/search?q=cost of fixing
software defects
graph&biw=1420&bih=724&tbm=isch&imgil=tI5RQYGN5naDNM%3A%3BcpMY07MBFrbO9M%3Bhttp%253A%252F%252Fwww.seguetech.com%25
2Fblog%252F2014%252F03%252F31%252Frising-cost-defects-2&
Public
20
Public 10
11/9/2020
Traditional Vs. Agile Quality
Traditional (Waterfall) Agile

Testing is the last phase of the Testing is a daily part of each sprint
project. and is usually included in each
requirement’s definition of “done”.
Problems (‘bugs’) are difficult to find Problems (‘bugs’) are easier to find
at the end of the project and fixes with smaller amount of work and the
are costly. fixes are easier to deal with a
requirements that you just created
versus created months earlier.
Sunk costs are higher when tested Sunk costs can be lower as you can
at the end of the project. test high risk features at earlier
sprints.
Sometimes, due to schedule or Testing is assured as they are part
budget constraints, teams cut the of every sprint.
testing phase short.
21
Public
21
Quality in Agile - Sprints

Requirements
Design
Test Test
Integrate Develop
Test
22
Review & Retrospective
Public
22
Public 11
11/9/2020
Agile Quality Deployment Techniques

Test-driven development (TDD): It is a development technique where the developer
begins with creating test case for the requirement and proceed with the development
effort; the development continues till the test case passes.
Pair Programming: It is a development technique where two “developers” work together

from the same workstation. One of them will be the primary developer and the other will
be an observer to review the code. The two participants switches the roles at regular
frequency.
Peer Reviews: Peer code review is a technique where members of the development team
reviews one another's code.
Continuous Integration: The practice of creating integrated code builds one or more
times each day. Continuous integration allows members of the development team to
check how the user story the development team is creating works with the rest of the
product.
23
Public
23
Types of Testing
Unit Testing: Testing individual units, or the smallest parts, of the product code.
Regression Testing: Tests an entire product start to finish, including requirements you have tested
previously.
User Acceptance Testing: Product stakeholders or even some of the product’s end users review a
product and accept it as complete.
Functional Testing: Tests to make sure the product works according to acceptable criteria from the
user story.
Integration Testing: Tests to make sure the product works with other products, as necessary.
Performance Testing: Tests how fast a product runs on a given system under different scenarios.
Smoke Testing: Tests on small but critical parts of code or of a systems to help determine if the
system as a whole is likely to work.
Static Testing: Focuses on checking code standards, rather than working software.
24
Public
24
Public 12
11/9/2020
Test Case Matrix & Traceability

Test Business Test Case Test Steps Test Data Expected Results Pass /
Case # Req. # Fail
25
Public
25
If Cars were Developed like Software?

• At the COMDEX computer exposition, Bill Gates, the founder and CEO of
Microsoft Corporation, stated: “If General Motors had kept up with
technology like the computer industry has, we would all be driving $25
cars that got 1,000 miles to the gallon.” In response to Gates’ comments,
General Motors issued a press release stating: “If GM had developed
technology like Microsoft, we would be driving cars with the following
characteristics:
– For no reason whatsoever your car would crash twice a day.
– Every time they repainted the lines on the road, you would have to
buy a new car.
– Macintosh would make a car that was powered by the sun, reliable,
five times as fast, and twice as easy to drive, but would run only five
percent of the roads.
– New seats would force everyone to have the same size hips.
– The airbag system would say “Are you sure?” before going off.
– Occasionally, for no reason whatsoever, your car would lock you out
and refuse to let you in until you simultaneously lifted the door
handle, turned the key, and grabbed hold of the radio antenna.
26
Public
26
Public 13
11/9/2020
THANK YOU.
Public
27
Public 14
5/7/2021
IT
ProjecT
managemenT
Public
Enabling Continuous
Improvement:
Assessing Organization Culture, Tailoring
Process, Removing Non-Value Add Work &
Developing Maturing Assessment Models
Public
Public 1
5/7/2021
Overview
• Continuous improvement is deeply rooted within the
culture of an organization and agile teams enables the
practice through short learning cycles compared to the
traditional project teams.
• People, processes and tools are key factors that aids the
continuous improvement practices and mindset within any
organization.
Public
Kaizen
‘Kai’ - Change ‘zen’ - Good
Change for the better

4
Public
Public 2
5/7/2021
Kaizen
• Agile practices use the Kaizen approach for continuous improvement by utilizing
learning cycles in small increments after every iteration.
• Unlike the top-down management driven large transformational changes

undertaken in the western world, Kaizen expounds the people who are doing
the work to initiate (or suggest) small increment changes, but frequently.
• Since the changes are small and do not incur large capital investment, if the
experiment does not work, they can be reverted without incurring large costs.
• Agile practices are based on “empirical process theory”, which is making

changes based on fact-based, experience-based and evidence-based manner.
That is, one truly verifies if a process is working only when it is being used
(experimented).
Public
Kaizen
• Kaizen is based on PDCA cycle developed by W. Edwards Deming.
• Agile practices use ‘retrospectives’ to promote continuous improvement.
Learn Plan
6 Evaluate Develop
Public
Public 3
5/7/2021
Continuous Improvement in Agile Practices

• Pair Programming
• Daily Stand-up
• Demo, review, retrospectives
• Product Release
Public
Process Improvement
• Process improvement need can be triggered through retrospectives or process
tailoring activities.
• Analytical tools can be employed to evaluate processes and employ any

improvement strategies:
• Systems thinking
• Process analysis
• Value Stream mapping
Public
Public 4
5/7/2021
Definitions of Systems Thinking
• Merriam - Webster Dictionary: a system (not systems thinking!) is defined as a

regularly interacting or interdependent group of items forming a unified whole.
• Barry Richmond (the originator of the systems thinking term): the art and
science of making reliable inferences about behavior by developing an
increasingly deep understanding of underlying structure.
• Peter Senge (leader in the field / MIT): discipline for seeing wholes and a
framework for seeing interrelationships rather than things, for seeing patterns of
change rather than static snapshot.
• Sweeney & Sterman (authors & researchers): involves the ability to represent
and assess dynamic complexity (e.g., behavior that arises from the interaction
of a system’s agents over time), both textually and graphically.
• Kopainsky, Alessi & Davidsen: systems thinking should include appreciation for
long term planning, feedback loops, non-linear relationships between variables,
and collaborative planning across areas of an organization.
Public
Can you see a pattern…

• Slumber
• Pillow
• Dream
• Night
• Bed
• Blanket
• Quiet
• Pajamas
• Nap
• Snooze
10
Public
10
Public 5
5/7/2021
Characteristics of Systems Thinking
1. Recognizing Interconnections
2. Identifying Feedback
3. Understanding Dynamic Behavior
4. Differentiating types of flows and variables
5. Using Conceptual Models
6. Creating Simulation Models
7. Testing Policies
11
This Photo by Unknown Author is licensed under CC BY-SA-NC
Public
11
Operation Cat Drop
• https://www.youtube.com/watch?v=17BP9n6g1F0
12
Public
12
Public 6
5/7/2021
Causal Loop Diagrams

• Causal Loop Diagram provides an overview on how one element of the
system effects the rest of the system.
• It is a visual representation that enables the understanding of how

different elements interact with each other in a system.
• Causal Loop Diagrams are useful to illustrate and understand complex

systems; examine the details of the interaction of various elements and
can be a tool of education for those who are unfamiliar with the system.
• It may become too complex to illustrate every element that interacts with
the system; so it is only represents the broadest view of the system.
• Types of loops:
– Reinforcement Loops (R)
– Balancing Loops (B)
13
Public
13
Draw your Systems Diagram
14
Public
14
Public 7
5/7/2021
Process Analysis
• At regular intervals, processes used by the agile teams must be reviewed to
identify and inefficiencies or risks of providing value with quality.
• Alistair Cockburn, one of the signatories of the agile manifesto published a list of
attributes that can identify shortcomings in the process:
• One size for all projects

• Intolerant
• Heavy
• Embellished
• Untried
• Used once
15
Public
15
Process Analysis – Effective Processes

• Alistair Cockburn also published a list of successful methodologies:
• Interactive, face-to-face communication in the cheapest and fastest

channel for exchanging information.
• Excess methodology weight is costly.
• Larger teams need heavier methodologies.
• Projects with greater criticality require greater ceremony.
• Feedback and communication reduce the need for intermediate deliveries.
• Discipline, skills, and understanding counter process, formality, and

documentation.
• Efficiency is expendable in non- bottleneck activities.

16
Public
16
Public 8
5/7/2021
Value Steam Mapping

• Value Steam Mapping (VSM) is a lean technique used to analyze the flow of
material and information through the system and to identify and eliminate
waste.
• A way to analyze a chain of processes with the goal of eliminating waste. It is

intended to give the analyst a deeper understanding of the system by mapping
it out.
About 30 years back, American

Airlines saved $40,000 by removing
one olive from each salad plate!
17 This Photo by Unknown Author is licensed under CC BY-

SA
Public
17
Value Stream
• Value Steam can be considered as all the activities required to transform a
customer request into a good or service.
VALUE STREAM
Process Process Process
Customer Customer
Request Receipt
18
This Photo by Unknown Author is licensed under CC BY-NC
Public
18
Public 9
5/7/2021
Value Steam Mapping - Example

Current State
Barista Call out

Latte Order Cups placed First Sip
making the customer
Selection Counter in Queue 
Latte name
2 min 0.5 min

1 min 0.5 min
VA
NVA
5 min 6 min 1 min
Value-added time (VA): 1min + 0.5min + 2 mins + 0.5 min = 4 mins

Nonvalue-added time (NVA): 5mins + 6 mins + 1 min = 12 mins
Total Cycle time: 4mins + 12mins = 16mins
Process Cycle Efficiency: 4mins / 16mins = 25%

19
Public
19
Value Steam Mapping - Example

Future State
Barista Latte Placed

Online Latte Order placed First Sip
making the with Name
Selection in Queue 
Latte Tags
1 min 2 min 0.5 min

VA
NVA
6 min 0.5 min
Value-added time (VA): 1min + 2 mins + 0.5 min = 3.5 mins

Nonvalue-added time (NVA): 6 mins + 0.5 min = 6.5 mins
Total Cycle time: 3.5mins + 6.5mins = 10mins
Process Cycle Efficiency: 3.5mins / 10mins = 35%

20
Public
20
Public 10
5/7/2021
Team Self-Assessment Scoring Model

• James Shore developed an assessment technique based on the XP practices,
which the team can use to measure their performance.
21
Public
21
THANK YOU.
Public
22
Public 11
5/7/2021
IT
ProjecT
managemenT
Public
Enterprise-wide Scaling
of Agile:
Scrum of Scrums, Less, DAD & SAFe®
Public
Public 1
5/7/2021
Overview
• Current agile practices are primarily applied to projects that are referred to be in
the “sweet spot”:
– Collocated teams
– Non-critical
– Green field
– In-house software development
– Stable architecture
– Simple governance rules
• Applying agile into large organizations with multiple teams is a new phenomenon,
where the organizations are still struggling to integrate the agile practices to multi-
functional teams.
Public
What is the Problem?
4
Source: Knaster, R., & Leffingwell, D. (2017). SAFe distilled: Applying the Scaled Agile Framework® for lean software and systems engineering: SAFe 4.0. Boston:
Addison-Wesley.
Public
Public 2
5/7/2021
“Every company is a technology company, no

matter what product or service it provides. The
companies that embrace this fact are the ones
that shape our world”
- Stepenie Stone, CIO, Americas at M+W Group
Public
Recent Research
• World Economic Forum has identified agile governance as one of the critical
component for success in the fourth industrial revolution as emerging
technologies create uncomfortable pace of change (How Governance Is
Changing in the 4IR, 2018).
• COVID-19 has proved to most nations around the world that traditional
supply chains and manufacturing ecosystems are failing, and we need to
shift to a more adaptable, agile solution that is fully digitally enabled (Evans,
2020); this again points us to agile governance to survive and thrive in the
post-COVID world.
Evans, D. (2020, May 19). Post COVID-19, The Answer Is Digital Transformation, Now What’s The Question? Forbes.
https://www.forbes.com/sites/daveevans/2020/05/19/post-covid-19-the-answer-is-digital-transformation-now-whats-the-question/
How governance is changing in the 4IR. (2018). World Economic Forum. https://www.weforum.org/agenda/2018/01/agile-governance-changing-4ir-
6public-private-emerging-technologies/
Public
Public 3
5/7/2021
Remember these Guys?
Kodak
Blackberry
7 Compaq
Public
Scaled Agile Practices
Public
Public 4
5/7/2021
Five Core Competency of the Lean Enterprises
1. Lean-Agile Leadership
2. Team and Technical Agility
3. DevOps and Release on Demand
4. Business Solutions and Lean Systems Engineering
5. Lean Portfolio Management
Source: Knaster, R., & Leffingwell, D. (2017). SAFe distilled: Applying the Scaled Agile Framework® for lean software and systems engineering: SAFe 4.0. Boston:
Addison-Wesley.
Public
Full SAFe® Configuration
Source: Knaster, R., & Leffingwell, D. (2017). SAFe distilled: Applying the Scaled Agile Framework® for lean software and systems engineering: SAFe 4.0. Boston: Addison-Wesley.
10
Public
10
Public 5
5/7/2021
What is SAFe®
• Scaled Agile Framework is a set of organizational best practices and processes that
enables enterprise-wide enablement of lean and agile practices.
• These practices promotes alignment, collaborative communication and consistent
delivery amongst multiple agile teams.
• SAFe® Principles
– Take an economic view
– Apply systems thinking
– Assume variability; preserve options
– Build incrementally with fast, integrated learning cycles
– Base milestones on objective evaluation of working systems
– Visualize and limit WIP, reduce batch sizes, and manage queue lengths
– Apply cadence, synchronize with cross-domain planning
– Unlock the intrinsic motivation of knowledge workers
– Decentralize decision-making
• Reference: SAFe Principles. (n.d.). Retrieved December 5, 2019, from https://www.scaledagileframework.com/safe-lean-agile-principles/.
11
Public
11
SAFe® Principles
- Safe® is developed based on proven best practices, but it recognizes that some tailoring or
customization may be required to fit to the organization.
- SAFe® improves employee engagement, time-to-market, solution quality, and team productivity.
12
Public
12
Public 6
5/7/2021
Trends of the Future

• In my view…
– Leading with empathy & morality
– Understanding the interconnectivity of the eco-system
– Ability to mobilize the “wisdom of mass”
– Guts to “test the water”
– Program & Portfolio Management
– Understand the technology & question “how can I use it?”
13
Public
13
THANK YOU.
Public
14
Public 7

The Scrum Guide: Ken Schwaber & Jeff Sutherland

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Scrum Guide: Ken Schwaber & Jeff Sutherland

Uploaded by

Copyright:

Available Formats

Ken Schwaber & Jeff Sutherland

The Scrum Guide

Ken Schwaber & Jeff Sutherland November 2020

© 2020 Ken Schwaber and Jeff Sutherland

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

● Creating a plan for the Sprint, the Sprint Backlog;

● Developing and explicitly communicating the Product Goal;

● Coaching the team members in self-management and cross-functionality;

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

● Leading, training, and coaching the organization in its Scrum adoption;

During the Sprint:

● No changes are made that would endanger the Sprint Goal;

Sprint Planning addresses the following topics:

Topic One: Why is this Sprint valuable?

Topic Two: What can be Done this Sprint?

Topic Three: How will the chosen work get done?

● For the Product Backlog it is the Product Goal.

Commitment: Product Goal

Commitment: Sprint Goal

Commitment: Definition of Done

Scrum Guide History

© 2020 Ken Schwaber and Jeff Sutherland

Project Management Framework

What Helps Projects to Succeed?1

1. The Standish Group, “CHAOS Activity News” (August 2011).

What the Winners Do?

Project, Program & Portfolio Management

Functional Project Matrix

Sample Organization Structures

Team Diversity in IT Projects

• IT project managers must develop the skills to work with:

• An overview of various project life cycles and their

• Concept of Systems Thinking and its applicability to IT

What is Systems Development Methodology?

System Development Life Cycle (SDLC) Phases

Planning & Requirements Design

This document is marked Confidential

This document is marked Confidential

This document is marked Confidential

Project Life Cycles

 Predictive Life Cycle

This document is marked Confidential

Predictive Life Cycle (Waterfall)

This document is marked Confidential

System Integration Test

Client Acceptance Test

Delivery & Maintenance

Requirements Gathering (Waterfall)

 Specifies something that the system can do

Requirements Gathering (Waterfall)

Iterative Life Cycle

This document is marked Confidential

Incremental Life Cycle

Adaptive Life Cycle

Hybrid Life Cycle

Definitions of Systems Thinking

• Merriam - Webster Dictionary: a system (not systems thinking!) is defined as a

Can you see a pattern…

Characteristics of Systems Thinking

Operation Cat Drop

Causal Loop Diagrams

• It is a visual representation that enables the understanding of how

• Causal Loop Diagrams are useful to illustrate and understand complex