Title: Agile Project Management with Scrum
Author: Ken Schwaber
Year: 2004
Pages: 192

Most of us have been part of projects where everything looked perfect on paper—detailed plans, timelines, milestones—but somehow, it all fell apart in practice.

Deadlines slipped, features changed, and teams scrambled. If you’ve ever thought, “There must be a better way,” this book is it.

Agile Project Management with Scrum isn’t just about doing things faster or more efficiently—it’s about changing how we approach complex work altogether.

Through real stories and no-nonsense insights, Ken Schwaber shows how teams can stop fighting chaos and start using it to their advantage.

As a result, I gave this book a rating of 7.5/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Agile Project Management with Scrum

Book Overview

Most teams don’t fail because they’re lazy. They fail because they’re following a plan that no longer makes sense.

That’s the hard truth Ken Schwaber confronts in Agile Project Management with Scrum, and the reason Agile Project Management with Scrum feels less like a how-to manual and more like a much-needed reality check.

If you’ve ever worked on a software project—or honestly, any complex initiative—you’ve probably seen the chaos up close. Requirements change, deadlines slip, people get burned out, and when the dust settles, what gets delivered doesn’t quite match what was originally asked for.

Traditional project management tools try to tame this mess with perfect plans and rigid timelines.

But Schwaber makes a compelling argument: instead of pretending we can control the chaos, why not learn how to dance with it?

That’s where Scrum comes in.

Scrum isn’t just about stand-up meetings or sticky notes on a board. It’s a shift in mindset.

At its core, Scrum is built on something called empirical process control—a fancy way of saying, “Let’s try something, see what happens, and adjust.” It’s about visibility, inspection, and adaptation. In other words: show your work, reflect on it often, and be willing to change course.

That might sound simple, but it’s radical in environments where following the plan has always mattered more than questioning it.

What makes Agile Project Management with Scrum work so well is that it doesn’t preach from a distance. Schwaber brings you inside real teams—like the exhausted developers at Service1st, the overwhelmed managers at MegaBank, or the visionary leaders at MegaFund.

You see the dysfunctions, the resistance, the small wins. You feel the tension between old habits and new ways of working.

And slowly, you watch how Scrum turns things around—not because it’s perfect, but because it forces people to face reality sooner, and fix what’s not working faster.

One of the most powerful stories in Agile Project Management with Scrum is from a company that used to crash-land every release.

They had beautiful Gantt charts, detailed specs, and deadlines… but they still ended up in chaos.

Then they tried Scrum.

Instead of waiting until the end to find out what wasn’t working, they built in feedback every 30 days.

Suddenly, they weren’t scrambling at the last minute—they were learning, adjusting, improving. Bit by bit, chaos gave way to clarity.

Another standout idea is how Scrum redefines roles.

The ScrumMaster isn’t a boss barking orders—it’s a servant leader who protects the team from distractions and guides them through uncertainty.

The Product Owner doesn’t just gather requirements—they decide what truly matters, constantly rebalancing priorities to deliver real value.

And the team? They’re not order-takers anymore. They plan, execute, and hold themselves accountable. It’s not just efficient—it’s empowering.

What’s especially refreshing is that Schwaber doesn’t sugarcoat the difficulties. Teams struggle.

Managers resist. People slip back into old habits.

But through every setback, Agile Project Management with Scrum keeps reinforcing the same idea: transparency beats assumptions, and collaboration beats control. Scrum works not because it’s rigid, but because it’s honest.

It puts the spotlight on what’s actually happening—good or bad—and gives teams the tools to respond.

Agile Project Management with Scrum also dives into scaling Scrum, which can feel like trying to juggle flaming swords.

But again, the message is clear: don’t rush it.

Lay the groundwork, build the right infrastructure, and let teams grow into their rhythm before layering on more complexity.

It’s a reminder that even agility needs structure.

By the time you turn the last page, one thing becomes obvious—Scrum isn’t just a framework for software. It’s a smarter way to work in any uncertain environment.

Whether you’re building an app, launching a product, or managing a transformation, the lessons in Agile Project Management with Scrum apply.

It challenges the comforting illusion that control guarantees success and replaces it with something far more valuable: trust, collaboration, and the humility to inspect and adapt.

That’s what makes Agile Project Management with Scrum more than just a guide—it’s a lens that changes how you see work.

Because in a world that’s always shifting, the teams that win aren’t the ones who plan perfectly. They’re the ones who learn the fastest.

Ken Schwaber and Jeff Sutherland

Ken Schwaber sees Scrum not as a solution, but as a mirror. In his view, Scrum exists to expose the dysfunctions that organizations would rather not face—unclear priorities, siloed teams, command-and-control leadership, and the illusion of predictability in complex work.

In The Enterprise and Scrum, Schwaber is clear: Scrum is intentionally disruptive. It’s designed to force uncomfortable conversations and shine a spotlight on what’s broken.

For him, the value of Scrum lies in its ability to create transparency, encourage inspection, and drive real, often painful, change—not in wrapping organizations in agile labels or surface-level rituals.

Jeff Sutherland, on the other hand, tends to present Scrum with more emphasis on speed, performance, and success.

In his book Scrum: The Art of Doing Twice the Work in Half the Time, the tone is more upbeat and results-focused. Sutherland highlights how Scrum can lead to high-velocity teams, fast learning cycles, and breakthrough outcomes.

While he also acknowledges the need for discipline and accountability, his approach leans more on the benefits of Scrum when it’s working well, rather than the turmoil of getting there.

It’s a more optimistic take, often aimed at energizing teams and executives to adopt Scrum for competitive advantage.

The core difference lies in tone and focus. Schwaber is the realist—he sees Scrum as a mechanism to challenge an organization to grow up.

Sutherland is the idealist—he shows what’s possible when Scrum is embraced deeply and used to unlock a team’s full potential. Both perspectives are true, and both are valuable.

But if you’re looking for a tough love, no-nonsense guide that holds up a mirror to your company’s behavior, Schwaber’s lens offers a raw, unfiltered look at what Scrum really demands.

Chapter by Chapter

Chapter 1 – Backdrop: The Science of Scrum

Software is complex—and that’s just the start.

Ken Schwaber opens Agile Project Management with Scrum by diving straight into the heart of the problem: software development isn’t just complicated, it’s inherently unpredictable. It’s not like building a chair or baking a cake.

In software, the “materials” are ideas, changing requirements, volatile technologies, and, of course, people—with all their moods, opinions, and experiences. So how do you manage something so messy? That’s where Scrum comes in.

Why Scrum exists

Scrum wasn’t invented out of thin air. It’s grounded in what’s called empirical process control, which is all about working with the unpredictable. Instead of trying to plan everything upfront and hoping it all works out, Scrum focuses on visibility, inspection, and adaptation.

That means constantly checking in, being honest about what’s really happening, and adjusting as needed. It’s less about having the perfect plan and more about responding smartly when things inevitably change.

Empirical process control in action

Here’s a simple way Schwaber puts it in Agile Project Management with Scrum: if something’s too complex to predict or control with standard processes, you need to guide it as it happens. Imagine reviewing code.

A developer writes it, someone more experienced reviews it, and they talk about how it can improve. It’s this feedback loop—see what’s happening, reflect on it, then change it—that Scrum is built around.

What makes software development so complex?

Schwaber outlines three major sources of complexity:

• Requirements – People often don’t know what they want until they see it. And when they do, their opinions change.
• Technology – It’s not just one piece of software. It’s systems talking to systems, often built with fragile, advanced, or evolving technologies.
• People – This might be the biggest wild card. Everyone has different skills, attitudes, and daily moods. And they all have to work together.

Put all that together, and it’s no surprise that software projects often feel chaotic.

Scrum’s response: Simplicity through structure

To manage this chaos, Scrum offers a simple, repeatable framework. At its core is an iteration—a fixed period where the team builds a working chunk of software. Every day, they check in with each other to inspect progress and adapt if needed.

At the end of each iteration, they show what they built, get feedback, and decide what’s next.

The heartbeat of Scrum: the team

The real engine of Scrum is the team itself. Given a set of priorities, they figure out how to build the product, make decisions together, and adjust their approach as they go.

It’s not a top-down process; it’s self-organizing, creative, and adaptive.

Who’s involved?

Schwaber defines three key roles in Scrum:

• Product Owner – Think of this person as the voice of the customer. They prioritize the work and make sure the team focuses on delivering the most valuable features.
• Team – These are the builders. They’re cross-functional and responsible for delivering working software every iteration.
• ScrumMaster – The coach. They help the team follow Scrum principles, remove obstacles, and ensure the process runs smoothly.

And then there’s the classic “pigs vs. chickens” joke.

The ones committed to the project (pigs) are different from those just involved (chickens). Scrum makes it clear who owns what and avoids letting bystanders interfere too much.

The Scrum flow

Everything starts with a vision, which is then translated into a Product Backlog—a living, prioritized list of what the product should do.

The work is done in 30-day Sprints, each beginning with a planning meeting and ending with a review and retrospective. Every day, the team holds a Daily Scrum to keep things on track. It’s all designed to be lightweight, fast, and focused.

Scrum’s key artifacts

• Product Backlog – The master list of everything that might be needed in the product, managed by the Product Owner.
• Sprint Backlog – A list of tasks the team commits to during the Sprint. It’s updated daily and shows what’s getting done.
• Increment – The actual working software delivered at the end of each Sprint. It must be “potentially shippable,” meaning tested, working, and usable.

Done means done

This is a big theme: when Scrum says something is “done,” it means really done. Not halfway there, not sort of coded. It’s built, tested, integrated, and documented—ready to go if needed.

This chapter of Agile Project Management with Scrum lays out the why and how of Scrum. It’s not about controlling everything. It’s about building systems that adapt and improve as the team learns.

Schwaber sets the stage for the rest of Agile Project Management with Scrum by giving us the science behind the framework—and reminding us that managing software projects means embracing complexity, not avoiding it.

Chapter 2 – New Management Responsibilities

Scrum and the Roles of Management

According to Agile Project Management with Scrum, In Scrum, management is split into three clear roles: the Product Owner, the ScrumMaster, and the Team. All of them are considered “pigs,” meaning they are deeply committed to the project and responsible for its execution.

On the other hand, “chickens” are the spectators—people who are involved in the project but not directly responsible for its success.

This distinction helps clarify accountability and authority within Scrum, and while the roles might seem simple, they are far from easy to fill.

Scrum managers have to handle complex situations and constantly adapt based on what the process reveals.

The ScrumMaster’s Role

The ScrumMaster is like the traditional project manager but with a crucial difference: instead of managing the work itself, the ScrumMaster manages the Scrum process. Their main responsibility is to ensure that Scrum is followed correctly.

If the project is like a flock of sheep, the ScrumMaster is the shepherd, keeping the team on track and shielding them from distractions or “wolves.”

One great example comes from a company called MetaEco, where the CTO, Tom, took on the ScrumMaster role. He had to balance the needs of the development team with the pressures from the CEO to meet client demands.

By standing firm on Scrum principles, Tom protected the team’s focus, which ultimately led to a successful deal with a new client.

The Product Owner’s Role

The Product Owner focuses on maximizing the project’s return on investment (ROI). They use the Product Backlog to prioritize what gets built and ensure that the most valuable features are developed first.

At MegaEnergy, the Product Owner, Jane, had to manage the complexity of automating a land ownership tracking system.

The previous attempts to do so had failed, but Scrum gave them a new chance. Jane worked with the team to prioritize the most valuable features and quickly saw business value after just 45 days.

This illustrates how Scrum allows the Product Owner to adjust priorities frequently, ensuring that the project delivers value at each step.

The Team’s Role

In a traditional project, the manager tells the team what to do. In Scrum, the team is responsible for its own management.

They decide what work to take on, how to approach it, and who will do what. This self-organizing structure can seem unusual, but it’s incredibly effective.

A great example is from a company called Service1st. The team, initially too large, faced challenges during the Sprint planning meeting.

But rather than letting the situation stall, the team took the initiative to reorganize itself into smaller sub-teams. This decision led to smoother workflow and better progress.

Why These Roles Matter

According to Agile Project Management with Scrum, the value of Scrum’s management roles becomes clear when you look at how these three roles—Product Owner, ScrumMaster, and the Team—interact with the project.

Tom at MetaEco protected his team’s focus, Jane at MegaEnergy optimized the ROI, and the team at Service1st self-organized to overcome obstacles.

In each case, Scrum made the project’s status visible and allowed for rapid adjustments to keep things on track. The result? Greater focus, more efficient workflows, and quicker delivery of value.

Scrum puts a premium on visibility and adaptability. Each role—whether it’s the Product Owner prioritizing work, the ScrumMaster protecting the team, or the team self-organizing—helps the project stay focused and responsive.

While these roles might seem simple, they require continuous effort, intelligence, and initiative. The structure of Scrum helps these managers adjust in real-time to meet the project’s goals.

Chapter 3 – The ScrumMaster

What’s in a Name?

Ken Schwaber starts by explaining why he chose the term “ScrumMaster” instead of using the more traditional “project manager” title. The term is designed to highlight the key difference between these two roles.

A ScrumMaster’s role isn’t about controlling tasks; it’s about facilitating the Scrum process, ensuring that Scrum rules are followed, and removing any obstacles that get in the way of the team’s progress.

The ScrumMaster’s power is indirect— it’s grounded in their knowledge of Scrum and their ability to guide the team toward success.

The Challenge of Being a ScrumMaster

While learning the basic practices of Scrum is relatively straightforward, understanding the philosophy behind it can be challenging. Scrum is about a fundamental shift in thinking: from controlling to empowering, from rigid documentation to working software.

For some, this shift is difficult. Schwaber compares the learning curve for ScrumMaster to learning how to ride a bike—it’s simple once you get it, but until you do, it can be confusing and difficult.

Some people may have the right practices but lack the deeper understanding needed to fully implement Scrum, leading to ineffective outcomes.

ScrumMaster Failures: A Few Case Studies

The chapter of Agile Project Management with Scrum explores several case studies to show how different ScrumMasters approach the role with varying levels of success.

The Untrained ScrumMaster at Trey Research

At Trey Research, the ScrumMaster was a traditional project manager who tried to apply Scrum techniques without understanding the deeper principles.

He took control of the Daily Scrum, reading off a list of tasks, checking whether team members had completed them, and assigning new tasks. This went against Scrum’s core principle of self-organization.

The ScrumMaster’s failure to facilitate the team’s own process rather than manage it directly led to a lack of commitment and engagement from the team.

It wasn’t until Schwaber pointed out this mistake that the ScrumMaster realized his approach had missed the point of Scrum.

The Untrained ScrumMaster at Litware

Similarly, at Litware, John, a project manager, failed to show up to critical Scrum events, sending someone else in his place. He did not grasp that Scrum requires personal commitment and leadership from the ScrumMaster.

A good ScrumMaster doesn’t delegate responsibilities, and John’s absence from key moments sent the message that Scrum—and the team—weren’t a priority. As a result, the team struggled to adapt and trust the ScrumMaster’s leadership.

Eventually, the ScrumMaster role was reassigned to someone who understood the importance of being present and active in the process.

Overzealous at Contoso.com

At Contoso.com, a ScrumMaster was too rigid in defending the Scrum process, which led to conflict. During a Sprint, a vice president insisted on halting the team’s work to attend an offsite meeting instead of allowing them to focus on their Sprint goal—an analyst meeting crucial for the project’s success.

The ScrumMaster, overzealous in enforcing the process, escalated the issue but ultimately faced pushback. This story highlights the fine balance that ScrumMasters need to maintain between protecting the team and adapting to the culture and realities of the organization.

Wolves at MegaFund

MegaFund, a large fund management company, had been struggling with its technology project. The ScrumMaster, Terry, was effective because he not only understood the rules of Scrum but also knew when to enforce them and when to be flexible.

When a senior manager attempted to derail the Sprint for a new opportunity, Terry used Scrum’s mechanisms to ensure that the team remained focused on their current goals without shutting down the opportunity entirely.

Terry’s ability to balance Scrum’s rules with organizational needs made him an effective ScrumMaster.

Lessons Learned

Each of these cases reveals the challenges of the ScrumMaster role.

The ScrumMaster is not a boss or a project manager; instead, they are a facilitator, protector, and coach. The success of Scrum depends on the ScrumMaster’s ability to guide the team toward self-organization, to remove obstacles, and to protect the integrity of the Scrum process.

The ScrumMaster must deeply understand Scrum, not just the mechanics but the philosophy behind it. They must be committed to the team’s success, even when it means standing firm against pressure from above or outside the team.

Responsibilities of the ScrumMaster

Schwaber concludes by summarizing the ScrumMaster’s key responsibilities:

• Removing barriers between the Product Owner and the development team
• Teaching the Product Owner to maximize ROI
• Helping the team remain creative and empowered
• Improving the team’s productivity and engineering practices
• Keeping the team’s progress visible to all stakeholders

The ScrumMaster role is a balancing act between guiding the team, adhering to Scrum principles, and responding to the needs of the organization. The role is not about control, but about facilitating a process that leads to greater collaboration, empowerment, and success.

The chapter of Agile Project Management with Scrum makes it clear that being a ScrumMaster requires a shift in mindset from traditional management approaches to a more supportive, coaching role.

Chapter 4 – Bringing Order from Chaos

The Struggles of Complex Projects

In software development, chaos often emerges when a project’s complexity surpasses the management team’s ability to guide it. Progress may happen in fits and starts, but it can feel unsatisfactory and aimless.

Scrum steps in to tackle this complexity by allowing teams to self-organize and gradually create order from the chaos.

This chapter of Agile Project Management with Scrumexplores several organizations’ journeys as they faced chaos in their projects, illustrating how Scrum can bring structure and success.

Service1st’s Struggle with Traditional Methods

Service1st, a software vendor, traditionally used detailed project plans like PERT and Gantt charts. Despite these efforts, every release cycle ended with the team exhausted and delivering buggy software.

The company had a culture of “fire drills” in the final two months of each cycle, where developers worked overtime to catch up. The result? Poor quality software and a worn-out team.

The vice president of development at Service1st decided to try Scrum to prevent burnout and improve the quality of software. But the company’s existing approach created a bottleneck in the development process, causing delays and frustration.

The team worked in a siloed, waterfall approach, with distinct roles for analysis, design, coding, and testing, which led to disjointed communication and a lack of collaboration.

Scrum’s Role in Bringing Order

When Scrum was introduced, the first step was to organize a Sprint planning meeting. The goal was to focus on a specific feature (workflow capabilities) and break it down into manageable tasks.

The team had to work together to find solutions, such as making the two products integrate seamlessly. This approach focused the team’s attention on one goal and allowed them to see tangible results in just one Sprint, with a small piece of functionality working across both products.

By focusing on incremental delivery, the team made measurable progress every month. The shift from a waterfall approach to Scrum’s iterative cycle helped reduce burnout and gave the team a sense of accomplishment.

The Scrum framework empowered the team to self-organize and decide on the best way to achieve their goals, leading to better collaboration and higher-quality software.

Tree Business Publishing’s Shift to the Web

Tree Business Publishing had been struggling for years to move its journals to the Web. Despite efforts, only one journal was online, and the process was bogged down by the complexity of creating a “media-neutral” platform for all publications.

When the company acquired WebPub, a dot-com capable of quickly creating Web content, they thought they had found the solution. However, the WebPub platform had its own peculiarities and wasn’t immediately compatible with Tree’s journals.

To solve the issue, Scrum was introduced to WebPub’s development team. The goal was to work incrementally to get Tree’s journals online, starting with four key publications. Teams were cross-functional, with developers, XML specialists, and WebPub experts working together.

The complex dependencies between these teams were addressed by self-organizing to resolve issues as they arose. The results were swift, with trade journals appearing online within three months.

Lapsec’s National Security Project

Lapsec, a research and development organization, was tasked with a high-stakes project to detect potential terrorist activities by analyzing large quantities of government data.

The project was highly complex, involving new and untested technologies, as well as significant coordination between multiple government agencies.

Early attempts at collaboration were unsuccessful, as the team struggled with the enormity and uncertainty of the task.

Scrum was introduced to give the team a structured yet flexible framework to tackle the project’s challenges. The team faced issues around data collection, storage, and algorithm design.

However, Scrum’s time-boxing and iterative nature allowed the team to focus on small, manageable chunks of work and gradually make progress.

Through collaboration, self-organization, and adaptation, the team was able to focus on the most critical aspects of the project and deliver valuable results within short time frames.

Lessons Learned from All Three Projects

The key takeaway from these case studies in Agile Project Management with Scrum is the importance of self-organization and incremental delivery in solving complex problems.

Scrum enables teams to break down large, intimidating projects into smaller, achievable goals, fostering collaboration and ensuring steady progress.

It’s clear that traditional methods of planning and controlling work simply don’t work in highly complex environments. Instead, Scrum’s iterative, empirical approach allows teams to adapt and respond to change, ultimately driving productivity and success.

Each organization faced significant challenges, but by adopting Scrum, they were able to create order from chaos. Service1st improved its release cycles and team morale, Tree Business Publishing managed to bring its journals online, and Lapsec successfully navigated a national security project.

Scrum’s core principles of time-boxing, incremental delivery, and self-organization provided the structure needed to turn these complex, chaotic projects into successful outcomes.

Chapter 5 – The Product Owner

The Challenge of the Product Owner Role

In Scrum, the Product Owner plays a crucial role in bridging the gap between the development team and the customers. Their job is not only to prioritize work but also to ensure that every piece of functionality delivers the most value for the business.

But this responsibility comes with significant challenges, especially in environments where the Product Owner and development teams have historically been disconnected.

There’s a long history of customer frustration and team miscommunication that Scrum works to solve, primarily through close collaboration.

Why Collaboration Matters

According to Agile Project Management with Scrum, in the past, as software development grew more complex, communication between developers and customers became more formal and distant.

The once simple, face-to-face conversations about what customers wanted turned into lengthy documentation processes, misunderstood requirements, and slow, fragmented feedback.

By the time customers could review the product, the solution had often drifted far from what they really needed.

The shift from this process to Scrum is designed to bring both sides back together. Scrum enables collaboration through short, iterative cycles where the development team delivers working software, and the Product Owner provides ongoing feedback.

This ensures that the product stays aligned with customer needs and avoids the trap of building features that don’t deliver real value.

The Role of the ScrumMaster in Facilitating Collaboration

The ScrumMaster’s role is pivotal in fostering this collaboration. According to Agile Project Management with Scrum, they act as a bridge, removing barriers between the Product Owner and the development team.

In some cases, they may need to work “undercover,” guiding the team and the Product Owner toward better communication without pushing the formal structure of Scrum too aggressively.

The goal is simple: make sure the development team stays focused on creating what matters most and the Product Owner gets the necessary visibility and involvement to make informed decisions.

Customer Collaboration in Practice

The chapter of Agile Project Management with Scrum discusses several examples where the Product Owner and development teams worked together effectively to maximize value through Scrum.

Service1st’s Management Gets Involved

Service1st had been struggling with traditional management approaches, where releases often slipped, and quality was compromised. When Scrum was introduced, it radically changed the way management interacted with the development teams.

Instead of relying on reports and lengthy meetings, the teams showcased their progress through Sprint review meetings. This direct, hands-on involvement allowed management to offer real-time feedback and make decisions that affected the product’s direction—resulting in a much more efficient and collaborative approach.

TechCore’s Focus on Product Development

At TechCore, an entrepreneurial leader found himself spread too thin, trying to juggle all aspects of the business. Scrum helped him refocus his efforts on what truly mattered: product development.

By using Scrum to create a Product Backlog and focusing on high-priority tasks, Michel could make better decisions, align the team, and improve the company’s prospects—culminating in a significant buyout offer after just a few months of implementing Scrum practices.

MegaFund’s XFlow and Internal Collaboration

Geoff, the product manager at MegaFund, faced a challenge of misalignment between the engineering team and internal customers. Scrum provided a structured, yet flexible, environment to bring these two groups together.

By facilitating regular, collaborative meetings, Geoff helped both parties understand each other’s needs, prioritize work, and agree on solutions. This not only improved the product but also fostered trust and collaboration within the organization.

MegaBank and the Simplicity of Scrum

At MegaBank, the FTS team was struggling with a lack of clear direction. The new management team was unsure about how to engage with the developers and get the project back on track.

Scrum was introduced with a simple approach: set up a Product Backlog, prioritize tasks, and have monthly reviews to check on progress.

This downplayed the complexity of Scrum, making it easier for non-technical stakeholders to understand and engage effectively. The result was better collaboration and more focused progress on the project.

Lessons Learned

The overarching lesson from these examples is the importance of collaboration and clear communication.

The Product Owner must bridge the gap between the business and the development team, ensuring that both sides are speaking the same language. For Scrum to work, both parties need to understand each other’s priorities and challenges.

The ScrumMaster plays a key role in facilitating this relationship and ensuring the team remains aligned with business goals.

Scrum doesn’t require complicated methodologies or jargon—rather, it encourages simple, direct collaboration that keeps everyone focused on delivering the highest value.

When the Product Owner and development team can communicate effectively, the results speak for themselves.

The role of the Product Owner is essential in guiding the team toward delivering value. They must prioritize effectively, ensure stakeholder involvement, and constantly adjust based on feedback.

Scrum helps facilitate these responsibilities by making collaboration a central part of the process. Whether it’s through direct involvement, regular feedback loops, or simplifying the way teams communicate, Scrum helps teams stay aligned with business needs and drives success.

Chapter 6 – Planning a Scrum Project

The Importance of Scrum Planning

In Scrum, planning is much different from traditional project planning. It isn’t about creating an exhaustive list of tasks or crafting long-term timelines, but rather about aligning expectations and ensuring that the team is prepared to adapt quickly.

The Scrum planning process is crucial for setting realistic expectations with stakeholders—whether that’s the ones funding the project, using its outcomes, or otherwise affected by it.

The plan is also key to keeping everyone on the same page, ensuring that the stakeholders know what changes to expect and when, and that they can adjust their expectations if the plan shifts.

One of the major differences in Scrum is that the plan isn’t a static roadmap—it’s a living document that evolves as the project progresses.

Three Key Questions for Scrum Planning

When you’re planning a Scrum project, there are three questions that must be addressed:

1. What can stakeholders expect at the end of the project?
2. What progress will have been made by the end of each Sprint?
3. Why should stakeholders believe this project is worth funding and that the team can deliver?

Scrum projects don’t require the detailed planning that traditional Gantt chart-based projects do.

Instead, Scrum is about monitoring the project and guiding it toward the best possible outcome as new information becomes available.

This makes it more adaptable, but also requires flexibility from all involved.

The Minimum Plan

The bare minimum for starting a Scrum project is a vision and a Product Backlog. The vision explains why the project exists and what success looks like, while the Product Backlog details the functional and non-functional requirements for achieving that vision.

The Product Backlog is continuously updated as the project unfolds, with priorities shifting based on what’s learned in each Sprint.

MegaBank Case Study

The chapter of Agile Project Management with Scrum then dives into an example of Scrum in action at MegaBank, a large financial institution.

The bank initially decided to use Scrum for a project that involved moving one of its key applications from a mainframe system to the Web.

The project was relatively simple at first—just recreate the existing system on the Web—but once Scrum was introduced, things changed quickly.

The planning process for the project began with a two-day Sprint planning session. This was necessary to teach the team how Scrum worked and to develop the Product Backlog.

In this session, the team listed all the features from the mainframe system that would need to be replicated in the Web-based version. The goal was to have enough of the Product Backlog ready to start, with more details emerging as they progressed.

Estimating the Product Backlog

Estimating work in Scrum can be difficult because software development is inherently unpredictable. The team initially struggled with the idea of estimating the work, especially when they didn’t know all the details up front.

But after a discussion about the nature of complexity and the limitations of accurate forecasting, the team moved forward.

The estimates were based on the team’s existing knowledge of the current mainframe system and their understanding of the new technologies they would use for the Web version.

The key takeaway here from Agile Project Management with Scrum is that estimating in Scrum isn’t about precision; it’s about gaining a rough sense of the size of the work, both in absolute terms and relative to other tasks.

This information helps with prioritizing the Product Backlog and dividing it into manageable chunks for future Sprints.

What Does “Done” Really Mean?

One of the challenges in Scrum is making sure everyone is on the same page when it comes to what “done” actually means.

The team’s first estimates didn’t account for all aspects of quality, like unit testing, code reviews, and refactoring. Once these factors were taken into account, the estimates changed.

The lesson here from Agile Project Management with Scrum is that “done” doesn’t just mean that something is finished; it means it’s been done with sufficient quality to deliver real value.

The Impact of Changes to the Plan

When the team had finished estimating the Product Backlog and breaking it down into Sprints, they realized that the project would take longer than originally expected. Initially, the team had committed to finishing the project in five months.

However, after considering the extra work involved in delivering a quality product, they revised the estimate to seven months.

This led to a difficult conversation with management. In the past, the culture at MegaBank was such that once a date was set, it was almost impossible to change it.

However, with the new Scrum process in place, the team had better data to support their decision and were able to have a more honest discussion about the project’s progress and realistic timelines.

Lessons Learned

The key lesson from this chapter of Agile Project Management with Scrum is that Scrum provides a more adaptive and realistic approach to project planning. Instead of rigidly sticking to an initial plan, Scrum emphasizes continuous feedback and adjustment.

This allows teams to make better decisions, prioritize work based on value, and be transparent about progress and challenges.

The chapter 6 from Agile Project Management with Scrum also highlights that planning in Scrum doesn’t require exhaustive detail upfront. What’s most important is having a vision, a Product Backlog, and a clear understanding of the work’s relative size.

The team’s ability to estimate and re-estimate based on new information helps them stay on track and adjust expectations as needed.

Scrum planning is not about creating a perfect, unchanging schedule. It’s about setting expectations, staying adaptable, and ensuring everyone involved understands the project’s goals, progress, and risks.

This approach leads to better communication, greater flexibility, and ultimately, more successful outcomes.

Chapter 7 – Project Reporting—Keeping Everything Visible

Visibility in Scrum Projects

In Scrum, one of the core principles is transparency. Regular, visible reporting keeps everyone informed about the progress of a project and allows the team to make necessary adjustments.

Scrum’s reporting system focuses on frequent inspection and adaptation to keep the project on track.

According to Agile Project Management with Scrum, this visibility isn’t just about internal team communication; it also plays a key role in updating stakeholders, ensuring they have up-to-date, meaningful information about the project’s progress.

Dynamic and Static Reports

Scrum involves both dynamic and static reporting. Dynamic reporting happens in real time through regular Scrum meetings like the Daily Scrum, where the team shares updates about their work.

This allows everyone to quickly gauge progress and address obstacles. Static reports, such as Sprint Reviews, provide more formal documentation at the end of each Sprint, offering a snapshot of progress.

For example, at MegaEnergy, traditional task-based progress reports were frustrating for stakeholders because they didn’t clearly connect to business functionality.

Scrum flipped this around by shifting the focus to the Product Backlog and its prioritization, giving stakeholders a clearer picture of what was actually being built and how valuable that work was.

The Dilemma at MegaEnergy

The challenge at MegaEnergy was introducing Scrum into an environment that was accustomed to Gantt charts and rigid planning. While the team had embraced Scrum, the senior management was deeply invested in the traditional reporting system.

They wanted to know how the project was progressing against the original plan rather than seeing a flexible, iterative process unfold.

To solve this, Ruth, the ScrumMaster at MegaEnergy, had to find a way to translate Scrum’s flexible approach into a format management could understand.

Instead of sticking strictly to traditional Gantt charts, Ruth adapted Scrum’s reports to show progress in terms of requirements rather than tasks.

This included using the Product Backlog Burndown report, which visually tracks remaining work and provides a clear indicator of how close the team is to completing the project.

Challenges at MegaBank

At MegaBank, the management wanted a more detailed understanding of the technology architecture and progress. Traditional reports about user functionality weren’t enough to satisfy the concerns of Jim, the executive overseeing the project.

To address this, the Scrum team created a technology progress report that tracked different layers of the system architecture and indicated progress by using color-coded milestones.

This custom reporting made it easier for management to understand the technical aspects of the project while staying aligned with Scrum’s iterative process.

The report was displayed in a highly visual format, so even busy executives could quickly gauge the project’s progress.

Visibility Issues at Service1st

At Service1st, the Scrum team faced a different problem. While the team demonstrated great productivity in the first Sprint by delivering a lot of functionality, it became clear that not all of the work had been completed to the necessary standard.

The team had skipped critical testing and bug-fixing processes to meet the demonstration deadline.

This issue revealed a deeper problem: the team wasn’t keeping the Sprint Backlog up to date. Without detailed tracking of their progress, the Daily Scrum became ineffective, and the team failed to address unfinished work in a meaningful way.

The lack of visibility into the work and the incomplete tasks caused confusion and poor planning for future Sprints.

Lessons Learned from the Service1st Case

The primary lesson here from Agile Project Management with Scrum is the importance of visibility at every stage of the Sprint. Without detailed and specific reporting, the Scrum team failed to properly track its progress.

The Sprint Backlog must reflect every task, including testing and bug fixing, and it must be updated daily to ensure that all work is accounted for. Only then can the team truly self-manage and make meaningful progress.

The ScrumMaster’s role is critical in making sure that everything is visible—whether that’s ensuring the Sprint Backlog is updated, ensuring tasks are clearly defined, or adapting Scrum reports to suit management’s needs.

The team must report in specific, measurable terms so everyone, including management, can track real progress.

The key takeaway from this chapter of Agile Project Management with Scrum is that Scrum works best when everything is visible for inspection. For teams to succeed, they must maintain clear, up-to-date reports that allow for accurate tracking of work.

ScrumMaster’s responsibility is not only to enforce Scrum practices but also to adapt reporting to the needs of the organization, ensuring transparency and collaboration at every step.

Whether it’s using traditional reporting tools or custom formats, maintaining visibility ensures that the team and stakeholders are always aligned with the project’s goals.

Chapter 8 – The Team

The Team’s Power to Manage Itself

Scrum’s real magic happens when the team becomes self-managing. Initially, many teams are unsure about their responsibilities and look to their ScrumMaster or other leaders to direct them.

But in Scrum, the team is in charge of planning, executing, and managing its own work. This is a significant shift, especially in cultures where teams are accustomed to top-down management.

The power of Scrum lies in the team’s ability to figure out how to deliver value without constant direction.

According to Agile Project Management with Scrum, the process of self-organization is both empowering and challenging. In the early stages of Scrum, teams often struggle with the idea that no one is going to tell them what to do.

But once they realize that the Sprint has begun and they must manage their work independently, things start to click.

This self-management leads to a feeling of ownership over the project, and ultimately, the team becomes more productive and engaged.

Service1st’s Struggle with Self-Organization

At Service1st, transitioning to Scrum was not without its challenges. The company had been using a traditional waterfall approach where team members were often isolated in their workspaces.

There was a rigid division of labor, with designers, coders, testers, and writers all working separately. When Scrum was introduced, this dynamic was flipped.

Teams were now expected to collaborate closely and take ownership of their entire work process.

One example from Service1st was when teams initially hesitated during the first Sprint planning meeting, unsure about how to break down the work.

After a few moments of discomfort, they started asking questions, such as “How should portlets look?” or “Do we have standards for design?” This was a key turning point in their understanding of Scrum: they began to realize that they were responsible for deciding how to best accomplish the work.

The Role of the ScrumMaster

The ScrumMaster plays a crucial role in helping the team transition to self-management. While the ScrumMaster doesn’t tell the team what to do, they guide them through the process.

This can be difficult because ScrumMasters often have to overcome their own ingrained management habits. The ScrumMaster is there to protect the team from distractions, ensure the team follows Scrum practices, and help with problem-solving.

A critical aspect of the ScrumMaster’s role is coaching the team through the Daily Scrum, where the team discusses progress, identifies obstacles, and adjusts their plans.

Over time, the team learns to take responsibility for their own work and develop the habits needed for success.

Challenges in Team Composition

At Service1st, forming the right teams was another challenge. The company had to ensure that each team had the right mix of skills to succeed.

This wasn’t always easy, as the teams had to balance domain knowledge with cross-functional expertise. In some cases, people were spread across multiple teams, which created additional complexities.

However, they adapted by organizing themselves into cross-functional teams, ensuring they had the necessary skills to tackle all aspects of the work, from coding to testing.

Learning to Trust Each Other

One of the biggest changes at Service1st was the shift from isolated work to collaborative effort. With Scrum, teams are encouraged to help each other and take collective responsibility for the outcome.

For example, the testers, coders, and writers worked closely together, often collaborating from the start of the project rather than waiting for one phase to be finished before the next could begin.

This shift toward collaboration fostered a more supportive environment, where team members trusted each other more and felt empowered to make decisions.

It also increased productivity and job satisfaction, as people felt more connected to their work and to each other.

Engineering Excellence and Self-Organization

One key challenge that arose was related to engineering practices. Early on, the team struggled with ensuring that the code was “clean”—meaning free from bugs, properly tested, and easy to maintain.

This issue highlighted the importance of continuous integration, where code is regularly checked in and tested to ensure that the team’s work remains in sync.

As teams adapted to Scrum, they learned to embrace engineering practices like pair programming and test-driven development to ensure that they could produce high-quality, shippable code.

Over time, this led to smoother workflows and more reliable software.

Sprint Retrospectives and Continuous Improvement

After each Sprint, the team holds a Sprint retrospective, where they reflect on what went well and what could be improved. This meeting allows the team to make adjustments and refine their processes continuously.

It’s a critical part of Scrum’s inspection and adaptation cycle. At Service1st, teams began to realize that it wasn’t about achieving perfection right away; instead, it was about making incremental improvements after each Sprint.

The retrospective also helped the team recognize areas for improvement in their cross-functional collaboration. For example, they decided to start helping each other more, with testers, coders, and writers working together from the start.

This not only improved efficiency but also fostered a greater sense of camaraderie within the team.

The Power of Self-Organization and Teamwork

The overall lesson from this chapter of Agile Project Management with Scrum is that self-organization is key to Scrum’s success. When teams take ownership of their work and collaborate effectively, they can achieve great results.

This is particularly true in complex environments where there are many unknowns and changing requirements. Scrum provides the framework for teams to manage themselves and adapt to new challenges, ultimately leading to higher productivity and greater job satisfaction.

The transition to a self-managing, self-organizing team is challenging but ultimately rewarding.

Teams that embrace this responsibility become more empowered, more productive, and more aligned with the goals of the organization.

Scrum helps teams achieve this transformation by providing a structure that encourages collaboration, accountability, and continuous improvement.

Chapter 9 – Scaling Projects Using Scrum

Scaling Projects with Multiple Teams

When a project becomes too large for a single Scrum team to handle, multiple Scrum teams must work in parallel. These teams must be coordinated to ensure that they remain synchronized, a process called scaling.

The challenge lies in maintaining the effectiveness of Scrum practices when the number of teams increases. This chapter of Agile Project Management with Scrum offers practical insights and lessons learned from projects where Scrum was successfully scaled.

Scaling at MegaFund

MegaFund faced immense pressure to modernize its technology to remain competitive in the financial sector. In 1997, MegaFund’s systems were outdated, and they needed to build a competitive product fast.

The solution was to scale their efforts across multiple teams, starting with one team working on the core technology infrastructure.

The project’s Product Owner wanted to initiate many teams simultaneously. However, the team realized that it first needed a robust architecture and infrastructure to ensure that multiple teams could work in harmony without stepping on each other’s toes.

The infrastructure included things like middleware servers, data access capabilities, and common standards. Only once the infrastructure was in place could additional teams be added.

After three Sprints of setting up the necessary infrastructure, seven teams were introduced, and the work was divided across them. Daily Scrum of Scrums meetings were held to ensure synchronization between the teams.

This approach allowed the scaling process to unfold smoothly, and business value was delivered from the very start, even before the teams were fully scaled up.

Key Scaling Lessons

The main takeaway from MegaFund’s experience is the importance of laying the foundation for scaling before expanding the team count. This means setting up systems, creating a detailed technical architecture, and defining clear standards.

Additionally, business functionality should always be delivered during each Sprint, even if the focus is on setting up infrastructure.

Scrum Scaling Practices

The first step in scaling is to create the infrastructure needed to support multiple teams. This includes ensuring that teams are capable of sharing source code, managing synchronized builds, and communicating effectively, especially in distributed environments.

Once the infrastructure is ready, scaling can proceed in phases, with one team first setting the groundwork, followed by others joining in.

Nonfunctional requirements (such as system architecture or build environments) must be prioritized in the Product Backlog before scaling.

These elements are crucial because they support the work of multiple teams and ensure that the teams’ work remains aligned. Staging is the process of defining and prioritizing these nonfunctional requirements and placing them into the Product Backlog.

During the initial phase, these are the items that take precedence.

Scaling at Medcinsoft

Medcinsoft used Scrum to manage a complex Y2K project, which required scaling efforts across multiple teams and customer sites. The company had to coordinate the work of over 300 developers, as well as field support personnel, to ensure that software releases were delivered on time.

With customers operating different versions of Medcinsoft software, many of them needed customized updates.

Scrum was used to synchronize releases with Sprints, and a structured approach was developed for prioritizing customer needs. Medcinsoft created a system where customer-specific backlogs were merged into an overall Y2K Product Backlog, which helped ensure that the various teams worked on the most critical tasks first.

Daily Scrums were held with customers within three months of needing a Y2K release. This kept customer priorities and feedback up-to-date.

The Product Backlogs were shared across the organization, ensuring transparency and coordination. The Y2K project was a complex operation that required precise synchronization between multiple teams, and the Scrum approach proved essential in keeping things organized.

Lessons from Medcinsoft

Medcinsoft’s experience showed that scaling doesn’t just involve adding more teams—it also involves effectively managing the flow of information between teams and customers.

By using Daily Scrums and keeping all Product Backlogs visible, Medcinsoft was able to keep everyone aligned with the project’s evolving priorities. The result was that despite the project’s complexity, the team could meet deadlines and customer expectations.

Scaling a project using Scrum requires a balance between self-organization and structure. While Scrum emphasizes team autonomy, scaling efforts often require simple, top-down guidelines to ensure coordination between teams.

The Scrum of Scrums is a method that helps ensure this coordination but should be used carefully to avoid overmanagement. Ultimately, scaling works best when self-organization is allowed to flourish, with a few guiding rules to keep everything in sync.

In summary, Scrum can be successfully scaled by preparing the infrastructure first, ensuring business value is delivered from the start, and fostering transparent communication through shared Product Backlogs.

The experiences at MegaFund and Medcinsoft illustrate that scaling is less about rigidly managing teams and more about empowering them to work autonomously within a clear, coordinated framework.

4 Key Ideas from Agile Project Management with Scrum

6 Main Lessons from Agile Project Management with Scrum

My Book Highlights & Quotes

“… The ScrumMaster is responsible for the Scrum process, for teaching Scrum to everyone involved in the project, for implementing Scrum so that it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows Scrum rules and practices…”

“… At the end of the Sprint, a Sprint review meeting is held. This is a four-hour, time-boxed meeting at which the Team presents what was developed during the Sprint to the Product Owner and any other stakeholders who want to attend…”

“… Laying out a process that repeatably will produce acceptable quality output is called defined process control. When defined process control cannot be achieved because of the complexity of the intermediate activities, something called empirical process control has to be employed…”

“… Scrum makes a clear distinction between these two groups and ensures that those who are responsible for the project have the authority to do what is necessary for its success and that those who aren’t responsible can’t interfere unnecessarily…”

“… Teams are self-managing, self-organizing, and cross-functional, and they are responsible for figuring out how to turn Product Backlog into an increment of functionality within an iteration and managing their own work to do so. Team members are collectively responsible for the success of each iteration and of the project as a whole…”

“… There are three legs that hold up every implementation of empirical process control: visibility, inspection, and adaptation…”

“… The rules of Scrum distinguish between the chickens and the pigs to increase productivity, create momentum, and put an end to floundering…”

“… It doesn’t matter whether it is visible that this functionality is done if no one can agree what the word “done” means…”

“… The heart of Scrum lies in the iteration. The team takes a look at the requirements, considers the available technology, and evaluates its own skills and capabilities. It then collectively determines how to build the functionality, modifying its approach daily as it encounters new complexities, difficulties, and surprises. The team figures out what needs to be done and selects the best way to do it. This creative process is the heart of the Scrum’s productivity…”

“… Scrum hangs all of its practices on an iterative, incremental process skeleton…”

Conclusion

Scrum doesn’t promise perfection—it promises visibility, learning, and adaptability.

It helps teams stop pretending they have all the answers upfront and start building something real, together.

Whether you work in software, product, or just want a smarter way to manage complex goals, Agile Project Management with Scrum gives you the mindset and tools to thrive in a fast-changing world.

You’ll walk away seeing projects—and teamwork—in a whole new light.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Articles
• Book Notes
• Career Development
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Agile Coaching Agile Transformation Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Psychological Safety Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: