Leadership Academy — Week 6 Assessment Practice
Practice scenario and analysis questions for Week 6 — agile leadership, ownership, MoSCoW, and deciding under pressure — with model answers.
Part of the Leadership Academy series — practice questions to go with the Week 6 study guide.
Q1 (scenario). You notice a risk to a deliverable early, but you’re not fully sure yet whether it’ll actually become a problem. Do you raise it now, or wait until you’re sure?
A1. Raise it now. Ownership means proactively surfacing risks before they become problems, and escalating while still uncertain — framed as informing or asking for help — gives the other person time to respond. Waiting until you’re certain is the most common ownership failure, not a more careful version of doing it right.
Q2 (analysis). Two senior stakeholders both believe they have final say on a decision, and each has separately approved a different, conflicting approach. What’s wrong, and how do you fix it?
A2. A RAPID violation — the Decide role was never assigned to exactly one person, and RAPID explicitly fails when Decide is shared. Fix: assign a single named Decide-owner going forward, and reclassify the other stakeholder as Agree (if their sign-off is genuinely required) or Input (if their view should inform it but not vote on it) — then communicate the assignment explicitly to both.
Q3 (scenario). You have a client proposal due today and a P1 defect from a different client at the same moment. Both are yours. Walk through how you’d handle it.
A3. Take charge first rather than freezing on “both are urgent.” Weigh actual gravity, not just surface urgency: a P1 defect is usually harder to reverse and more squarely your direct accountability than a proposal, unless the proposal’s deadline is genuinely minutes away. Delegate what can genuinely be delegated — ask someone to review the proposal draft while you handle the defect. Communicate proactively rather than going quiet — tell whoever’s expecting the proposal immediately what’s happening and offer a concrete alternative. If the fix forces a scope trade-off, apply MoSCoW: a Could or Should never delays a Must.
Q4 (scenario). A leader is asked, without warning, “what’s the most important thing your team needs to deliver in the next two weeks?” They answer with a specific task that’s due. What’s the gap in this answer?
A4. The answer names an output (a task getting finished), not an outcome (what needs to actually be true once it’s finished). Agile leadership’s second meaning is owning outcomes, not tasks — a stronger answer names the result the task is supposed to produce, not just the task itself.
Q5 (analysis). A leader commits to a customer that something will be done in two hours, without actually knowing whether that’s true, because the moment felt like it needed an answer. What principle does this violate, and what should have happened instead?
A5. Violates “embrace uncertainty explicitly” and the decision-quality-under-pressure rule. The honest version is “I don’t know yet, but I’ll find out,” not a confident guess. If this specific commitment is hard to reverse once made, it should also have gotten a ten-minute pause and a second opinion before being said out loud.
Q6 (scenario). You’re allocating work across your own team and trying to decide the Must/Should/Could split. Should this be a fully collective team decision, entirely your call, or something else?
A6. Neither extreme — for internal team allocation, the leader proposes and owns the segregation, ideally with the team present, but shouldn’t be “too defensive” and treat it as something that must always be fully collectively negotiated. Contrast: for a customer’s own requirements, the customer decides what’s a Must for their ask — your job there is to bring an honest picture of scope, timeline, and resourcing to that conversation.
Back to the series index · Week 6 study guide