The Scrum Guide: Ken Schwaber & Jeff Sutherland
The Scrum Guide: Ken Schwaber & Jeff Sutherland
The Scrum Guide: Ken Schwaber & Jeff Sutherland
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.
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.
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:
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:
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:
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.
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.
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.
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.
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:
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.
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.
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.
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.
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).
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
16
Public
Public 8
9/8/2021
17
Public
18
Public
Public 9
9/8/2021
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
20
Public
Public 10
9/8/2021
21
Public
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.
Public
• “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
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
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
Public 4
9/21/2020
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
10
Public 5
9/21/2020
11
Public
11
• 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
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
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.
This document is marked Confidential
14
Public 7
9/21/2020
15
Public
15
16
Public
16
Public 8
9/21/2020
17
Public
17
• Night
• Bed
• Blanket
• Quiet
• Pajamas
• Nap
• Snooze
18
Public
18
Public 9
9/21/2020
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
• https://www.youtube.com/watch?v=17BP9n6g1F0
20
Public
20
Public 10
9/21/2020
• 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
22
Public
22
Public 11
9/21/2020
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.
24
Public
24
Public 12
9/28/2020
Module Overview
Public
• 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 principles are 12 practices that help support the values in the Agile Manifesto.
Public
Public 2
9/28/2020
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
Public
Public 3
9/28/2020
• Transparency: constant interaction with all stakeholders enables all parties to be well
aware of the progress of the project at any one time.
• 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
Public
Public 4
9/28/2020
Public
Agile Environment
• Physical environment
– Collocating the team
– Setting up a dedicated area
– Removing distractions
– Going mobile
• High-Tech Communication
– Video conferencing and webcam
– Instant messaging
– Web-based desktop sharing
– Collaboration websites
10
Public
10
Public 5
9/28/2020
11
Public
11
Agile Behaviors
• Establishing Agile Roles
– Development team
– Product owner
– Scrum master
– Stakeholders
– Agile mentor
Public
12
Public 6
9/28/2020
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
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”.
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
Value-Driven Delivery
Agile
Business Value
Traditional
Time
Public
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)
Public
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
Public
• Rate of Progress
• Remaining Work
10
Public
10
Public 5
5/7/2021
• Anything that can potentially reduce value delivery can be considered as a risk.
Perform
Monitor Qualitative
Risks Risk
Analysis
Implement
Plan Risk
Risk
Response
Responses
11
Public
11
Prioritizing Value
• Customer-Valued Prioritization
• Scrum – backlog
Which
• FDD – feature list feature do
• DSDM – requirements list you want to
do next?
12
This Photo by Unknown Author is licensed under CC BY-NC-ND
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
• Kano Analysis
13
This Photo by Unknown Author is licensed under CC BY-SA
Public
13
• 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
15
• 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
L=λ*W
L = Work in Progress
λ = Customer Demand Rate
W= Lead Time
Finished
Raw
Goods
Material
18
This Photo by Unknown Author is licensed under CC BY
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).
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
• 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”.
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
Value-Driven Delivery
Agile
Business Value
Traditional
Time
Public
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)
Public
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
Public
• Rate of Progress
• Remaining Work
10
Public
10
Public 5
5/7/2021
• Anything that can potentially reduce value delivery can be considered as a risk.
Perform
Monitor Qualitative
Risks Risk
Analysis
Implement
Plan Risk
Risk
Response
Responses
11
Public
11
Prioritizing Value
• Customer-Valued Prioritization
• Scrum – backlog
Which
• FDD – feature list feature do
• DSDM – requirements list you want to
do next?
12
This Photo by Unknown Author is licensed under CC BY-NC-ND
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
• Kano Analysis
13
This Photo by Unknown Author is licensed under CC BY-SA
Public
13
• 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
15
• 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
L=λ*W
L = Work in Progress
λ = Customer Demand Rate
W= Lead Time
Finished
Raw
Goods
Material
18
This Photo by Unknown Author is licensed under CC BY
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).
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
• This module explores one of the agile manifesto values,
“Individuals and interactions over processes and tools” by
studying how teams are organized, motivated and makes
decisions.
Public
• 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
• Dreyfus Model
• Tuckman Model
Public
Shu-Ha-Ri Model
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
Adjourning
Performing
Norming
Storming
Forming
Public
Public 4
5/7/2021
Leadership Styles
Delegating
Directing
Supporting
Coaching
Public
Coaching Guidelines
10
Public
10
Public 5
5/7/2021
Team Performance
Burndown Chart
11
Public
11
Team Performance
Burn-up Chart
Public
12
Public 6
5/7/2021
Velocity
• Velocity is a common way of measuring progress within agile projects.
• 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
• This module explores one of the agile manifesto values,
“Individuals and interactions over processes and tools” by
studying how teams are organized, motivated and makes
decisions.
Public
• 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
• Dreyfus Model
• Tuckman Model
Public
Shu-Ha-Ri Model
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
Adjourning
Performing
Norming
Storming
Forming
Public
Public 4
5/7/2021
Leadership Styles
Delegating
Directing
Supporting
Coaching
Public
Coaching Guidelines
10
Public
10
Public 5
5/7/2021
Team Performance
Burndown Chart
11
Public
11
Team Performance
Burn-up Chart
Public
12
Public 6
5/7/2021
Velocity
• Velocity is a common way of measuring progress within agile projects.
• 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.
Public
• 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
5
User Stories User Stories User Stories
Public
Product Vision
Public
Public 3
7/7/2021
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.
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
• Need: Why does the customer need the product? What features
are critical to the customer?
Public
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
11
Public
Validation:
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
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
Features:
• See checking account balances
• See savings account balances
• See investment account balances
• See retirement account balances
14
Public
Public 7
7/7/2021
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
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.
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
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
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
• User satisfaction
• Continuous improvement
• Management commitment
Public
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
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
Develop
Code
Convert into
Technical
Requirements
Test (QA)
Gather Business
Requirements Create Test
Case Matrix
14
Public
14
Public 7
11/9/2020
• Features
• System Outputs
• Performance
• Reliability
• Maintainability
15
Public
15
16
Public
16
Public 8
11/9/2020
Controlling Quality
• Output of this process:
– Acceptance decisions
– Rework
– Process adjustments
Public
17
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
Unit Testing
Integration Testing
Systems Testing
User Acceptance
Testing
Production
Acceptance Testing
19
Public
19
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
21
Public
21
Design
Test Test
Integrate Develop
Test
22
Review & Retrospective
Public
22
Public 11
11/9/2020
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
25
Public
25
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
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.
• 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.
Public
Kaizen
• Kaizen is based on PDCA cycle developed by W. Edwards Deming.
Learn Plan
6 Evaluate Develop
Public
Public 3
5/7/2021
• Daily Stand-up
• Product Release
Public
Process Improvement
• Process improvement need can be triggered through retrospectives or process
tailoring activities.
Public
Public 4
5/7/2021
Public
• Night
• Bed
• Blanket
• Quiet
• Pajamas
• Nap
• Snooze
10
Public
10
Public 5
5/7/2021
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
• https://www.youtube.com/watch?v=17BP9n6g1F0
12
Public
12
Public 6
5/7/2021
• 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
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:
15
Public
15
Public
16
Public 8
5/7/2021
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
Customer Customer
Request Receipt
18
This Photo by Unknown Author is licensed under CC BY-NC
Public
18
Public 9
5/7/2021
NVA
5 min 6 min 1 min
Public
19
NVA
6 min 0.5 min
Public
20
Public 10
5/7/2021
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
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
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
Kodak
Blackberry
7 Compaq
Public
Public
Public 4
5/7/2021
1. Lean-Agile Leadership
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
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
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
13
Public
13
THANK YOU.
Public
14
Public 7