Agile 2 - Scrum 101

Google Project Management Certificate · Course 5: Agile Project Management

Module 1 set out the Agile mindset, its four values and twelve principles, and the spread of frameworks that sit under the Agile umbrella. This module drills into one of them. Scrum is the most widely used of those frameworks, and the course spends the rest of its time there because Agile is the philosophy while Scrum is the thing that actually makes the philosophy operational on a real team.

The ordering is worth remembering because people get it backwards: Scrum is older than the Agile Manifesto, and it was one of the inspirations for the Manifesto rather than a product of it. That is also why the two words get used interchangeably in conversation, which is sloppy. Agile is the mindset. Scrum is one framework that materialises the mindset.

This module builds Scrum from the ground up: first the theory of why it works (empiricism, and the three pillars that follow from it), then the five values a team has to live out, then the mission and product vision that give the team something to aim at, and finally the three roles that make up a Scrum Team. Everything is illustrated with a new Office Green project called Virtual Verde, which delivers plants to people’s home offices.

What Scrum is, and where the name comes from

The Scrum Guide is the source of truth. It is free, it lives at Scrumguides.org, and everything Scrum Teams need to agree on is in it. Two definitions of Scrum come out of it in this module, and they say the same thing from different angles: a framework for developing, delivering and sustaining complex products, and a framework in which people tackle complex adaptive problems while creatively and productively delivering products of the highest possible value.

The practical reading is that you use Scrum when the environment or industry is hard to predict and the project carries real risk. It is not a framework for work you can specify perfectly up front. The name is borrowed from rugby, where the scrum is the formation in which the whole pack pushes towards one objective together. That analogy runs through the module - a Scrum Team is like a sports side where every position has its own job but only the collective result counts.

Empiricism: the theory underneath

Scrum rests on empiricism, the idea that real knowledge comes from lived experience rather than from prediction. The Scrum founders’ position is that in an uncertain world you should not assume the plan will hold or try to forecast the future. Instead, every decision you take is grounded in actual experience and hard data.

Two mechanics deliver that. Iterative means the project processes are repeated, with the work running in timeboxes or iterations rather than one long push. Incremental means the work is split into smaller chunks that build on each other, and each instance of the product produced that way is an increment.

Put together, every iteration is effectively a mini experiment. You learn something real from it, you check progress against reality repeatedly across the life cycle, and that is what makes the project more predictable and shrinks its uncertainty.

Work a small slice in a timeboxiterative - the process repeats

Produce an incrementincremental - chunks that build on each other

Inspect it with the team and stakeholdersdetect variances while you can still act

Adapt the product, plan or processthen start the next iteration

Each pass round the loop is treated as an experiment that produces evidence, not as a step in a fixed plan.

The three pillars of Scrum

Empiricism itself stands on three foundations, and those same three are the pillars of Scrum.

Transparency

Make the most significant parts of the work visible to everyone accountable for the outcome. That obligation is universal: Scrum Team members, senior sponsors, and the users too.

Transparency is easier on a small team, which is one reason Scrum Teams are deliberately kept small, between three and nine people. Small teams avoid mixed signals, communication breakdowns and needless complication. Inside the team, transparency is what makes the team productive and the project finishable. Outside the team, being transparent with customers, sponsors and management builds trust, and trust in turn buys you more collaboration and fewer mistakes.

Inspection

Inspection means timely checks on progress towards a Sprint goal so that undesirable variances get spotted. A stakeholder review of the work is not an interruption, it is an opportunity for growth: the more inspection a team does, the more its work improves. The value sits in inspecting while there is still a chance to change something.

Adaptation

Adaptation means continuously looking for ways to adjust the project, the product or the processes so deviations and issues do not grow. Transparency and inspection supply the information and the opening; adaptation is what you do with them. Agile as a whole embraces change here rather than resisting it. Note that adaptation is not only the immediate fix to an immediate problem - it also covers changes made so that future projects do not repeat the same mistake.

The order of the three is not decorative: you cannot inspect what was never made visible, and you cannot adapt without something inspected to adapt from.

The five Scrum values

Where Agile has its values, Scrum has five of its own that every team member subscribes to. Having them written down means teammates can expect each other to behave a certain way.

Value	What it asks of you	Example from the module
Commitment	Personally commit to the Scrum Team’s goals	Someone is blocked by an unfamiliar technology, so a teammate who knows it puts their own work aside to teach them
Courage	Do the right thing and take on the hard problems	Accepting a task that forces you to learn a new skill, admitting to the team that you are stuck, or naming a negative behaviour so it can be discussed openly
Focus	Concentrate on the work in the Sprint and the team’s overall goals	Letting the person on the hard, necessary piece stay on it while teammates carry it over the line, because that speeds the team up in the long run
Openness	Team and stakeholders agree to be open about the work and its challenges	Raising an issue you cannot fix instead of sitting on it, since someone else may have a quick solution or a useful option
Respect	Respect teammates’ opinions, skills and independence	Feeling respected makes you far more likely to actually listen to feedback, which is what makes the product better

Courage is worth a second look: responding to hard situations with courage is what builds a team’s resilience. And openness has a mechanical purpose as well as a cultural one - you cannot gather data if people will not share their observations and experience.

How the values bring the pillars to life

The two lists are not separate. The pillars only happen if the team behaves according to the values.

Transparencyneeds

Openness & focuswilling to share information with stakeholders, disciplined enough to share the parts that actually matter

Inspectionneeds

Courage & respectcourage to give difficult feedback on the work and the process, mutual respect to really listen to it

Adaptationneeds

Courage & commitmentcourage to change things and learn from it, commitment to follow the change through

Mission and product vision

One Agile principle says to build projects around motivated individuals, give them the environment and support they need, and trust them to get on with it. The module’s answer to how do you motivate them is to give them a mission and a product vision they care about.

Virtual Verde makes it concrete. Office Green’s business development department wrote the mission: Virtual Verde improves the health and happiness of users by bringing their at-home workspace to life. The Scrum Team wrote the product vision: Virtual Verde is a living marketplace that transforms the home office. Both exist to push the team towards a delightful experience for the people who use the service.

The Scrum Team and its three roles

Every Scrum Team has exactly three defined roles, and the cleanest way to hold them apart is by the question each one owns.

Product Owner - the WHAT

Responsible for what the team builds, and for making sure everyone understands the why
Captures and promotes the good ideas coming out of the team
Slogan: build the right thing

Development Team - the HOW

Responsible for how the product gets delivered
On Virtual Verde: building the ordering website, integrating billing systems, fixing issues
Slogan: build the thing right

Scrum Master - the WHEN

Responsible for when the team delivers value to its users
Unblocks the team: chasing a late vendor, prioritising user issues, organising the demo for the CEO
Slogan: build the thing fast

The boundaries are softer than those three panels suggest. Expectations per role are clear, but the whole team works together on the goals: Developers still contribute ideas on the what and the when, and the Product Owner still joins the discussion on the how. The Scrum Master role is roughly the equivalent of the project manager in a traditional project, which is why project managers usually pick it up.

Two collective skills the Scrum Guide requires

Cross-functional. Whatever a Scrum Team delivers is the whole team’s achievement, regardless of which function or part of the organisation each person came from. A single team might hold a software developer, a marketing specialist, a quality assurance specialist and a logistics expert. The soccer analogy again: each player covers their position, and between them you have everything needed to get the ball into the goal. The mixed perspectives are themselves worth something to the project, the users and the business.

Self-organising. This is the part that feels alien coming from an organisation where a manager assigns your tasks and asks for frequent updates. Because the team leans on the five values, it can organise its own work and still deliver, in a more organic and flexible setting.

The Scrum Master in detail

The Scrum Master promotes and supports the Scrum process by helping everyone understand and implement it, including its practices, rules and values. The Scrum Guide phrases this as two accountabilities: establishing Scrum as the Guide defines it, both inside the team and in the wider organisation, and being accountable for the Scrum Team’s effectiveness by enabling the team to improve its practices within the framework.

The most useful framing from the video: a Scrum Master is responsible for helping the team be its very best, by coaching individuals to handle external forces and by maximising the team’s internal potential. The Virtual Verde example is the error reports piling up on the shopping cart feature. A Scrum Master does not fix errors one at a time; they notice the pattern and help the team find a better solution, maybe a dedicated test plan or extra solution reviews before that feature ships changes.

What the role actually does

Coach team members on Agile and Scrum practices, rules and values, and on self-management and cross-functionality.
Help find effective ways to manage the Product Backlog.
Facilitate Scrum events, such as the Sprint Retrospective at the end of every Sprint, and make sure the important meetings such as the Daily Scrum actually happen.
Keep every event positive, productive and inside its timebox, the way a coach keeps an eye on the game clock.
Cause the removal of blockers and impediments to progress, whether that is missing information or access to tools and training.
Shield the team from unhelpful interactions and interruptions coming from outside it.
Help the team focus on producing high-value Increments that meet the Definition of Done.

Traits that make it work

Organised - artifacts and eventsSupportive leader, not a bossFacilitator of productivityCoach, not answer-giverCommunicator with diverse stakeholdersNegotiator and conflict-resolver

Supportive leadership here means putting the team’s needs and other people’s needs ahead of your own, and the questions that go with it are how can I help and what would move the team forward on this, not instructions. Coaching means encouraging dialogue and discussion instead of handing over answers. Communication matters most with stakeholders, who often arrive with competing perspectives and styles.

A Google technical program manager interviewed in the module adds the leadership angle. An effective Scrum Master is first a good teacher and communicator, because the Scrum values have to be instilled across the team. Second, they lead through influence, since in most cases they have no managerial authority over anyone on the team. Influence gets used two ways: keeping the team operating effectively, and building a culture of motivation inside it. They are also expected to give direction and keep the team pointed at the goals set for the Sprint, which he describes as a focused effort towards particular, well-defined goals, a burst of energy that gets the team there.

Scrum Master versus project manager

They share a skill set and are frequently the same person, but they are not the same job.

	Scrum Master	Traditional project manager
Primary job	Facilitator and coach to the Scrum Team, first and foremost	Leads the team to meet objectives, oversees tasks and progress
Scope and priority changes	Does not manage them	Owns scope management
Artifacts	Does not maintain Gantt charts and similar traditional artifacts	Budget management, risk spreadsheets, Gantt charts
Focus	Establishing Scrum, team effectiveness, removing impediments	Delivering the plan

If the company genuinely needs all that traditional project management activity done, it may hire project managers to own it alongside the Scrum Master. And a Scrum Master needs enough hours in the day to do the facilitation and coaching properly, which is the point of separating the two.

The Product Owner in detail

The Product Owner exists so the team builds the right product. A ruthlessly efficient Scrum Team is useless if it ships something nobody wants. Formally, the Product Owner is responsible for continuously maximising the value of the product the Scrum Team delivers, and the Scrum Guide notes that how this gets done varies a lot between organisations, teams and individuals.

The key activity is being the voice of the customer inside the team, and the way that voice gets expressed is through ownership of the Product Backlog.

Develop the Product Goal and communicate it explicitly.
Create Product Backlog items and communicate them clearly.
Prioritise the Product Backlog so goals are met in the best order and value reaches customers soonest.
Keep the Product Backlog transparent, visible and understood by everyone.
Help the Scrum Team understand why their work matters to the overall goal and mission.
Make sure the product or service genuinely fulfils the customer’s needs.

Traits

The traits are customer-focused, decisive, a great communicator, flexible, optimistic and positive, available, collaborative and organised. Customer focus means understanding both the customer’s needs and the business’s industry extremely well. Decisiveness has a partner requirement: understand both sides of an issue so you can defend your decisions to the team. Flexibility means being open to new information that could generate a profitable change. Optimism matters because this is the person delivering the product vision and inspiring belief in the mission. Availability is not optional, because the iterative nature of Scrum means the team needs the Product Owner regularly to inspect, adapt and plan the next iteration, and collaboration means working alongside several stakeholders to make sure customer needs are met. The reading adds a useful boundary: a Product Owner supplies direction, requirements and objectives with confidence, but lets the team work out how to achieve them.

The herb garden example

The Virtual Verde Product Owner hands the Development Team a priority order: flower arrangements, then potted succulents, then large potted plants, then herb gardens.
The Development Team reviews it and pushes back. Herb gardens were assumed to be hard because they count as regulated food items.
The vendor specialist on the Development Team knows better: the vendor already holds plenty of herb gardens in stock, so they are far easier than assumed. The team suggests doing them first.
A Product Owner who is flexible and customer-focused reprioritises on the new information rather than defending the original list.

Product Owner versus project manager

In traditional project management, scope is the project manager’s primary responsibility. In Scrum, defining and managing product scope moves to the Product Owner. The reverse also holds: the Product Owner is not accountable for team performance and is not a manager, whereas the project manager leads the team to the objectives and oversees tasks and progress. What the two share is stakeholder management, since both have to practise and enable effective communication across team and stakeholders.

The Development Team in detail

The Development Team, also just called the Developers, are the people who do the work of building the product. The Scrum Guide describes them as the members of the Scrum Team committed to creating some aspect of a usable Increment every Sprint.

Size is three to nine people, and the range is deliberate. Small enough to stay nimble, large enough to finish something meaningful within a single Sprint. Go smaller and you struggle for diversity of skills and ideas; go larger and you drown in opinions and communication streams.

Characteristic	What it means in practice
Cross-functional	The team holds all the skills needed to build the product in-house. Software: web developer, database developer, user experience specialist. Marketing: writers, editors, search engine optimisation specialists, business analysts
Self-organising	They own their own processes and structures and do not wait to be told how to organise
Collective	They operate continuously as a team rather than a set of individuals, and support each other towards the team’s goals
Customer-oriented	They accept that the best products come from teams who keep the user in view while building

Responsibilities

Create the plan for the Sprint, which is the Sprint Backlog.
Instil quality by holding to the Definition of Done.
Adapt their plan each day towards the Sprint Goal.
Hold each other accountable as professionals.
Execute sprints by designing, building and testing Product Backlog items in increments.

The traits to hire for are people who stay focused on completing deliverables and producing a superior end product, and who are eager to collaborate and willing to compromise for the good of the product, since the team is self-organising and cross-functional. More generally, across all three roles you want people interested in constant collaboration and improvement, who value feedback, bring energy and fun, and can admit and learn from their own mistakes.

Co-location, and the alternative

Many Scrum Teams prefer to be co-located, working alongside each other in one physical space, on the belief that the work is higher quality and the team improves faster. It is not always possible.

The Virtual Verde example: a plant vendor hits quality problems and will miss the holiday rush. The quality assurance specialist could fly out to help the vendor, but then their assigned tasks go undone. A co-located team huddles in a conference room, sketches options, and either covers the work or rearranges it so the Sprint goals survive. A distributed team does the same over phone or email, or coordinates diaries across time zones for a meeting, and the workarounds that follow can end in overall project delays. Set against that, video conferencing means the specialist can dial in from anywhere. Both arrangements have benefits and drawbacks, so pick whichever suits your team.

The artifacts named in this module

The role videos introduce the Scrum artifacts as they become relevant rather than as a set, so this is the vocabulary as far as these lessons take it.

Artifact	Definition given
Product Backlog	The single authoritative source for the things a Scrum Team works on. It holds all the product features, product requirements and activities tied to deliverables that achieve the project goal. Owned and prioritised by the Product Owner, and kept visible and transparent to everyone
Sprint Backlog	The set of Product Backlog items selected to be completed during the upcoming Sprint. It is the Development Team’s plan for that Sprint
Increment	Each instance of the product produced by an iteration. The product is built up over time out of increments, and every Sprint should produce a usable one that meets the Definition of Done

Where the roles leave the project manager

Pulling the comparisons together, Scrum does not delete project management work so much as redistribute it. Nobody on the team is more important than anybody else - the three roles are all vital and they only create value for customers as a set.

Scope and prioritiesto the Product Owner

→

How the work gets doneto the self-organising Development Team

→

Process, events, impedimentsto the Scrum Master

→

Budgets, risk registers, Gantt chartsto a project manager, if the company still needs them

The project manager most often becomes the Scrum Master, but the traditional artifacts and the scope authority do not travel with them.

Revision summary

One-minute recap

Agile is the philosophy, Scrum is a framework that materialises it. Scrum predates the Agile Manifesto and helped inspire it, so do not use the two words interchangeably. The name comes from rugby.
The Scrum Guide is the source of truth, free at Scrumguides.org. Scrum is a framework for developing, delivering and sustaining complex products and for addressing complex adaptive problems while delivering the highest possible value. Few rules, easy to understand, hard to master.
Empiricism is the theory: knowledge comes from lived experience, not prediction. Work iteratively (repeated timeboxed cycles) and incrementally (chunks that build on each other, each instance being an increment), and treat every iteration as a mini experiment.
Three pillars: transparency, inspection, adaptation. Make the significant work visible to everyone accountable, check in time to catch undesirable variances, then adjust the project, product or process, including changes that stop future projects repeating the mistake.
Five values: commitment, courage, focus, openness, respect. The values are what make the pillars real - openness and focus deliver transparency, courage and respect deliver inspection, courage and commitment deliver adaptation.
Mission says why the work is being done and stays constant; product vision says what the finished work looks like and where the team’s boundaries are.
Three roles. Product Owner owns the what and builds the right thing; Development Team owns the how and builds the thing right; Scrum Master owns the when and builds the thing fast. Boundaries are soft and the whole team collaborates.
Scrum Teams are three to nine people, cross-functional and self-organising. Any manager sits outside the team and supplies strategy and career development, never task assignment.
Scrum Master is accountable for establishing Scrum and for the team’s effectiveness: coaching, facilitating events inside their timebox, removing impediments, shielding the team, and pushing towards Increments that meet the Definition of Done. They lead by influence, not authority.
Product Owner is the voice of the customer and maximises product value: owns the Product Goal, creates and prioritises Product Backlog items, keeps the backlog transparent. Customer-focused, decisive, flexible, optimistic, available, collaborative.
Development Team creates the Sprint Backlog, holds to the Definition of Done, adapts its plan daily towards the Sprint Goal, holds itself accountable, and designs, builds and tests in increments. Co-location helps but video conferencing is a workable substitute.
Versus traditional PM: scope moves to the Product Owner, and the Scrum Master neither manages scope changes nor maintains Gantt charts. The two roles overlap on stakeholder management. At Google and elsewhere, product scope may belong to a separate product manager, so check how any new company splits it.
Artifacts so far: Product Backlog (single authoritative source of everything the team works on), Sprint Backlog (the items chosen for the coming Sprint), Increment (each usable instance of the product).

Next: Implementing Scrum → - the backlog, estimation, the five Scrum events, and the tools that track a Sprint.