Agile 4 - Applying Agile
Google Project Management Certificate · Course 5: Agile Project Management
By the end of Module 3 the team could run Scrum day to day: a backlog of user stories, estimates, the five events, velocity and burndown charts. That is the machinery. This last module steps back from the machinery and asks what it is all for, and what happens when you try to use it inside a real organisation with real people, shifting plans and a job market to get through.
The thread running through it is value. First, how a team keeps its attention on value rather than on output, and the roadmap artifacts that make that possible. Then the messy part: changing a plan without losing control of it, introducing Agile to an organisation that may not want it, coaching a team through the change, and spotting the warning signs when things go wrong.
The module closes with the wider view: how Agile has spread and evolved since 2001, the frameworks that stretch it beyond a single team, and practical advice for interviewing for an Agile role or bringing Agile back to your current team.
Value-driven delivery
Section titled “Value-driven delivery”Value is whatever the end product actually gives the user, and it differs by customer depending on what they expect the product to achieve. The course gives three examples: financial benefit, user growth and engagement, and compliance adherence.
Value-driven delivery means the team’s attention sits on producing a product of high value. Shipping something is not the same as shipping something valuable. This is the original problem Agile answered: teams were so absorbed in process that nobody judged usefulness until the product had already been handed over. Agile turns the focus around, so the product comes first and the process exists to serve it. It links straight back to the first Agile principle, satisfying the customer through valuable delivery (swap software for product or solution outside tech).
Three moves to deliver value
Section titled “Three moves to deliver value”The terms build and run come from software, and for other projects you can read them as create, produce or deliver.
| Move | What it means | Virtual Verde example |
|---|---|---|
| Build the right thing | Go past the stated request to the goal behind it. A customer asking for a website may really want brand recognition or more customers, so have a solution-oriented conversation. The value individuals and interactions over processes and tools reaches customers and users as well as the team | Survey current and potential customers on plant preferences and home office styles, then update the user stories in the Product Backlog |
| Build the thing right | Stick to requested or approved features. Extras add complexity with no user value, delay or shrink the value at delivery, and raise the risk of bugs later | Secure a trusted vendor for the right plants, work with designers on pots and vases in the preferred styles, and get marketing to feature them on the website and in the catalogue |
| Run it right | Think through how users interact with the product after delivery: how they get support, how the product keeps adding value, how new features reach existing users | Follow-up satisfaction surveys on offerings, delivery times and plant quality, feeding vendor and marketing decisions, plus extras such as watering cans, automatic plant health systems or free monthly gardening tips |
Reading a case study
Section titled “Reading a case study”The module sets a case study on Penta, a construction software company that formed an Agile task force to solve problems with Scrum teams. The case itself sits behind a link and is not in my source, so what I have is the reading method. A case study is an in-depth, data-driven analysis of a business, community or organisation, and it is worth reading for the problem, its effect on the organisation, and the pros and cons of the solution. Questions to ask while reading:
- What is the issue, and what is the goal of the analysis?
- What is the context of the problem, and which key facts matter?
- What alternatives does the decision-maker have?
- What would I recommend, and why?
For Penta specifically, the prompt was to notice how the roles mattered and how people from across the organisation came together to generate ideas, test and analyse.
A technical program manager on flexibility
Section titled “A technical program manager on flexibility”Camron, a Google technical program manager (a program manager with enough technical background to take part in technical conversations and decisions), likes Agile most for its flexibility. You make most decisions at the start, when you know least, so some will be wrong, and Agile builds in chances to change them as you learn.
His contrast with Waterfall is about when value arrives. Waterfall hands everything over at the end, so the customer waits days, months or years before getting anything out of it. That suits a house or a car, where a partial product is useless or unsafe. For work with a hard final problem, Agile means you do not hold back the whole project for the last piece: ship the 90 percent that works, let people use it, and release the last 10 percent later.
The value roadmap
Section titled “The value roadmap”A value roadmap is an Agile way of laying out the timeline and requirements of product development, usable in any kind of business. It works as a guide to where you are going, how you get there and what you achieve on the way to maximise value. As the team follows it, it collects input from customers and stakeholders and feeds that into each iteration. It also helps explain the product vision and pick out key milestones.
A project usually has several releases before it counts as done, and only the first release date should be treated as fixed. Everything after it rests on early estimates and will move.
A release plan contains:
- A release goal, the overall business goal for the features in that release.
- The backlog items needed for that goal, such as epics, user stories or features.
- An estimated release date.
- Any other dates that affect the release, such as a convention or a major holiday.
All release plans belong on the value roadmap. And the whole thing only works if the team is collaborative and stakeholders keep working with it regularly.
Types of roadmap, benefits and pitfalls
Section titled “Types of roadmap, benefits and pitfalls”Companies interpret roadmaps differently, so you will meet project, product, value, Lean and Agile roadmaps. They are usually visual, often squeezed onto one page (for example bars across four quarters) so reviewers see the whole timeline at once.
- Makes the order of deliverables clear
- Shows teams how their effort connects to the north-star vision
- Shows stakeholders value arriving incrementally, not as one delivery at the end
- Gives stakeholders a rough picture of the work behind a deliverable
- Letting stakeholders treat it as fixed, so they block adaptation and push deadlines at any cost
- Polishing delivery dates instead of keeping them rough and sharpening them as they approach
- Pouring effort into the roadmap rather than the deliverables
Best practices: keep it prominent and refer to it often, mark the highest priority items and, where possible, the highest value items, share it with the wider stakeholder group for their own planning, and review it regularly with sponsors, stakeholders and the team to check it still works as the project’s blueprint.
Tips for an effective value roadmap
Section titled “Tips for an effective value roadmap”-
Keep release dates on the product roadmap rough. They may be months or years away, and a roadmap that is too specific sets the team up to fail on dates nobody can guarantee.
-
Build each release plan jointly. The Product Owner and the project manager or Scrum Master must connect the roadmap to the team’s capacity and velocity. A plan that ignores what the team can actually do is unrealistic and breaks the sustainable pace principle.
-
Factor hard deadlines in and communicate them. For Virtual Verde, an Office Green décor convention in October is a fixed launch date for the first phase. Agree the must-have features with stakeholders so that, if the date is at risk, the team knows what to focus on.
-
Treat the release plan as a living artifact. Having one does not contradict responding to change over following a plan. It changes when team velocity changes (people joining or leaving, or efficiency gains), when the Product Owner approves a scope change, or when the team learns a story or epic is harder or easier than it thought.
-
Review the release plan before every Sprint Planning. The Scrum Master or PM checks the team is on track. If not, they have an open conversation with the Product Owner and business people about what to adjust, which is where transparency matters.
Responding to change over following a plan
Section titled “Responding to change over following a plan”Module 1 introduced this as one of the four values. The reading turns it into a procedure for changing a release plan, in three stages.
Stage 1: identifying a needed change
Section titled “Stage 1: identifying a needed change”The triple constraint from earlier courses works as the lens here, in Agile as in traditional projects. Anyone can spot a needed change: Product Owner, project manager, Scrum Master or the Development Team.
| Constraint | In an Agile project it covers | Example trigger |
|---|---|---|
| Scope (the what) | Product roadmap contents, Product Backlog items, intended deliverables, intended users or customers | Customer feedback on early prototypes adds some features and removes others |
| Time (the when) | Roadmap timeline, release schedule, even Sprint length | Critical dependencies or deliverable dates shift, forcing a roadmap change |
| Cost or resources (the how) | Development Team makeup, PMs, Product Owners, other business people, equipment | A Sprint Retrospective reveals understaffing |
Stage 2: deciding to make the change
Section titled “Stage 2: deciding to make the change”Most decision-making models share the same basic steps:
- Name a single decider, usually the Product Owner or a senior stakeholder, for consistency and accountability.
- Agree and share which factors matter, and gather the data that supports the decision.
- Discuss benefits and costs openly, flag uncertainties and capture assumptions.
- Document the decision.
Stage 3: implementing the change
Section titled “Stage 3: implementing the change”- Document the change and how it was decided: meeting notes, pros and cons, assumptions, data.
- Update every affected artifact (roadmaps, backlogs, staffing plans, integration dates) with a reference to the source of the change and a revision label such as version 1.2 or an updated-on date.
- Tell every affected stakeholder, through meetings, documentation and notes, or email announcements.
- Monitor the change for a while so you know the team is aware of it and supports it.
If the change is rejected, still record the information and reasoning. You can also park a change until more information lets you decide with more confidence.
Activity: Virtual Verde release plan emails
Section titled “Activity: Virtual Verde release plan emails”The activity puts me in the Scrum Master’s seat, receiving three emails from Office Green colleagues. For each one the template asks three questions: does the update need action and what are the options, does anyone need to be consulted, and is more information needed. If a release plan change is warranted, I then draft an email to the Scrum team (to, from, subject, body, closing).
| Exemplar verdict | Options, people and information | |
|---|---|---|
| March 25, content manager: June seasonal care emails done early, July to November content under way | No action. The first seasonal emails do not go out until June, so the release plan stands | None needed |
| April 10, vendor manager: the vendor database built in an earlier Sprint shows stock that does not match the warehouse and is losing invoices | Act now, but no major release impact expected. Email the team asking developers to work with IT, warning of a few days’ disruption | Options: IT fixes it fast, fall back to the old software, or track manually. Consult the vendor manager, developers and IT, and the warehouse operations manager. Find out how long the fix takes and how many invoices are missing |
| June 9, vendor manager: the Bonsai supplier stops stocking Bonsai at month end, weeks before the July release that features them | A likely change to Release 3. Email the team with the options, doubting a new vendor can be found in time and on budget, and suggesting a July launch with vegetables and gardening supplies, adding Bonsai in a later release | Options: find another Bonsai vendor, substitute a specialty plant, or launch without Bonsai. Consult the Product Owner (final decider), the vendor manager and the Development Team. Ask about other vendors, their cost and speed, the substitute plants and the website changes needed |
The lesson is in the contrast: not every update is a change, the decider for a scope change is the Product Owner, and the team email lays out options before a decision rather than announcing one.
Bringing Agile into an organisation
Section titled “Bringing Agile into an organisation”Employers will be Agile already, part-way through switching, or not Agile but ready. An entry-level PM is unlikely to lead a full transformation at a large company but may well support one, while a smaller company might hire you precisely to lead it.
Two ideas carry over from the earlier course on culture and change. Organisational culture comes from shared workplace values and shows in behaviour, activities, communication and how people work together. A change out of step with that culture is much harder, and research shows companies that ignore Agile’s cultural side are more likely to fail. Change management is the process of getting people to adopt something new, which for Agile is a whole value system. Unless the organisation has years of Agile behind it, expect a culture change that can take years.
Ownership and urgency
Section titled “Ownership and urgency”A sense of ownership and urgency lifts interest, motivation and engagement in the outcome.
| Lever | How to create it |
|---|---|
| Ownership | Find an executive sponsor who also feels ownership of the change. Tie the change to the company’s stated mission or values. Buy-in at the top improves the odds, and ideally the sponsor promotes Agile’s benefits and provides support and resources |
| Urgency | Ask the team, organisation and stakeholders what is and is not working, and link each change to those answers. For example: what stops us giving customers the best product, what lets competitors beat us in this market, how can our teams be more productive and supported |
The urgency questions do double duty: they help prioritise, and you can reuse them to gather feedback during the change and show incremental improvement, which is Agile in spirit. Virtual Verde did both. Urgency came from home office decorating becoming a hot online trend the CEO wanted to catch, and ownership came from a team experienced on the Plant Pals project and motivated to try a new approach.
The influencer change framework
Section titled “The influencer change framework”This framework comes from the book Influencer: The New Science of Leading Change by Joseph Grenny, Kerry Patterson, David Maxfield, Ron McMillan and Al Switzler. Course 4 already covered influencing without authority in general (leadership notes); what is new here is a structured model for changing behaviour across a team or organisation.
Being an influencer here means leading people to change their behaviour, hearts and minds for meaningful, lasting results. Influence is not persuasion: persuasion is short-term, influence lasts, and it needs people to trust you, see you as an authority and have confidence in your decisions. In organisational change, influence is the difference between a temporary shift in behaviour and a deep change in culture and values.
The three keys
Section titled “The three keys”-
Clarify measurable results. Know what you want, why and by when. Use SMART goals (specific, measurable, achievable, relevant, time-bound), check the why, and keep the measures visible to the whole team throughout.
-
Find vital behaviours. A vital behaviour is what someone does at a pivotal moment for the change. Example: a developer wanting more Product Owner involvement finishes a feature mock-up and, instead of moving on, emails it to the Product Owner for feedback. To find them, consult experts, scan well-cited research, or run a culture assessment of team norms, and study the people who succeed where most fail.
-
Use all six sources of influence. Using them together raises the odds, and you can weight them to your audience, since some respond to money and others to social impact.
The six sources of influence
Section titled “The six sources of influence”Each source pairs motivation (do they want to?) with ability (can they?) at three levels. The examples all continue the Product Owner involvement scenario.
- Do they want to do it themselves? Help them love what they hate
- Example: the Product Owner gives feedback that is timely, appreciative and useful
- Do they have the skills and knowledge? Help them do what they cannot
- Example: the developer can use the demo tools and email a quick video of the feature
- Do their contacts and networks encourage or discourage it?
- Example: developers remind each other at the Daily Scrum to email the Product Owner before finalising
- Does their network give them resources to do it?
- Example: a tool to track every demo sent to the Product Owner during the Sprint
- Are there rewards or incentives for the behaviour?
- Example: a coffee gift card Sprint award that the Product Owner hands out
- Does the environment help or hinder? Make the wrong behaviour harder than the right one
- Example: the content system pre-fills the Product Owner as reviewer
Helping the team improve: Agile coaching
Section titled “Helping the team improve: Agile coaching”The project manager or Scrum Master is the team’s designated Agile coach, helping it see where to improve and put solutions in place. The course frames it like coaching a sports team, in three steps.
Design the plays. The playbook covers how the team runs a Sprint Review, how it works day to day and how it publishes plans to stakeholders. Involve the team in every update, walk through new processes together, consider every position on the team and make sure everyone sees the flow. The instructor’s example: a brainstorm on which parts of the process were failing, sticky notes to group improvement ideas, then prioritising which to implement.
Provide feedback. Give it to the team and stakeholders as early as possible, every day, like directions from the sideline. Also take the view a coach gets from replaying the game video, looking for patterns to fix and for plays that worked so well they should run every game. Feedback is as much about keeping what works as fixing what is broken.
Celebrate and learn. Congratulate the team often, for a job well done, a happy customer or a big launch. When the team loses, meaning it missed a requirement, treat that as critical data for next time, and help it stay positive and see a learning opportunity. The course quotes Edison on finding 10,000 ways that did not work.
Coaching against managing
Section titled “Coaching against managing”Both belong in project management. The difference is communication: managing gives direction, coaching teaches. Course 4 looked at leading teams in a traditional setting; the Agile twist is that teams are meant to be self-managing, with the autonomy to decide how to do their work instead of being directed from above, and the confidence to solve problems themselves.
- Oversees others’ work: onboarding, running meetings, delegating, monitoring progress, making high-level decisions
- Keeps the team organised and on track, streamlines communication
- Right for an emergency needing immediate action, a missed deadline, or a client whose specific needs you know best
- Needed in results-driven work with little room for error
- Develops skills, motivation and judgement so people reach solutions themselves
- Offers guidance then steps back, asks questions, does not jump in during a crisis
- Builds trust, which raises satisfaction and quality of work
- Right for experienced people building new competencies or trying something new
Three coaching principles: motivate (point out the value in someone’s work and build pride in it), support (be an accessible resource for problems and ideas) and encourage and appreciate (acknowledge a heavy workload and reassure people they can handle it). Coaching helps when someone moves into a career-boosting new technology or discipline, when a person’s behaviour is quietly harming team dynamics, or when a team is recovering from a setback.
The worked scenario: a Scrum team misses customer needs Sprint after Sprint, the Product Owner keeps sending the same three features back for rework, and the team is deflated and burning out. Run a working session through all three principles: brainstorm positive reasons the customer is giving this feedback (motivate), capture ways to streamline the feedback loop such as a design Sprint with the customer present (support), and hold a fun, inclusive celebration of what the team has achieved so far (encourage and appreciate).
To choose a style, ask: what is the desired outcome, what is the skill level of the person facing the problem, and what does the situation need right now?
Challenges during an Agile change
Section titled “Challenges during an Agile change”As the coach, it pays to spot common problems before they arrive. The first set maps onto three of the four principle themes from Module 1: value delivery, business collaboration, and team dynamics and culture.
| Theme | Warning signs | Responses |
|---|---|---|
| Value delivery | Missed delivery dates and tasks taking much longer; burnout, long hours, exhaustion; too much work in progress so little reaches done | More demos against the value roadmap; ask in retrospectives what slows the team down (dependencies, communication); quick review so everyone shares the meaning of done; only a few user stories per Sprint so items finish together |
| Business collaboration | Team swamped by critical feedback or change requests after reviews; people avoiding feedback or grumbling about Product Owner requests; an us-versus-them mood with management, such as do not demo to sales, they will just find faults | More demos so feedback arrives at a steady pace and done is shared; a Solution Design Sprint, a whole Sprint on solution design with the team and business people sitting together; introduce backlog changes only between Sprints |
| Team dynamics and culture | Low morale, grumpiness and irritation; lots of unresolved conflict, resentment and grudges; and, surprisingly, too little conflict, which suggests people do not feel safe to disagree | Brainstorm how to work better, for example sharing stories of the best and worst team you have been on and turning them into do’s and don’ts; change workflows by pairing on hard tasks or reshaping a regular meeting; a training class or team-dynamics video to discuss; retrospective techniques such as Six Hats Thinking, where each person takes a hat with a different objective (positives, negatives, emotions) for a rounded discussion |
Two anecdotes stick. The instructor’s team is always tempted to overload Sprints, but fewer backlog items per Sprint delivered beats many items spread across more Sprints. And an engineering director who kept dropping by engineers’ desks asking for quick dashboards wrecked focus and velocity until he was asked to take requests to the Scrum Master so they could be planned.
Three more coaching challenges
Section titled “Three more coaching challenges”1. An unstable product roadmap. Roadmaps always change, but too much change destabilises them. There are two causes.
- Product leadership over-promises; a Product Owner keen to please stakeholders says yes too fast
- Example: the CEO wants Virtual Verde in Asia in four months, and the Product Owner agrees before asking the team
- Agree up front how new opportunities are reviewed, estimated and committed
- Hold roadmap reviews with the whole team at least quarterly
- Share knowledge both ways between Product Owner and Development Team
- Uncertainty forces assumptions, and too many put success at risk
- Example: which plants sell, which survive varied climates, which vendors to use
- Document assumptions and make them transparent
- As a team, accept them as safe or decide to check them
- Check with unbiased user research: surveys, focus groups or other objective data
2. Incomplete implementation of Scrum. Scrum’s roles, artifacts and events are designed as a set, so a partial or unsupported rollout reduces the benefits. It shows up three ways: blurred roles (a developer doubling as Scrum Master may do neither well, so fill each role with a specific person), skipped or merged events (without clear boundaries between Sprint Review, Retrospective and Planning, transparency, inspection and adaptation all suffer), and no coaching (which means the Scrum Master is not doing the job). The fix is to implement Scrum completely: connect each activity to the values (if people complain about stand-ups, remind them the purpose is feedback, unblocking, asking for help and Sprint goal focus) and make sure everyone knows their own role, their teammates’ roles and how they interact.
3. Lack of team stability. Frequent joiners and leavers make work unpredictable and break the flow. Responses: a quick onboarding process, pairing a newcomer with a colleague to learn on the job (which also means a partner can pick up the work when someone leaves), and shorter Sprints when people keep leaving, so they can finish a Sprint’s worth of work first.
The evolution and growth of Agile
Section titled “The evolution and growth of Agile”Agile’s popularity has grown fast since 2001. The course cites two figures: one industry report found 85 percent of organisations have adopted a product-centric model, which is associated with Agile, and the State of Agile report says 30 percent of those use a hybrid of methodologies. Blending methods is therefore a genuinely useful career skill. The driver is the VUCA world from Module 1, where Agile and its frameworks help organisations cope.
The Manifesto as a mindset has barely changed, but the frameworks it inspired keep evolving with business conditions.
| Direction | What the course says |
|---|---|
| DevOps | Combines software development and IT operations. Google Cloud defines it as an organisational and cultural movement to increase software delivery velocity, improve service reliability and build shared ownership among software stakeholders. It arose from the problem of running software reliably for billions of people, around the clock, and is about building teams that grow secure, reliable large-scale systems quickly |
| Business agility | A next frontier: applying Agile principles across management as a whole so the organisation thrives in high VUCA. It can mean rethinking financial planning, governance and reporting, hiring and HR, and more. Large organisations here may use Scrum of Scrums or SAFe |
| Beyond tech | Google sales in Latin America took Agile training to react to market shifts, valuing lower risk across the sales cycle through early feedback and frequent discussion with teammates and customers. Construction projects, per a PMI article, used Agile against delays and budget overruns by recasting the Manifesto in construction terms, such as minimising silos and encouraging close cooperation |
| Personal life | A Kanban board for planning a house move, a garage clear-out, a family reunion or a barbecue |
Practitioners who live the values are the ones who move Agile forward, which includes new project managers.
Scaling Agile
Section titled “Scaling Agile”A Scrum team tops out at about nine people. When the team or the product is bigger, you need a way to scale. Module 1 introduced the Spotify model as inspiration; this reading places it among five approaches and adds a sharper caveat about it.
| Framework | Core idea | Key details |
|---|---|---|
| SAFe (Scaled Agile Framework) | The most popular scaled framework. Lean-Agile, drawing on Kanban, Scrum, XP, DevOps and Design Thinking. Value above all: its first principle is take an economic view | Organises work and teams into Agile Release Trains built around value streams, such as sales. Mature, with detailed guidance, though some parts matter more than others, so check back against the Manifesto to keep agility. Core values: alignment, built-in quality, transparency, program execution, leadership |
| Scrum of Scrums | A technique for integrating several small Scrum teams on one product into a cohesive deliverable | At least 12 people split into Scrum teams of five to ten. Scrum of Scrums meetings weekly, twice weekly or daily, in Daily Scrum format but about each team: what the team did, problems affecting it, what it aims to do before the next meeting, whether it is blocked. Each team sends its Scrum Master or an ambassador, and a Scrum of Scrums Master looks after the process across teams. Sprint Planning, Review and Retrospective still happen. No official framework beyond this; teams need solid Scrum knowledge and design their own coordination |
| LeSS (Large-Scale Scrum) | Maximise Scrum teams’ ability to deliver value and cut waste in larger organisations. Grew out of more than 600 experiments | Two frameworks: Basic LeSS up to about 50 people, LeSS Huge for 50 to 6000 or more. Ten principles, listed below |
| DAD (Disciplined Agile Delivery) | A hybrid of strategies from Kanban, LeSS, Lean Development, XP, Agile Modeling and more. It guides the process decisions SAFe and Scrum of Scrums leave open, building a scaling strategy from context and desired outcomes | Four layers: Foundations (principles, guidelines, concepts, roles, team structure, Way of Working); Disciplined DevOps (safe, effective delivery with data and security first); Value Streams (alignment with business strategy, linking customers, sales and portfolio management); Disciplined Agile Enterprise (linking the marketplace with governance and wider enterprise activity) |
| Spotify model | Not a true framework and no standard guide: a description of how Spotify scaled by focusing on culture, autonomy, communication, accountability and quality | Squads of 6 to 12 with a coach and a Product Owner; Tribes of 40 to 150 with a Tribe Lead; Chapters that align specialists and set standards; Guilds as communities of interest |
The ten LeSS principles
Section titled “The ten LeSS principles”In brief: apply Scrum’s values to the bigger group; inspect, adapt and learn from experience; keep the project clear and accessible; add only the processes, roles and artifacts you truly need; make every part serve the whole product; keep customer needs central; improve product and process every Sprint; see the whole system without drowning in detail; improve continuously and respect people; and manage flow, queue size and multitasking.
Best practices for scaling
Section titled “Best practices for scaling”- Treat SAFe, Scrum of Scrums, LeSS and the rest as general frameworks, not instruction manuals.
- Mix and match across frameworks when the situation calls for it, as long as the Manifesto’s values and principles hold.
- Do not scale without prior Agile experience. Jumping from Waterfall straight to scaled Agile is risky without a knowledgeable guide.
- Most important: do not scale unless you must. Scale adds complexity and waste, so make sure the team understands Agile principles first.
Scaling ranges from simply pairing two Scrum teams in a Scrum of Scrums to training thousands of people in SAFe.
A Site Reliability Engineer’s view
Section titled “A Site Reliability Engineer’s view”Jez is a Google SRE, whose job is keeping Google’s systems up and reliable. For him Agile and DevOps are fundamentally about solving complex problems: split the big problem into chunks, deliver first the chunks that teach you most, and iterate. You learn both how to make users’ lives better and which process works best for doing it.
The big shift he has seen over about ten years is pulling the front end (planning) and the back end (release and operations) into the team, and making all of it relentlessly user-centred, a transformation he says is far from finished. His other point is the one people say but do not absorb: you will make a great many mistakes, especially when new, and you cannot learn without them. Do not expect to get it right first time, or ever.
Agile in job interviews and on your team
Section titled “Agile in job interviews and on your team”Job boards list these roles as Agile Project Manager, Scrum Master, IT Agile Project Manager or DevOps Project Manager. Choose a role that fits your experience level, complements your industry expertise and offers growth, with a culture that suits you and an employer that supports your goals and development.
What a Google hiring manager asks
Section titled “What a Google hiring manager asks”| Question | What the answer reveals |
|---|---|
| What is the difference between Agile and Waterfall? | Whether you know Agile is more than Scrum, Sprints and stand-ups, reaching founding values like customer collaboration, value delivery and self-organising teams. And whether you paint Waterfall as the worst option, or recognise that clear requirements, risk management and stakeholder awareness help every project |
| How do you know when to use an Agile approach or framework? | Whether you understand which specific project challenges Agile or Scrum solve |
| If your team resists a Scrum or Agile practice, how do you get them to try it? | Your communication and influence skills, and whether you really believe teams can self-organise. Google teams resist being told what to do because it can stifle innovation, so the manager hires PMs who work with the team rather than force a method on it |
Your own questions for the interviewers are a chance to test the culture, which you now know is critical to Agile success. Suggested ones: how supportive is management of blending project management approaches, what is the first thing I should know about the culture, how often will I hear about user or customer needs, and what would a typical day look like in this role?
Bringing Agile to your current team
Section titled “Bringing Agile to your current team”-
Start small. Your team may like things as they are, so introduce practices in bite-sized pieces, such as a Kanban board for a single workstream or a retrospective after a major milestone.
-
Listen to feedback. Listening and meeting the team where it is, is the PM’s most powerful tool. Ask how changes are going, collect ideas and fold them in, which amplifies small changes into big results.
-
Be strategic. Aim changes at today’s biggest problems. A team that estimates badly and lives in crunch mode might try relative estimation; too many voices on what the product should be might need a single Product Owner to keep prioritisation consistent.
-
Find allies. Build a network of Agile supporters for advice through setbacks and to keep you true to the values. Google has about 60 volunteer Agile coaches who lean on each other for ideas.
Revision summary
Section titled “Revision summary”Back to the course overview → - Course 5 ends here; the Course 5 glossary collects its vocabulary.