Course 2:

Project OKR’s, comparison with SMART goals

 Project-level OKRs help establish the appropriate scope for your team so that you can say
“no” to requests that may get in the way of them meeting their objectives
 Strong objectives are: Aspirational, Aligned with organizational goals, Action-oriented, Concrete
and Significant
 Strong key results are: Results-oriented—not a task, Measurable and verifiable, Specific and
time-bound, Aggressive yet realistic
 Think of your objectives as being motivational and inspiring and your key results as being
tactical and specific. The objective describes what you want to do and the key results describe
how you’ll know you did it.
 Difference between SMART goals and OKR’s: SMART goals are very specific and have
measurables either in the form of profitability metric or quality metric, whereas OKR’s are
more lose and inspirational allowing allocation of multiple key results to ensure alignment
with the overall goal
 OKR’s to be used: when destination is known, long term objectives etc.
 SMART goals to be used: When Destination is unknown

Project scope

 Defines boundaries for the project. (what is

included and excluded from a project)
 Who is it delivered to and who is the end user
of the deliverable
 Also includes: TIMELINE, RESOURCE,
BUDGET
Scope Creep: Scope creep is when a project’s work starts to grow beyond what was originally agreed
upon during the initiation phase.
How to avoid scope creeps:

 Define your project’s requirements.

 Set a clear project schedule
 Determine what is out of scope
 Provide alternatives
 Set up a change control process
 Learn how to say no
Triple constraint model to manage changes to the project scope (which element of the triangle matters the
most): both time and cost have to be efficiently managed alongside scope. You cant change one without
having a impact on the other.
Measuring a project’s success includes: launching (when the deliverable is ready and can be presented to
the client) and landing (measuring the project success against the predefined success criteria, defined in
the beginning)
Module 3:
How to choose a team:

 Required roles
 Team size
 Necessary skills
 Availability
 Motivation
How to run a stakeholder analysis

 Make a list of all stakeholders the project impacts

 Determine he level of interest and influence for each stakeholder
 Assess the ability of stakeholders to participate and then find ways to involve them


RACI Chart (Responsibility Assignment Matrix (RAM), RACI diagram, or RACI matrix): it helps to define
roles and responsibilities for individuals or teams to ensure work gets done efficiently
Four type of participations in the RACI chart: Responsible (doing the work), accountable (getting the
work done), consulted (those give feedback, SME or decision makers) and informed
Note: Accountability is always mapped to only one person to avoid conflict of ownership. However A
and R could be the same person
Why projects fail: Initiation missteps

 Unclear expectations
 Unrealistic expectations
 Miscommunication
 Lack of resources
 Scope creep
Module 4:
Essential Project Resources: Budget, people, material
Key Documents: Project proposal (only for early phase), project charter (referred throughout the PM
lifecycle)
Components of Project Charter:

 Project Goal
 Deliverables
 Business Case / Background
 Benefits, Costs, and Budget
 Scope and Exclusion
 Project Team
 Measuring Success
Project management tools to learn about:
important considerations and keys to successfully introducing new tools:

 Discuss the tool early and often, if possible

 Ask for feedback from key stakeholders
 Involve the key stakeholders in demonstrations as you get closer to making the final decision on
the project tracking tool.
 Ensure the tool is fully functional before the team is introduced to it.
 Set up training for the tool as needed before you ask the team to actually use it.
Some key type of tools:

Scheduling and work management software: (asana, Jira Software). Asana, Monday.com, Basecamp, and
Trello

Pro tip: Learn more by trying free tutorials or trial versions of popular project management
tools. By navigating project management software, you will be able to explain the uses and
functionality of these types of tools firsthand. Here are some examples to get started:

 Asana and Asana Guide

 Basecamp
 Trello
 Jira
 ClickUp
 Monday.com
 Microsoft Project or Project Libre (open source)
 Smartsheet (Demo)
Productivity & collaboration tools: online shared doc (google docs, Microsoft word), spreadsheets,
presentations, emails and chats
Common project management tools: (MUST be familiar with): asana, spreadsheets,

 Important template links:

Google Sheets template gallery
 Project Timeline
 Project Tracking
Gantt Chart
Event Marketing Timeline
Course 3:
Module 1:
Important components of the planning phase: Scheduling (start date, end date, in between), budgeting
(total cost for completing the project), risk management (identifying risk and formulating mitigation
strategies)
How should a planning lick off meeting look like:

To ensure the milestones and task are arranged in order of execution, WBS (work breakdown structure) is
used. Completion of WBS before making SOW also helps in smoothly calculating approximate budgets
Module 2:
Key components of project plan: Tasks, milestones, people (roles and task mapping for accountability),
documentation (RACI chart, Project charter, budget, risk management strategies), and time.
Other important components: schedule, scope and goals, WBS, budget, management plans
Planning includes: time estimation, effort estimation, capacity planning, keeping track of critical path.

Critical path: The critical path helps you determine the essential tasks that need to be completed on
your project to meet your end goal and how long each task will take

How to get accurate time estimation from team

 Asking the right questions

 Negotiating effectively
 Practicing empathy
Use GANTT CHARTS to make a project schedule
Some project plan templates:

 Smartsheet: Project Plan Templates for Microsoft Word

 Smartsheet: Project Plan Templates for Google Sheets

 Google Project Plan Timeline Template

 Microsoft Gantt Chart Template

Module 3:
Budgeting: break the budget down by milestones
Key components of a project budget: Resource cost rates, Reserve analysis, contingency budget, cost of
quality
To Do’s for budgeting: historical data, leverage experts, bottom-up, confirm accuracy, baseline.
As a standard practice, 5% of the overall budget cost is considered to be reserve cost (in google)
Budget management template:

Microsoft Excel Budget Templates

Microsoft Excel Website Budget Template

Google Sheets Budget Template

Best practices:

 When is a good time to review the project budget and identify if you need to make any
changes?: After you meet a milestone

 Be proactive with cost control strategies rather than being reactive

Challenges in budget allocation:

 Challenge 1: Budget pre-allocation

 Challenge 2: Inaccurately calculating TCO

 Challenge 3: Scope creep

Terms to remember:

 CAPEX (capital expenses) are an organization's major, long-term, upfront expenses, such
as buildings, equipment, and vehicles. They are generally for assets that the company will
own and keep. The company incurs these expenses because they believe they will create
a benefit for the company in the future.

 OPEX (operating expenses) are the short-term expenses that are required for the day-to-
day tasks involved in running the company, such as wages, rent, and utilities. They are
often recurring.

Difference between contingency and management reserves: Management reserves (5-10%) -

While contingency reserves are used to cover the costs of identified risks, management reserves
are used to cover the costs of unidentified risks. For example, if you were managing a
construction project and a meteor hit your machinery, you could use management reserves to
cover the costs of the damage.
Management reserves can be used only when project sponsor approves.

Procurement process: initiation (NDA)->selecting(RFP)->contract writing(SoW)->control-

>completing

the most common ethical traps that exist when conducting procurements are corruption and
bribery, sole-supplier sourcing, and interactions with state-owned agencies.

Module 4:

Risk- possibility of event that might occur which in turn can impact the project

Issue- occurrence of event that is considered as risk

Phases of Risk Management:

 Identify the risk.

 Analyze the risk.

 Evaluate the risk.

 Treat the risk.

 Monitor and control the risk.

Tools and techniques used to identify risks:

 Brainstorming (cause and effect diagram also known as a fishbone diagram)

 Make risk register that has list of identified risks

 Use probability and impact matrix to evaluate which risks should be prioritized

 Update the risk register with priorities

Key types of Risks:

 Time risk

 Budget risk

 Scope risk

 External risks (limited to no control- environmental, legal)

 Single point of failure (has potential to be catastrophic and halt work across the project)

 Dependency risk (internal (team mates) and external)

o Finish to start

o Finish to Finish

o Start to start

o Start to finish
Risk mitigation strategies:

 Avoid

 Minimize

 Transfer
  Accept

Components of risk management document:

 Author:

 Status: Draft/Final

 Date of creation

 Date of updating

 Objective

 Executive summary (also include risk register, with level of impact and mitigation
strategy

 Appendix with impact and probability matrix and others

Module 5:

Tips for effective communication

 Recognize and understand individual differences

 Brainstorm and craft the appropriate message

 Deliver your message

 Obtain feedback and incorporate that feedback going forward

Components of communication plan

 What needs to be communicated

 Who needs to communicate

 When communication needs to happen

 Why and how to communicate

 Where the info being communicated stored

Modes of information processing:

 Visuals

 Listening

 Reading and analysis

 Talking with others

Course 4:

Module 1:

Importance of tracking: increases transparency, risk management and keeping the project on
track

How to check project progress: tracking and measuring (to identify deviation)

Common items to track on a project:

 project schedule,

 status of action items, key tasks and activities

 progress towards milestones

 costs

 Key decisions, changes, dependencies and risks to the project

Various types of tracking methods: (Gantt chart, Roadmap, Burndown chart)

Gantt chart – measures task against time and includes useful information on who will own a task.
Useful when project has lot of dependencies, large project teams. Commonly used in waterfall
project management.
Roadmaps: suited for high level tracking of big milestones, useful for illustrating how a project
should evolve overtime
Burndown chart: measures time against the amount of work done and the amount of work
remaining. Best suited for projects that require detailed, broken down review of each task
associated with the project. Also when the projects top priority is to finish on time

Key components of a project status report: Project name, Date, Summary, Status, Milestones and
tasks, Issues.
Change Request Forms:
Additional techniques for managing risks

 Managing changes, scope creeps and dependencies.

 ROAM technique: resolved, owned, accepted and mitigated
Escalations by PM must be encouraged:
  Act as checks and balances
 Generate speedy decision making
 Reduce frustrations
 Encourage participation
Best practices for writing a escalation email. Maintain a friendly tone, state your connection to the
project, explain problem, propose course of action and make a request, putting it all together
Module 2: quality management
Quality management:

 Quality standards (set at the beginning)

 Quality planning (on how to satisfy the quality standards)
 Quality assurance (evaluating if project is moving towards high quality standards)
 Quality control (at delivery, if not alternative actions to be taken)
How to measure customer satisfaction:

 Feedback surveys and user acceptance test(UAT)

Continues improvement begins when process or tasks need to be created, eliminated or improved
Data driven improvement frameworks

 DMAIC (define, measure, analyze, improve, control)

 PDCA (identify problem, fixing the issue, accessing weather the fix was successful and fine
tuning the final fix)
Conducting Retrospect:
Project retrospective components:

 Project summary
 Action items
 Key accomplishments
 Future considerations
 Lessons learned.
 Resources
Module 3:
Benefits of using data:

 Making better decisions

 Solve problems
 Understand performance
 Improve processes
 Understand your users
Common types of project data:
Productivity metrics (milestone, task, projection and duration)
Quality metrics (Number of changes, issues, cost variance)

Correlation between data, metrics and analytics: Once you determine your project's metrics, you
analyze the data according to those metrics to find patterns and answer questions about your project.
This process is called analytics

The six steps of data analysis: Ask (what needs to be analysed?), prepare (collect data), process (clean),
analyze (draw conclusions), share (data visualization to organize your data) and act.

Presenting data to tell a project's story

 define your audience.

 collect the data.
 filter and analyze the data.
 choose a visual representation.
 shape the story.
 gather your feedback.
Three ways to effective presentation:

 Be precise (5 seconds to understand)

 Be flexible
 Be memorable
Module 4:
The factors that impact team effectiveness:

 Psychological safety
  Dependability
 Structure and clarity
 Meaning
 Impact
Leading high-functioning teams
 create systems that turn chaos into order; (define processes, when to inform etc.)
 communicate and listen (same page)
 promote trust and psychological safety; (interpersonal risk, opinions are welcomed)
 demonstrate empathy and create motivation; (being present and listen, recognize)
 delegate responsibility and prioritize. (reduce ambiguity)
 celebrate team's success.

Providing air cover for the team*

Bruce tuckmans stages of team development:

 Forming (clarify goals, roles)
 Stroming (focus on conflict resolution)
 Norming (standard processes are set, team norms are defined)
 Preforming (works together seamlessly, need proper delegation, motivation and feedback
from PM)
 Adjourning (celebrate final milestone)

Steps to effective influencing

 Establish credibility (why one should listen to you, show expertise and establish relationship)
 Frame for common ground (how idea would benefit the audience, if agreed for collaboration)
 Provide evidence (hard data and persuasive story telling)
 Connect emotionally

Using sources of power to influence

 Organizational
 o Role
o Information (level of access and control)
o Network (people you are connected with)
o Reputation
 Personal
o Knowledge
o Expressiveness
o History
o Character

Module 5:
Effective email writing:
 State what you want clearly.
 Keep the content short and concise.
 Structure your writing.
 Check grammar, punctuation, and spelling.

Common communication tools

 Messaging
 Virtual meetings
 Work management and collaboration tools

How to organize effective meetings

 Structured
 Intentional
 Collaborative
 Inclusive

Common types of project meetings

 Project kickoff
 Status updates
 Stakeholder reviews
 Project reviews

Activity reference:
Module 6:

Steps to conducting a closing process

 Refer to prior documentation (sow, raci, proposal – to compare if everything is complete)

 Put together closing documentation (conclusions, learning, etc.)
 Conduct administrative closure of the procurement process (contracts, payments)
 Make sure all stakeholders are aware that a phase or project is ending
 complete any necessary follow-up work (closing survey, feedback etc.)

If the project is closed at the end directly:

Closing the project for other PMs:

Components of the report:

 Exec summary
 Key accomplishments
 Lessons learned
 Open items
 Next steps and future considerations
 Project timeline
  Resources and project archive

Course 5:
Module 1:
Agile vs waterfall:

Four values of agile manifesto:

The 12 principles of the Agile Manifesto:

Bucket 1:
Bucket 2:

Bucket 3:
Bucket 4:

VUCA Concept: (volatility, uncertainty, complexity, ambiguity)*

Kanban boards: to do, in progress and done.(wip limit shown in the picture)
XP programming activities: (extremes the project management best practices)

 Designing (simple as possible to start with which can be further refined as and when needed)
 Coding
 Testing
 Listening
Principles of lean methodology (continuously eliminates waste)
 define value
 map value stream
 create flow
 establish pull
 pursue perfection

Module 2:
Agile is a foundation or philosophy, while scrum is a framework that materializes the philosophy.

Scrum: a framework for developing, delivering, and sustaining complex products. Works on iterative
(project processes are repeated) and incremental (work is divided in smaller chunks that build on each
other) approach

Scrum teams are 3-9 people

Scrum has 3 pillars and 5 values

 pillars
o
o inspection (timely checks towards the outcome of a sprint goal)
o adaptation (adjust to minimize any further deviation or issues)
 values
o commitment
o courage
o focus
o openness
o respect

Scrum team
 product owner (build the right thing)
 scrum master (build the thing fast)
 development team (build the thing right)

Product mission (why are we doing the work) and vision (what will the work be like when we are done)

Scrum masters responsibilities

 coaching team members on agile and scrum practices, rules and values
 helping to find ways to manage the product backlog effectively
 facilitating scrum events
 helping the team remove blockers
 preventing unhelpful interactions from outside of the team
 skills: organizational skills, supportive leaders, facilitate productivity and collaborations, coach
team members, great communicators,

Responsibilities of a product owner

 continuously maximizes the value of the product delivered
 helping the scrum team understand why their work matters
 prioritize the product backlog
 backlog is visible and transparent to all
 makes sure the product is fulfilling customer needs
 skills: customer focused, decisive (great in communication), flexible, optimistic and positive,
available, collaborative

traits of a development team: cross functional, self-organizing, supportive, customer oriented.

Module 3:

5 imp scrum events:

  Sprint (They are fixed length events of one month or less to create consistency), All the work
necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review,
and Sprint Retrospective, happen within Sprints.
 Sprint planning
 Daily scrum
 Sprint review
 Sprint retrospective

Product backlog:

Imp facts about product backlogs:

 Living artifact
 Owned and adjusted by the product owner
 Prioritized list of features

Best practices to build a backlog:

 Description
 Value
 Order
 Estimate
User stories:

User stories cane be broken down into 3 components:

 The user
 Action
 Benefit

Each user story should meet 6 different criterias: INVEST

 Independent
 Negotiable
 Valuable
 Estimable
 Small
 Testable

When writing user stories, you will need to include the following elements:

 User persona. What is your user like? What is their relation to the project? What goals do they
have?
 Definition of Done. This refers to an agreed upon set of items that must be completed before a
user story can be considered complete.
 Tasks. What are the key activities needed to complete the user story?

 Any feedback already provided. If you are adding features to an existing product and you have
already received feedback from customers on a past iteration, make sure to consider this
feedback.
Example user story: Let’s imagine you are working on a project for a local library. The library hopes to
launch a website so that customers can read reviews before they check out books from the branch. The
typical template for a user story looks like this: As a <user role>, I want this <action> so that I can get
this <value>. Therefore, an example user story for this situation might read: As an avid reader, I want to
be able to read reviews before I check out a book from my local branch so that I know I am getting a book
I am interested in.

Ecip: a group or collection of user stories

Acceptance criteria (created by product owner): the checklist you will use to decide whether the user
story is done.

Example backlog:
**As a <user role>, I want <this action> so that I can <get this value>**
Asana has lot of templates to directly use from (like the sprint planning template)
Estimation used in product backlog is relative estimation. Example if medium is the estimation for task A,
what will be the estimation for task B in comparison to task A.
Types of denotions used:
Tshirt size: s,m,l,xl…
Story points (palindrome): 1,2,3,5,8,13,21…

Planning Poker™
This particular method is well-known and commonly used when Scrum teams have to make
effort estimates for a small number of items (under 10). Planning Poker is consensus-based,
meaning that everyone has to agree on the number chosen. In this technique, each individual has
a deck of cards with numbers from the Fibonacci sequence on them. The Fibonacci sequence is
where a number is the sum of the last two numbers (e.g., 0, 1, 1, 2, 3, 5, 8, 13, and so on).

Sometimes, Planning Poker decks also include cards with coffee cups and question marks on
them. The question mark card means that the person doesn’t understand what is being discussed
or doesn’t have enough information to draw a conclusion. The coffee cup card means that the
person needs a break.

The Planning Poker strategy is used in Sprint Planning meetings. As each Product Backlog
item/user story is discussed, each team member lays a card face down on the table. Then,
everyone turns their card over at the same time and the team discusses the estimates, particularly
when they are far apart from one another. By first hiding the estimates, the group avoids any bias
that is presented when numbers are said aloud. Sometimes, when hearing numbers aloud, people
react to that estimate or the estimator themselves, and it changes what their initial thought may
have been. In Planning Poker, teams can easily avoid that bias.

Dot Voting
Dot Voting, like Planning Poker, is also good for sprints with a low number of Sprint Backlog
items. In Dot Voting, each team member starts with small dot stickers, color-coded by the
estimated effort required (e.g., S=green, M=blue, L=orange, XL=red). The items or user stories
are written out on pieces of paper placed around a table or put up on the wall. Then, team
members walk around the table and add their colored stickers to the items.

The Bucket System

The Bucket System is helpful for backlogs with many items since it can be done very quickly. In
fact, a couple hundred items can be estimated in just one hour with the Bucket System. The
Bucket System is an effective strategy for sizing items because it explores each item in terms of
pre-determined "buckets" of complexity. Keep in mind that these buckets are metaphorical; this
strategy doesn't require the use of actual buckets, and instead uses sticky notes or note cards as
buckets.
In this technique, the team starts by setting up a line of note cards down the center of the table,
each marked with a number representing a level of effort. Then, the team writes each item or
user story on a card. Each person draws and reads a random item, then places it somewhere
along the line of numbered note cards. There is no need to discuss further with the team. If a
person draws an item that they do not understand, then they can offer it to someone else to place.
Additionally, if a person finds an item that they think does not fit where it was placed, they can
discuss it with the team until a consensus about a more accurate placement is reached. Team
members should spend no more than 120 seconds on each item.

Large/Uncertain/Small
Large/Uncertain/Small is another quick method of rough estimation. It is great for product
backlogs that have several similar or comparable items.

This is the same general idea as the Bucket System, but instead of several buckets, you only use
three categories: large, uncertain, and small. Starting with the simpler, more obvious user stories,
the team places the items in one of the categories. Then, the team discusses and places more
complex items until each is assigned to a category.

Ordering Method
The Ordering Method is ideal for projects with a smaller team and a large number of Product
Backlog items. First, a scale is prepared and items are randomly placed ranging from low to
high. Then, one at a time, each team member either moves any item one spot lower or higher on
the scale or passes their turn. This continues until team members no longer want to move any
items.

Affinity Mapping
Affinity Mapping is useful for teams that have more than 20 items in their Product Backlog.

A best practice is to conduct this technique using sticky notes placed onto a wall, whiteboard, or
table. Each sticky note features a different user story or item. Using sticky notes allows the team
to move user stories around in order to group them by similar theme, group, and pattern. The
team begins by placing one sticky note on the board. Then, the team takes the next sticky note
and discusses whether it is similar to the first item. Based on the team’s assessment, the second
sticky note is placed in the first group or into its own group.

After all of the items are grouped (there should be anywhere from 3–10 groups total), the team
gives a name to each group that represents the general theme of the items. Then, the groups are
prioritized by importance so that the team knows which items to tackle first.
Plan using sprint planning template -> download as csv -> create a new project by uploading the CSV to
create a backlog in list format
Comparing Releasable Product Increment to Minimum Viable Product

 A minimum viable product (MVP) is a version of a product with just enough features to satisfy
early customers. Eric Ries, an entrepreneur and author, coined the term in this guide and defined
an MVP as “that version of a new product which allows a team to collect the maximum amount
of validated learning about customers with the least effort.”
 A minimum viable product is a package of features that may take several sprints to develop, but
every sprint’s goal is to produce a product increment.
 To differentiate between a potentially releasable increment and a MVP, let’s take our example of
the online pet adoption app and the three features we discussed previously. We noted that each of
these features on their own wasn’t a useful release of the solution. However, the Product Owner
may decide that the MVP for this user experience is to implement these three requirements for
cats only.
 By reducing the scope of the MVP, the Product Owner is able to release the solution into the
marketplace and collect feedback from the users who wish to adopt cats. This feedback will be
valuable not only for the cat adoption process but for any type of pet adoption in future iterations
of the product.

Velocity and burndown charts:

 It helps to answer the stakeholders on

Trello, jira, asana, used for scrum management

Imp video on agile: https://www.youtube.com/watch?v=502ILHjX9EE

Module 4:

Components of a value roadmap:

 Product vision (user interviews, market analysis) – destination
 Product roadmap – how to get to the destination
 Series of release plan (MVP1, MVP2, MVP3 …) – milestones for reaching destination

Three keys to influence:

  Clarify measurable results
 Find vital behaviors
 Use the six sources of influence
o Personal motivation
o Personal ability
o Social motivation
o Social ability
o Structural motivation
o Structural ability

Agile coach:
 Design the play with team
 Provide feedback to the team
 Celebrate and learn with the team

Agile coaching challenges

Hybrid agile frameworks

Devops: focuses on developing product fast and reliably.

Scaled Agile Framework (SAFe)

The most popular scaled framework is the Scaled Agile Framework or SAFe. SAFe is a Lean-
Agile scaling framework that draws heavily on concepts from Kanban, Scrum, Extreme
Programming (XP), DevOps, and Design Thinking methodologies. SAFe puts the goal of
delivering value above all else—the first principle of SAFe is “take an economic view.” The
framework organizes all work and teams into “Agile Release Trains” based on value streams; for
example, sales. The SAFe framework is mature and provides detailed guidance on all elements
of using SAFe, but some elements are more critical than others. Be sure to check back to the
Agile principles and values in the manifesto to be sure you are preserving agility.

SAFe, like most Agile practices, is founded on a set of core values:

 Alignment: Synchronize the planning and execution of SAFe activities at all levels of the
organization.
 Built-in Quality: Build quality into all stages of solution development.
 Transparency: Make execution activities visible at all levels to build trust among teams
and across the organization.
 Program Execution: Focus on working systems and business outcomes.
 Leadership: Model the values and principles of SAFe.
Read this article to learn more about the core values of SAfe.
Scrum of Scrums
Scrum of Scrums is a technique for integrating the work of multiple, smaller Scrum teams
working on the same project or solution. Coordination among teams is critical to ensuring the
deliverables from each team can be integrated into one larger, cohesive deliverable.

Scrum of Scrums involves the following elements:

 A group of at least 12 or more people divided into Scrum Teams of five to ten people
each
 Scrum of Scrums meetings, which are held once a week, twice a week, or daily. These
meetings follow the same format as a Daily Scrum meeting but focus on the Scrum team.
In these meetings, you’ll discuss questions like: “What did the team do yesterday? What
problems occurred, if any, that are negatively affecting your team? What does your team
want to accomplish before we meet again? Is your team blocked from moving forward on
any tasks?”
 A Scrum Master or designated “ambassador” for each team that participates in the
Scrum of Scrums meetings and a Scrum of Scrums Master who focuses on the overall
Scrum process across multiple teams
 Sprint Planning, Sprint Review, and Sprint Retrospective meetings
Beyond these very basic guidelines, there is no official framework or methodology to implement
Scrum of Scrums. Scrum of Scrums assumes that teams have a good working understanding of
Scrum and are able to apply the scaling principles to how they work. Building on this
knowledge, they design and iterate their own approach to coordinate multiple teams working on
the same product.

Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) is a framework that aims to maximize the Scrum team’s ability to
deliver value and reduce waste in larger organizations. LeSS grew out of more than 600
experiments that expanded the practice of Scrum to larger groups.

LeSS includes ten principles for applying the value, elements, and overall purpose of Scrum
across an organization. These principles were designed to create more customer- and
collaboration-focused teams. LeSS teams prioritize learning, transparency, and customer needs.
The ten LeSS principles are:

1. Large-scale Scrum is Scrum: Apply the values and principles of Scrum to a larger
team.
2. Empirical process control: Inspect, adapt, and learn from experience to improve
processes.
3. Transparency: Ensure clarity and accessibility across a project.
4. More with less: Create only necessary processes, roles, artifacts, and waste when
scaling.
5. Whole-product focus: Think holistically about the product, making sure that all the parts
serve the whole.
6. Customer-centric: Keep the customer’s needs and values at the heart of your process.
 7. Continuous improvement towards perfection: Improve the product—and your process
—during every single Sprint.
8. Systems thinking: Think about the system as a whole; Don’t get lost in the details.
9. Lean thinking: Seek continuous improvement, aim for perfection, and respect people.
10. Queuing theory: Embrace the Lean principles of “flow,’ manage queue size,” and
“minimize multitasking” to keep delivering value.
The LeSS toolkit provides two frameworks—one for up to about 50 people (called Basic LeSS)
and one for 50–6000+ people (called LeSS Huge). More information on the LeSS frameworks
can be found at less.works.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery (DAD) is a hybrid approach that combines the strategies from
various Agile frameworks, including Kanban, LeSS, Lean Development, Extreme Programming,
Agile Modeling, and more. DAD guides people through the process-related decisions that
frameworks like SAFe and Scrum of Scrums leave open. DAD helps you develop a scaled Agile
strategy based on context and desired outcomes.

DAD is organized into four “layers”:

1. Foundations discusses the principles, guidelines, Agile concepts, roles and team
structure definitions, and Way of Working (WoW).
2. Disciplined DevOps ensures that solutions are delivered to customers effectively and
safely, with data and security management always at the forefront.
3. Value Streams ensures that solutions are aligned with the organization's business
strategy, connecting customers, sales, and portfolio management to the framework.
4. Disciplined Agile Enterprise (DAE) connects the industry marketplace with corporate
governance and larger enterprise activities.
Project managers wishing to implement DAD can read more about the framework in this article:
Going Beyond Scrum.

The Spotify Model

Another approach you may encounter is the “Spotify Model,” which we discussed in a previous
reading. It is important to note that Spotify’s model is not a true Agile framework. There is no
standard guide on how to implement it. The model began as a description of how Spotify
overcame the challenges of scaling Agile. By focusing their efforts on culture, team autonomy,
communication, accountability, and quality, they increased their agility over time. Spotify’s
approach has had a huge impact on workflows and team structures across the tech world. Some
of the key components include:

 Squads: Like Scrum teams, Squads are autonomous teams of 6–12 people working
toward the same outcome. All Squads include a coach (similar to a Scrum Master) and a
Product Owner.
 Tribes: When multiple Squads work on the same feature area, they form a Tribe of 40–
150 people. Each Tribe has a Tribe Lead who fosters collaboration and coordination.
  Chapters: Squads may be autonomous, but specialists (e.g., JavaScript developers)
should still align across an organization. Chapters establish best practices and, where
necessary, set standards.
 Guilds: Any group of people interested in a certain topic can form a Guild, where people
with shared interests can come together as a community.
While some organizations have had success with this model, be aware that it evolved from
Spotify’s already significant Agile experience. It is the product of extensive introspection and
adaptation and draws heavily on the company’s culture of trust, transparency, and autonomy.
Therefore, the value of Spotify’s approach to scaling is not in team names like Squads and Tribes
but in how they developed practices that supported and served their organizational culture. To
learn more about the Spotify Model, check out this video from Henrik Kniberg.