Project+ Exam PK0-005

Lesson 2
Selecting the Project Framework

Copyright © 2022 CompTIA, Inc. All Rights Reserved. | CompTIA.org

1
Lesson 2

Topic 2A
Identify Project Methodologies

Copyright © 2022 CompTIA, Inc. All Rights Reserved. | CompTIA.org

2
Waterfall
• The oldest methodology. Started before software existed.
• Linear, sequential implementation across 6 stages
• One stage must finish before the next can begin
• Requires clear requirements

3
Waterfall

Waterfall development is depicted as cascading stages. 4

Waterfall
Strengths Weaknesses
• Easy to learn and use • Inflexible
• Adaptable to many industries • Changes will restart the project
at the first phase.
• Easy for PMs to track and use
• Need to be able to plan the
• Thorough documentation
entire project at the project’s
start

5
Waterfall
Use Cases
Good for:
• Fixed requirements.

• Projects with high change costs.

• Short, simple projects.

Not a good fit for:

• Unclear requirements.

• Expected changes and discovery.

6
Waterfall
Select a Framework for a Project
Consider waterfall for a project to Select a different approach for a
design and manufacture a new project to launch a new cloud-based
vehicle. personal budgeting application.
 Need requirements early  Frequent releases
 High cost of change  Enhancements after
implementation
 Restart cycle for changes
 Changes are affordable and
desirable
7
Agile
• Adaptable to change
• Employees self-organized agile teams
• Aims to release products early and often
• Iterative incremental development

8
Agile

Iterative development releases often and incorporates feedback and changes. Incremental development
releases one piece of functionality at a time. (Images © 123RF.com.) 9
Agile

Iterative and incremental development optimizes the adaptability of iterative development and the focus
of incremental development. (Images © 123RF.com.) 10
Agile
Strengths Weaknesses
• Adaptable • Prone to scope creep
• Works well with uncertainty • Moving targets and missed
and change deadlines
• Incorporates early testing and • Requires highly skilled,
quality checks motivated teams
• Gives workers more autonomy • Less emphasis on
documentation
11
Agile
Use Cases
Good for:
• Emerging requirements

• Projects with expected unknowns or changes

• Stable, highly skilled, cross-functional teams

Not a fit for:

• Short, simple projects that fit in one iteration

• Projects that need thorough requirements early

12
Agile
Agile versus Waterfall
• Waterfall and agile are often contrasted against each other as direct
opposites.
• They are often used as adjectives to classify other frameworks.
• “Agile” development: expect shorter release cycles.
• “Waterfall” development: expect to provide more information early.

• Every framework works well in specific situations.

13
Agile
Select a Framework for a Project
Consider agile for a project to Select another method for an
launch a new cloud-based enterprise resource planning (ERP)
personal budgeting application. system implementation
Frequent, affordable updates  Commercial off-the-shelf
software
Ongoing enhancements increase
competitiveness  Disruptive implementation
Customer-driven features  Changes to requirements would
through product use be expensive
14
Scrum
• One of the most common agile frameworks
• Started in software development, but is often applied in other
functions and industries
• Development objectives:
• Lightweight

• Build to minimum requirements

• Empiricism and lean thinking

• All-or-nothing framework
15
Scrum
Scrum Values Scrum Pillars
1. Commitment 1. Transparency
2. Focus 2. Inspection
3. Openness 3. Adaptation
4. Respect
5. Courage

16
Scrum
Roles & Responsibilities
• Scrum team: the group delivering value. They build the sprint backlog
and set the sprint goal.
• Product owner: the one person responsible for identifying which
enhancements will be built next. They tend to the product backlog and
set the product goal.
• Scrum master: coaches the team to improve their application of scrum.
• Developer: the remaining scrum team members (not the product
owner or scrum master).
17
Scrum
Events
• Sprint: 1-4 week timebox for all sprint events. It delivers an increment
of value
• Sprint planning: select work for the upcoming sprint
• Daily Scrum: plan the next 24 hours with the scrum team
• Sprint review: inspect progress with stakeholders and adapt the
product
• Sprint retrospective: reflect on the team’s performance and improve
18
Scrum

Sprint event schedule for a 2-week sprint.

19
Scrum
Strengths Weaknesses
• Lightweight framework • Requires a precise environment
• Requires respect for the product
• Adaptable to any industry
owner’s decisions
• Problem-solving focus • Harder for inexperienced teams to
adapt
• Customer-centric
• Team changes significantly reduce
• Fast pace delivers considerable capacity
quantities of work • Pace and schedule can lead to
employee burnout
20
Scrum
Use Cases
Good for:
• Skilled, cohesive, cross-functional teams
• Teams focused on continual improvement
• Large projects
• Complex projects with unpredictable workflows

Not suitable for:

• Teams with routine, predictable work
• Projects with frequently changing team members 21
Scrum
Select a Framework for a Project
Consider scrum for a project to Select a different approach for a
launch a new cloud-based project to create and staff a new
personal budgeting application. development team.
Incremental releases  Predictable workflow
Feedback from customers  Unpredictable timeline
(stakeholders) would influence
backlog

22
Kanban
• One of the most common agile frameworks
• Older than agile and software. Started in lean manufacturing.
• Aims to increase completed work by controlling work in progress
(WIP) and improving processes.
• Highly visual; the Kanban board is recognizable and used across
many other methodologies.
• Work is pulled from a backlog through predetermined workflow
stages until it reaches a finished state.
23
Kanban

Kanban boards are often adopted and deployed in any other framework.
They are electronic or physical boards. 24
Kanban
Core Practices
Transparency through
1. Visualize work visual work allows the
2. Limit WIP team to identify and
eliminate bottlenecks.
3. Make policies explicit
4. Manage flow
Reducing WIP reduces
5. Implement feedback loops context switching and
6. Improve collaboratively, evolve increases focus.
experimentally
25
Kanban
Kanban Workflow
1. The product owner prioritizes and orders the backlog.
2. A team member selects the top-ordered item in the backlog and
pulls it into progress.
3. The team moves the work item through the workflow, keeping
within the WIP limits.
4. When the team is ready to start new work, they select the next
item in the backlog.
26
Kanban
Strengths Weaknesses
• Simplest framework to learn • Sensitive to large teams and
team changes
• Applicable to any industry
• Prone to longer cycle times
• Limited overhead makes it easy
without active performance
to get started
management
• Works well for repeatable,
routine tasks

27
Kanban
Kanban versus Scrum
• Kanban and Scrum are often contrasted against each other.
• Kanban and Scrum solve different problems.
• Teams use Scrum to solve complicated problems.
• Teams use Kanban to focus on a reasonable amount of work.

28
Kanban
Use Cases
Good for:
• Teams with predictable processes but an unpredictable backlog, such as help
desk or request systems.
• Teams that thrive without structure.
• Stable workflows.

Not a fit for:

• Unpredictable workflows.
• Teams with high turnover. 29
Kanban
Select a Project Framework
Consider Kanban for a project to You may opt for a different
create and staff a new framework (or a hybrid
development team. framework) for a project to
Predictable steps in the launch a new cloud-based
recruiting process personal budgeting application.

Unpredictable timeline  Regular releases and feedback

needed
Need to know if something is
delayed
 Cadence and structure needed
30
Extreme Programming (XP)

• Agile software development framework.

• Heavy emphasis on software engineering.
• Some practices are applicable outside of software
development.

31
Extreme Programming (XP)

• XP takes good software engineering habits to extreme levels

and codifies them as practices.
• For instance, if code review is good, let’s review code while
we write it. Pair programming assigns two developers to one
keyboard. One writes code; one observes and reviews code.

32
Extreme Programming (XP)
XP Roles
• Customer. The customer selects the XP is a customer and
next feature. developer focused
framework.
• Tracker. Usually a part-time role for a
team member, they capture metrics It improves the
and look for improvements. developer’s quality of life
and the customer’s
• Coach. Mentors the team on XP. products.

33
Extreme Programming (XP)

XP Values
XP is well-known for its
Communication extremely simple code.

Simplicity XP developers will solve

today’s problems only
Feedback with the least amount of
work.
Respect
Courage

34
Extreme Programming (XP)
Common XP Practices
• Pair programming • On-site customer XP is a continually
• Ten-minute build • Energized work / 40-hour
evolving
work week framework.
• Continuous integration
• Stories XP can be
• Test-first programming customized and
• Weekly cycle applied and
• Incremental design
• Quarterly cycle combined with
• Sit together other frameworks.
• Slack
• Whole team

35
Extreme Programming (XP)
Strengths Weaknesses
• Exceptionally efficient • Limited applicability outside of
software development
• Modernized development
systems out of necessity • Limited focus on product
design
• Higher success rate
• Pace can lead to stress for
• Teams can apply a portion of
developers
the practices
• Minimal documentation
36
Extreme Programming (XP)
Use Cases
Good for:
• Small, stable software development teams

• Teams that need to react to changes quickly

• Projects with tight deadlines

Not a fit for:

• Teams with limited access to automation

• Teams with functional roles and limited need to collaborate

37
Extreme Programming (XP)
Select a Framework for a Project
XP may be a good fit for a project Select a different approach for a
to launch a new cloud-based project to implement a cloud-
personal budgeting application. based portfolio management
application.
Frequent changes
 Not software development
Access to customer
Collocated or virtual team

38
DevOps
• More of an organizational structure instead of a project
methodology
• Software engineering practices
• Integrates software development and IT operations process and
people
• Aims to increase efficiency and quality by improving
communications and breaking down functional silos

39
DevOps
CI/CD
• Core DevOps practice that drives all other improvements
• Continuous integration/continuous delivery or
continuous integration/continuous deployment
• Continuous integration: frequently check code into the main branch &
run automated tests
• Continuous delivery: automated processes prepare code for release
• Continuous deployment: automated process prepare and release
code to production 40
DevOps

Without DevOps, developers work in Plan-Test, and Operations works in Test-Monitor. DevOps brings all
activities under one team, KPI set, and technology stack. 41
DevOps
Strengths Weaknesses
• Less friction • Extensive skill requirements
per team
• More cross-functional
collaboration • Specialist teams may need time
to adapt
• Increased automation
• Limited applicability for
• Frequent deployments (faster
systems lacking automation
delivery to customers)
capabilities

42
DevOps
Use Cases
Good for:
• Teams that want to implement CI/CD

• Frequent releases
• Companies with adequate resources to automate and staff cross-
functional teams

43
DevOps
Managing Projects with DevOps Teams
Agile DevOps Teams Agile Teams without DevOps

• Smaller increments of • Increments are smaller than waterfall,

functionality larger than DevOps
• Manual test, integration, and
• Longer development time to
deployment processes (technology is
include more integration, test, the bottleneck)
and debug cycles
• Longer integration and deployment
• Minimal deployment tasks tasks
• Fewer dependencies • More dependencies
44
DevOps
DevSecOps – Second generation DevOps
• Builds IT security into the DevOps cycle
Organizations that
• Significant culture shift for most are accelerating
organizations delivery with
DevOps cannot
• Reduces security as a shared service and
afford to isolate IT
increases decentralized decision-making
security to a few
• Everybody owns security in DevSecOps specialists.

45
Scaled Agile Framework (SAFe)
• Popular agile at scale framework
• Defines how to use many frameworks together
• Introduces some structure to help multiple teams coordinate on a
cadence
• Agile at scale: how to have multiple agile teams working together
while retaining the flexibility of agile

46
Scaled Agile Framework (SAFe)
SAFe Terms
• Agile Team: any team, regardless of framework or methodology
• Agile Release Train (ART): group of teams working together to create a
product
• Iteration: timebox for development, like a Sprint in Scrum and Weekly Cycle
in XP
• Program Increment (PI): longer-term planning cycle, like the Quarterly Cycle
in XP
• Program Increment Planning (PI planning): the planning event for an ART,
like a scaled version of sprint planning for a single Scrum team 47
Scaled Agile Framework (SAFe)
Strengths Weaknesses
• Allows organizations to apply • Adds overhead layers and staff
agile practices across many
• Limits team’s decision-making
teams
authority
• Builds connections between
• Adds structural constraints to
business teams and
technology teams the team, e.g., cadence
synchronization
• Scalable to any size

48
Scaled Agile Framework (SAFe)
Use Cases
Good for:
• Companies with projects spanning multiple teams

• Companies with many agile teams that needs to coordinate

Not a fit for:

• Individual teams. SAFe is an organizational undertaking, so you wouldn’t
implement it for a single project.

49
Scaled Agile Framework (SAFe)
Select a Project Framework
Consider this scenario: Consider this scenario:

• Small startup with 9 employees • Medium-sized company

• Two agile teams working together
• One team
• Teams meet to coordinate
• Occasional coordination with an
external vendor • PM sometimes assists with
coordination and facilitation
• PM fills PM duties Don’t use SAFe. The added overhead doesn’t
add value when a few teams can self-
This organization doesn’t need SAFe. manage.
50
Scaled Agile Framework (SAFe)
Select a Project Framework
Consider this scenario: Consider this scenario:

• Large corporation • Five agile teams working together

• Five agile teams working together • Teams create the work schedule and
resolve dependencies together
• Teams conflict over scheduling and
• PM ensures alignment of work with
task sizes
objectives
• PM spends significant time on • PM assists with coordination with other
coordination and synchronization ARTs and external vendors
SAFe would synchronize the work and This organization is applying SAFe. It creates
reduce conflicts clarity and empowers teams to plan and manage
their work. 51
Software Development Life Cycle (SDLC)
• Phase-based software development framework
• Emphasizes increasing quality and reducing cost via continual
improvement
• Structures managing software for its entire life cycle - from planning
process to its eventual decommissioning
• Phases are customized by organizations to fit lessons learned and
various frameworks
• An SDLC model typically contains 5-8 phases
52
Software Development Life Cycle (SDLC)
SDLC Models
• Evolved out of a 1960s framework, systems development life cycle
• Started as a waterfall model
• Has continued to evolve to different methodologies and approaches
as trends change

53
Software Development Life Cycle (SDLC)

Waterfall SDLC flows sequentially. 54

Software Development Life Cycle (SDLC)

An iterative SDLC model repeats the center processes.

55
Software Development Life Cycle (SDLC)

A spiral SDLC model cycles through all phases and reduces risk in each increment. 56
Software Development Life Cycle (SDLC)

An agile SDLC model iteratively and incrementally delivers value.

57
Software Development Life Cycle (SDLC)
Strengths Weaknesses
• Comprehensive framework • Requires thorough advanced
planning
• Incorporates thorough
documentation • Framework can seem
constraining for agile teams
• Reduced risk, cost, and time

58
PRojects IN Controlled Environments (PRINCE2)
• Process-based project management methodology
• Common in Europe and Australia; standard for UK government
• Started as a waterfall methodology and has adopted an agile model
• Aims to manage resources and lower risk with structured phases,
tasks, and roles

59
PRojects IN Controlled Environments (PRINCE2)
PRINCE2 Roles
• Team manager: helps the PM with team supervision and quality
management
• Project board: group that authorizes resources and funding; consists
of executive, senior user, and senior supplier
• Executive: represents the business’s perspective
• Senior user: represents the customer’s perspective
• Senior supplier: represents the implementation partner’s perspective
60
PRojects IN Controlled Environments (PRINCE2)
PRINCE2 Structure
• Seven principles
• Seven themes
• Seven processes
• Tailoring to suit the project environment

61
PRojects IN Controlled Environments (PRINCE2)
Principles
1. Continued business justification PRINCE2 is a mostly
2. Learn from experience customizable framework.

3. Defined role and responsibilities The seven principles are

mandatory.
4. Manage by stages
5. Manage by exception Everything else can be added,
removed, or changed.
6. Focus on products
7. Tailor to suit the product
62
PRojects IN Controlled Environments (PRINCE2)
Themes Processes
1. Business case 1. Starting up
2. Organization 2. Initiating
3. Quality 3. Directing
4. Plans 4. Controlling a stage
5. Risk 5. Managing delivery
6. Change 6. Managing a stage boundary
7. Progress 7. Closing
63
PRojects IN Controlled Environments (PRINCE2)

64
PRojects IN Controlled Environments (PRINCE2)
Strengths Weaknesses
• Adaptable to any size project • Extensive documentation can
be cumbersome for some
• Team members onboard
teams
quickly
• Structure requires
• Extensive communication with
organizational buy-in
stakeholders
• Continual improvement built
into framework
65
PRojects IN Controlled Environments (PRINCE2)
Use Cases
Good for:
• Process-focused organizations

• Organizations and industries that rely on thorough documentation

• Projects with frequently changing team members

Not a fit for:

• Organizations that do not emphasize documentation

66
PRojects IN Controlled Environments (PRINCE2)
Select a Project Framework
Consider PRINCE2 for a Select a different approach for a
pharmaceutical company. small business with two owners
and one employee.
Long projects and changing
team members  Alignment with business goals
built-in
Extensive data and research
 No value in excess overhead
Detailed records are required
for research and regulation
67
 Review Activity: Project Methodologies
1. Why is waterfall described as linear and sequential?
2. What is the difference between iterative and incremental?
3. In Scrum, what is the difference between a sprint backlog and a
product backlog?
4. How are the iteration in SAFe and the sprint in Scrum similar and
different?
5. How has SDLC adapted to waterfall and agile methodologies?

68
Lesson 2

Topic 2B
Compare Agile and Waterfall Projects

Copyright © 2022 CompTIA, Inc. All Rights Reserved. | CompTIA.org

69
Product Ownership
Product Overview
• Product: a good or service offered by a company to internal or external
customers (e.g., a budgeting application or a telemedicine service)
• Long-lived operations and team
• Covers all enhancements and operational work for the entire product life cycle
• Product teams may implement projects or have separate project managers
• Product manager sets the long-term strategy
• Product owner implements the strategy with an agile team

70
Product Ownership
Project Overview
• Project: Short-term engagement to achieve a goal (e.g., launch a
budgeting application)
• Team disbands when the project ends
• Requires knowledge transfer and handoffs from a project team to
an operations team
• A project manager leads the team and owns achieving the
objectives
71
Product Ownership
Project and Product Roles
Found in agile frameworks:
• Product owner

Found in any framework:

• Project manager

• Product manager

72
Product Ownership
Responsibilities
Project Manager Product Owner Project Manager and
Product Owner
• Manage project plans, • Create valuable products • Communicate directly
including the schedule, with stakeholders
initiation, and closing • Work within a fixed time,
documents fixed cost, and flexible • Support and lead a team
scope
• Measure the project’s • Maintain work lists
progress • Provide product direction
and vision
• Manage project risks
• Work within fixed time,
fixed cost, and fixed scope

73
Product Ownership
Leading Projects
Project Manager Product Owner
Project managers will
PM manages team PO is the customer proxy
adopt some PO traits
Uses a WBS Uses a product backlog
on agile projects.
Measures team Doesn’t need to measure
productivity team productivity Use agile frameworks
More involved in work Not involved in work
breakdown breakdown when leading projects
with agile teams.

74
Product Ownership
Product Ownership on Agile Projects
• The PM may fill adopt PO responsibilities or collaborate with a PO
when leading agile projects.
• Agile teams are self-organized. They may lead work breakdown and
performance management.
• If your project involves an agile team with a PO, work with the PO to
create a consolidate backlog for the team to work from.

75
Team Composition
Agile Frameworks Waterfall Frameworks
• 3-10 members per team • Any team size
• Scaling framework needed for • Increased communication issues
large project teams with large teams
• Team member changes • Team members often change
noticeably affect productivity without significant productivity
changes
• One team roster for entire
project of cross-functional staff • Specialized roles join and leave
as their skills are needed
76
Communication
Stakeholders
Agile Waterfall
• Provides requirements • Provide requirements at the
throughout the project start of the project
• Receive multiple version of a • Receive a finished product at
usable product throughout the the end
project
• No interaction with project
• Interact with the project team at team during development
least once per iteration
77
Communication
Channels
Agile Waterfall
• Teams work directly with • PM is intermediary between
stakeholders stakeholders and team
• PM ensures channels are
available, assists with setting
agreements, and addresses
issues

78
Communication
Updates and Changes
Agile Waterfall
• Expected • Avoided
• Requires frequent • Requires thorough analysis
communication
• PM tracks change requests and
• PM tracks change requests and manages changes
manages changes

79
Requirements
Agile Waterfall
• High-level requirements are • All requirements are provided
shared at the start of the at the start
project
• During development,
• Details are defined throughout adjustments are captured as
the execution phase through project change requests
progressive elaboration
• The project ends with a full set
• The project ends with a full set of requirements
of requirements
80
Requirements

Progressive elaboration will build out each feature over time. 81

Requirements
Benefits of Progressive Elaboration
• People create requirements, and they are unlikely to remember
every detail when all requirements are built in one round.
• The pace of the competition in the software industry makes
requirements from six months ago outdated.
• Developers and customers will learn through developing.

82
Budget and Schedule
Agile Budget Waterfall Budget
• Budget is tied to a project but • Specific scope is associated with
not the scope a set cost
• Total project budget is used to • Customer knows what to expect
deliver as much scope as possible in scope and cost
• Changes will consume the • Changes will change the project
project budget cost
• Preferred by customers who • Preferred by customers with a
want to customize their solution limited budget
83
Budget and Schedule
Agile Schedule Waterfall Schedule
• Simple schedule defines • Detailed schedule defines when
increments but not scope deliverables are completed
• Scope is defined 1-3 sprints at a • Entire schedule and scope are
time built at the start of the project
• More flexible for customer changes • More predictable for customer
• Team is responsible for acceptable
• Team is responsible for
cost, scope, and schedule
acceptable cost, scope, and
performance
schedule performance
84
Environmental Factors
Agile Culture Waterfall Culture
• More complex work processes • Simpler work processes
• Favors cross-training and role • Favors deep knowledge and
generalization role specialization
• More group work • More solo work
• Exposes development process • Provides only finished products
to customers to customers

85
Environmental Factors
Agile Development Waterfall Development
• Build-test-deliver; build-test- • Build. Test. Deliver.
deliver; build-test-deliver…
• Members rotate in and out of
• Members stay for the entire the project
project
• Clear handoffs in
• Limited separation of responsibilities
responsibilities

86
Environmental Factors
Industry Standards
• Agile is desirable for industries where a rapid pace of change is the
norm.
• Agile is more challenging for regulated industries with more
documentation requirements.
• The project must follow regulations in any methodology.

87
Environmental Factors
Select a Project Framework
Consider an agile framework when:
• The customer has ample budget and wants to customize their product.
• The organization and teams work are built around agile frameworks.
• The testing and integration process are automated.

Consider a waterfall framework when:

• The customer is unavailable to review frequent increments of work.
• The project is small enough to complete in one iteration.
• Testers work across many projects and are only available for a few weeks. 88
 Review Activity: Agile and Waterfall
1. What are the size limitations of agile, scaled agile, and waterfall project teams?
2. How does stakeholder communication differ between agile and waterfall
projects?
3. How does the requirements gathering process differ between agile and waterfall
projects?
4. You are a PM for a project to design a new data management system. The
customers are internal to your company. While they can’t describe every feature
that they need, they are really excited to work with you throughout the project.
You’ve been given a full development and operations team for up to one year to
complete the project. Would you use an agile or waterfall methodology? Why
did you make that choice?

89
Project+ Exam PK0-005

Lesson 2
Summary

Copyright © 2022 CompTIA, Inc. All Rights Reserved. | CompTIA.org

90