Assignment 1 — Agile Mindset & the PM Role

The Agile Manifesto states four values, each expressed as a preference: something is valued more than something else. State all four values precisely. Then pick one and explain — in a concrete, specific situation — how a PM who genuinely holds that value would make a different decision from a PM who does not. Do not describe the value in abstract; describe the decision.

In Agile, a piece of work is only truly “done” when it meets four conditions simultaneously: it is working, tested, accepted by the Product Owner, and potentially releasable. For each condition, explain in one or two sentences what specifically goes wrong on a real team when that condition is missing — not what the condition means in theory, but what the practical failure looks like. Then write a concrete Definition of Done for a user story on a web application team. Make it specific enough that two different developers would always reach the same verdict on whether a story meets it.

Agile teams measure success by outcome — the change created for users — rather than output — the volume of things produced. Explain the distinction clearly in your own words. Then consider this situation: a team delivers a product on time, on budget, with every feature in the specification shipped. Six months later, analytics show that 80% of users only ever use two of the fifteen features delivered. By traditional PM standards, was this project a success? By Agile standards? Justify both answers.

Session 2 describes how the PM role shifts in Agile: from commanding tasks to enabling people. List three specific behaviours that characterise the traditional command-and-control PM, and the corresponding Agile behaviour that replaces each one. Then answer this: the Agile PM role is sometimes described as “less work.” Make the case that it is in fact more demanding — not less — requiring more skill, not less authority.

You are the project manager on a six-month software project for a logistics company. You are now at month four, running on a traditional plan. Your team has spent three months building a core dispatch module to an agreed specification. Today, your biggest client calls: they are changing their warehouse layout and the core dispatch logic in the spec no longer works for them. Your sponsor says: “We have to accommodate this — they are 40% of our revenue.”

You have two tasks. First, describe the situation you are now in — specifically what it costs you to change course at month four, and why. Second, describe concretely how this situation would have looked different if your team had been running two-week Agile iterations from day one: at what point would the client’s constraint have surfaced, what would the team have been able to do about it, and what would not have been lost?

You have just joined a product team as a PM. In your first week you notice: the team does a 15-minute standup every morning, they use Jira to track tickets, and the team lead describes the team as “fully Agile.” But you also notice: every new feature begins with a detailed requirements document that takes two to three weeks to write; development cannot start until the client has formally signed off the spec; and when a client requested a change mid-build last month, it went through a four-week change-control process.

You need to raise this with your manager. Write the key points you would make in that conversation. Identify which Agile value or values this approach contradicts, explain why the contradiction matters in practice (not in theory), and describe two or three specific changes you would propose to make the team’s process genuinely Agile — not just labelled as such. Be realistic: you have no authority yet and need to persuade, not mandate.

You are a Product Owner. Your team is starting a new two-week Sprint next Monday. Below are eight backlog items. You can only take four into this Sprint. Using the six prioritisation factors from Session 2 — business value, risk, stakeholder need, dependencies, effort vs. value, and learning value — select your top four and write one to two sentences justifying each choice. You do not need to justify the four you excluded, but your justifications for the four you chose should implicitly make the trade-offs clear.

Your company has two teams that need a new way of working. You have been asked to recommend either Scrum or Kanban for each, and to justify your choice.

Team Alpha is building a new mobile banking app from scratch. Requirements are still evolving based on user research. The team of six will need to work closely with the product stakeholder, show progress regularly, and deliver a launchable product in roughly six months. Work is complex and interconnected — features depend on other features.

Team Beta is a four-person IT support team handling incoming infrastructure requests from across the business. Requests arrive unpredictably throughout the day — some critical, some minor. The team struggles with too many things “in progress” at once and frequently context-switches before finishing what they started.

For each team: state your recommendation, explain the two or three specific characteristics of that team’s situation that make your chosen framework the better fit, and identify one risk or challenge the team should be aware of when adopting it.

Think of a project, team, or process you have been part of — at work, at university, or in any organised activity. Describe one specific moment where feedback came too late, or where the team could see that something was wrong but could not change course. What was the situation? Why couldn’t the team adapt? What was the concrete consequence? And — this is the important part — what structural change (not just a cultural one) would have made earlier feedback possible?

Session 2 describes the Agile PM as someone who creates conditions for the team rather than controlling the team’s execution. Think of a manager, leader, or teacher you have worked with — someone who, in your experience, genuinely enabled the people around them rather than directing them. What did they actually do differently? Be specific: describe two or three concrete behaviours, decisions, or moments. Then reflect: which of those behaviours would fit the Agile PM role as described in this session, and which — if any — would not?