Explore

Lesson 2: Selecting the Project Framework

Last edited 505 days ago by Makiel [Muh-Keel].

Many project management methods and frameworks exist today. Even a single project might use multiple frameworks, and even though each framework has strengths and weaknesses, they all solve specific problems and work well in certain scenarios

Frameworks and Methodologies

Frameworks and Methodologies are the processes, tasks, roles, and guiding principles that form the structure of completing work.

⁠

Waterfall

Waterfall is a software development model where the phases of the SDLC cascade so that each phase will start only when all tasks identified in the previous phase are complete.

This method predates software and was actually used in manufacturing; Software needed a starting point, so people used what they were familiar with.

Waterfall is a linear, sequential project management framework.

Delivers value at the end

Uses a Big Design Up Front (BDUF) approach

All work gets completed in one phase before another phase starts.

Work only flows one way in waterfall, too.

Ex. If a project is in the testing phase, and the team realizes they missed a feature during implementation.

In that case, the team cannot go back to the implementation phase.

Instead, they must go back to the first phase and start the project over.

⁠

There are 6 Phases in the Waterfall dev model:

Requirements - define the project requirements

Design - use the defined requirements to create a specified design

Implementation - Complete the necessary work.

Ex. Write the code for a software project and start building the foundation.

Testing - Verify that the work completed meets the requirements and quality specifications.

For instance, perform tests on a software project and obtain inspections on a construction project.

Delivery - Move the product into production for customers to use.

Maintenance - Solve and issues as they come.

Examples: A project to design and manufacture a new vehicle uses waterfall.

Strengths of Waterfall

Easy to learn and use

Easy to measure progress

Clear transitions between phases

Include thorough documentation

Can be used in any industry

Weaknesses of Waterfall

Not very flexible

Not friendly towards last-minute revisions or anything that deviates from the original plan.

Change management is expensive

Use Cases for Waterfall

Projects with fixed requirements and no unknowns.

Projects where change costs are incredibly high later in the project.

Short, simple projects.

Waterfall is not good for:

Projects with unclear requirements or expected changes.

Projects with high research and discovery needs.

Agile

Agile is often described as iterative and incremental development, meaning it’s adaptable to change and designed to work with uncertainty.

Agile methodologies will be more adaptable with shorter release cycles, and waterfall methodologies will require more information early in the project.

⁠

Iterative Development

Iterative Development is a process by which product development, such as software development, is broken down from a large application into smaller chunks. A product or product component is designed, developed, and tested in repeated cycles.

Small parts of features and improve them often

Doesn’t focus on one component at a time

Iterative refers to a repetitive step or process

Ex. The team works on small portions of the spending summary, color scheme, and category structures in one iteration.

During this iteration, they receive feedback at the end of the iteration and improve each feature the next time they work on it.

Customer’s perspective: Nothing changed about the product and the team didn’t fully finish anything and nothing could be released.

Incremental development

Incremental Development means features are completed and released often throughout the project. An approach that breaks the software development process down into small, manageable portions known as "increments."

Each increment builds on the previous version so that improvements are made step by step.

Ex. The team may develop and release and entire piece of the product and not work on any other portion.

The dev team did not receive any feedback during the development process, which means they missed opportunities to improve the final product.

Customer’s Perspective: They received a new login screen.

Using Both Incremental and Iterative Development

A method that builds an incremental model that is developed in multiple cycles of iterations.

A product may begin with relatively small components or steps, and incremental milestones are made during each cycle of the iterations until the final product is achieved.

⁠

Focus on one feature at a time. However, they would gather feedback at every iteration. It’s the best of both worlds: continual improvement of features and frequent value for customers.

Strengths of Agile

Great for uncertain environments with an expected bit of change.

Promotes more testing and adjustments early on and typically produces higher-quality results.

The speed of change and volume of competitors makes long development cycles impractical for many technology companies.

Weaknesses of Agile

Changing requirements can make a project’s end seem like a moving target.

Agile’s flexibility can lead to scope creep.

The extension of the project scope caused by unapproved and uncontrolled changes that impacts the cost, quality, or timing of the project.

The iterative and incremental designs are complex, relying on stable and highly skilled teams, which can be challenging to assemble.

Can lead to less documentation.

Use cases for Agile

Agile is ideal for the following:

Projects where requirements will change or emerge throughout the project.

Stable, skilled teams capable of self-organization.

Agile is not suitable for the following:

Short, simple projects that fit in a single iteration and increment. The overhead of agile frameworks isn’t valuable if the team does not have time to inspect and adapt the product.

Scrum

Scrum is a lightweight, customer-focused framework agile framework used to manage and deliver complex projects, particularly in software development. However, its principles are flexible and can be applied to various project types.

Iterative and Adaptive: Scrum emphasizes delivering value in small, iterative cycles, which allows teams to adapt to changes and refine the product continuously.

The focus is on delivering the most important features first, rather than attempting to plan and deliver everything upfront.

Minimalistic Approach: Scrum deliberately covers only the essential requirements to start the project, leaving room for teams to adapt and fill in details based on their experiences, company needs, and other frameworks that might complement Scrum.

Sprints are specific to Scrum.

How Scrum Works:

Empiricism: Scrum relies on empirical processes, meaning it emphasizes learning from actual experiences and adapting based on what is known rather than making predictions or assumptions.

Teams observe what is happening in the project, make decisions based on these observations, and adjust their approach as needed.

Lean Thinking: This principle within Scrum focuses on maximizing efficiency by eliminating waste—such as redundant processes, unnecessary tasks, and anything that doesn’t add value.

The goal is to streamline the workflow, ensuring that the team’s efforts are focused on delivering high-quality results efficiently.

There are 5 scrum values:

Commitment

Focus

Openness

Respect

Courage

There are 3 Scrum pillars of transparency:

Sharing information improves decisions

Frequent reviews disclose problems and needed changes

Incorporating results of inspection

You cannot adapt without inspecting problems and changes

Inspecting will achieve nothing if the work you’re doing isn’t transparent.

Scrum Process

The Scrum process is easily described in four steps:

The product owner prioritizes work into a product backlog.

The Scrum team selects the top items in the backlog. The top items create a sprint backlog, which will deliver a working product that helps solve the top problem in the product backlog.

The Scrum team and stakeholders review the sprint results and adapt the product and the team’s approach for the next sprint.

The steps repeat as long as the product backlog exists.

Scrum Roles

Scrum Team

The group of people who work together to deliver increments of value.

Team is very capable of deliver a product increment each sprint.

Still small enough to form cohesive relationships.

Normally 3-10 team members.

Includes:

One Scrum Master

One Product Owner

Developers

Product Owner

The team member that creates maintains, and owns the product backlog. They also maximize outcomes and selects and prioritizes the work that the agile team will complete.

Product Backlog - an ordered list of product changes or enhancements.

Product Goal - is used to describe the product’s longer-term target and the product backlog should deliver the product goal.

Scrum Master

The agile team’s Scrum coach. They help the team, product owner, and organization improve how they apply Scrum.

Offers coaching, training, and guidance.

Developers

View “developer” as a shorthand term for a Scrum team member. They can be any job title or function that helps the Scrum team produce value.

Professionals who program an application or other piece of code that executes on a computer.

Difference between Scrum Master and PM

A Scrum master helps a team get work done by helping the team adopt Scrum principles. For example, a Scrum master can encourage the team to look at new metrics or teach the group how to estimate work.

They want the team to perform well using scrum frameworks, but they don’t have a particular interest in what the team is creating.

A PM is highly invested in the specific outcomes and the team’s dynamics, works within any given framework, and helps the team deliver work by ensuring they have all the resources and information needed to complete it.

Key Scrum Terms

Product Backlog

Product Backlog - an ordered list of product changes or enhancements.

Product Goal

Product Goal - is used to describe the product’s longer-term target and the product backlog should deliver the product goal.

Sprint Backlog

Sprint Backlog - The Scrum team’s plan for the upcoming sprint. It includes what the team will do, why they think it is important, and how they will get it done.

Sprint Goal

Spring Goal - describe the single objective that the team plans to meet to advance toward the product goal.

Just as the product goal summarizes the value of the product backlog, the sprint goal summarizes the value of the sprint.

It’s a way to help the team stay focused on the top priority in a given sprint.

Increment

Increment - A complete body of work that meets the definition of done and moves toward the product goal.

Every increment needs a definition of done to create a shared understanding of what it takes to move forward.

Scrum Events

Scrum accomplishes all of the above through four repeating events designed to reduce meeting redundancy and complexity.

These 4 events normally occur on the same cadence and at the same place.

⁠

Sprint

Sprints are a Scrum iteration and the container for all other Scrum events. Sprints are fixed lengths, usually one week to one month.

Often called the heartbeat of Scrum, the sprint length sets the rhythm of work. Like days on a calendar, or, well, a heartbeat, a new sprint starts as soon as the previous sprint ends.

Each sprint sets a sprint goal, which is the primary value that the team plans to deliver in that sprint.

When a sprint starts, the group focuses on the sprint goal, and they don’t accept changes to their plan that would stand in the way of delivering on the goal.

The sprint goal is why sprints need to be one month or less; the goal fixes the team’s focus and the longer the sprint, the more likely the goal is to become outdated.

If the sprint does become outdated, only the product owner can cancel the sprint.

Sprint Planning

Sprint Planning is a session where the scrum team selects enough work for the upcoming sprint to build a sprint backlog.

The product owner discusses the highest-priority items in the product backlog and how they relate to the product goal.

The team creates a sprint backlog by breaking down PBIs into smaller pieces of work.

Sprint Planning lasts 8 hours/1 month sprints and less for shorter sprints.

Daily Scrum

Daily Scrum developers meet to review progress toward the sprint goal and plan the next 24 hours of work.

Developers should self-organize and use this time to create plans, review issues, and make decisions.

Normally lasts 15 minutes.

Sprint Review

Sprint Reviews are when the agile team shares their progress with stakeholders.

Demonstrating small pieces of work reveals valuable information.

It uncovers issues early when they are small and easy to fix

Reveals previously unknown development ideas

Confirms that the team is on track.

Group shares their progress and the stakeholders provide feedback and asks questions.

Attendees discuss where to go next.

Product Owner may adjust the product backlog based on the sprint review.

Spring reviews last 4hours/1Month and less for shorter sprints.

Sprint Retrospective

Sprint Retrospectives is a process improvement session where an agile team reflects on the previous sprint and identifies ways that the team can improve how they work together.

The only event not focused on the product, but instead focused on the scrum team.

Lasts 3hours/1Month and less for shorter sprints.

Strengths of Scrum

Lightweight framework

Flexible so it can be used across industries

Shorter life cycle allows for responsive learning and complex problem-solving.

Highly-customer centric

Continuous improvement and adaptability.

Weaknesses of Scrum

Many of its elements depend on very precise circumstances and therefore could falter in less-than-ideal conditions.

Relies on the organization to respect the product owner's decisions about the backlog and priorities; if that trust isn't there, the methodology could break down.

Scrum's framework is designed for a single, high-performing and cross-functional team, which means that less-experienced teams may struggle and scaling up to larger groups might be difficult.

A change in team member’s may result in a drop in productivity.

Use Cases for Scrum

Scrum is ideal for the following:

Highly cohesive, cross-functional teams focused on continual improvement.

Larger projects, because the product backlog is consistently refined and broken into tasks.

Complex products with unpredictable workflows.

Adaptable projects or products with expected unknown requirements.

Kanban

Kanban is an agile dev methodology that is relatively new, but Kanban as a concept was created in the 1940s for manufacture use.

Kanban is used to control work in progress (WIP) levels and manage workflows in software and other business processes.

⁠

Kanban’s 6 core practices

Visualize Work

Create a Kanban board that shows the specific phases that work moves through on your team.

Then create the actual pieces of work that are moving through the stages

Limit WIP (work in progress)

When people focus on too much work, they get overwhelmed. Context switching lowers productivity and degrades the work environment.

Limiting WIP (work in progress) allows team members to focus and increases throughput.

WIP limits reduce the number of items a team is working on at a time, and team members enjoy reduced context switching and increased focus.

The team doesn’t need to spend time planning work or operating in fixed-length iterations.

Instead, they work on what is in progress, and when they finish an item, they just start on the next item in the backlog.

However, this model relies on an accurate, ordered backlog, which the product owner must maintain.

Make Policies Explicit

Clearly define how work gets completed and moves from one phase to another.

Clear policies create a shared understanding of the work and the workflow

Manage Flow

Look for and eliminate bottlenecks in your workflow.

This embraces Kanban’s roots in lean and reduces waste in the system.

Implement Feedback loops

It’s important to build feedback into the system to stay informed about the system’s performance.

Create and measure metrics and the flow of work across the Kanban board.

These signals can help you identify bottlenecks.

Improve collaboratively, evolve experimentally

Use the scientific method to test ideas and measure the results in the Kanban signals.

Kanban’s goals is to start now and keep on improving.

Reinforces the idea that whatever the organization is doing now is a good starting point because the team will keep improving the workflow.

Kanban’s 4-part workflow

The product owner prioritizes and orders the backlog, ensuring that the most important and valuable tasks are at the top, ready to be worked on next.

A team member selects the top-ordered item in the backlog and pulls it into progress column on the Kanban board, initiating work on that task.

The team moves the work item through the workflow, keeping within the WIP limits.

The team collaboratively works on the task, moving it through each stage of the workflow (e.g., In Progress, Testing, Review), while adhering to Work In Progress (WIP) limits.

These limits prevent too many tasks from being worked on simultaneously, which helps maintain focus and efficiency.

When the team is ready to start new work, they select the next highest-priority item in the backlog and repeat the process.

Continuously pulling work as capacity allows.