Session Plan
Session Outline
Lost at sea
What is project management?
What is Agile (basic principles and values)?
Basics of Scrum
Simple project setup
Simple prioritisation
Note: This module is in Foundation, which means trainees are not becoming specialized developers yet. The above topics should be kept high-level, focusing on the principles rather than deeper details. For example, it's good to explain that a principle of Scrum is that decisions are made based on data, but there is no need to go into the depths of calculating velocity and burndown charts at this point. These full details should be covered more in the specialization courses.
Exercise: Lost at Sea
Purpose: Experience working under pressure, dealing with sudden change, and making group decisions under stress.
Time: 45 minutes total
The Scenario
You have won the lottery! To celebrate, you decide to take three or four teammates on a fancy holiday. For that you've chartered a yacht, sailing together across the Atlantic Ocean. Since none of you have sailing experience, you hired an experienced captain and two crew members.
Unfortunately, in the middle of the Atlantic, a violent fire breaks out in the ship's galley. The captain and crew disappear. Most of the yacht has been destroyed and the boat is slowly sinking.
Your location is unclear, after all you were busy partying, and the navigation tools and radio were damaged in the fire. Your best estimate is that you may be several hundred kilometers from the nearest beach to land.
You and your friends managed to save 15 undamaged items after the fire. You also saved a four or five-person lifeboat and a box of matches.
Your task: Rank the 15 items in order of importance for your survival while waiting to be rescued.
The 15 Items
A sextant
A small mirror
A mosquito net
A 25-liter container of drinking water
A case of army rations
Maps of the Atlantic Ocean
A floating seat cushion
A 10-liter can of oil and fuel mixture
A small transistor radio
2m² of opaque plastic tarp
A box of shark repellent
A bottle of rum (80% alcohol)
500 meters of nylon rope
2 boxes of chocolate bars
A fishing kit with rod
🔒 FACILITATOR GUIDE - TRAINEES: STOP HERE
The section below contains facilitation instructions and strategy. If you are a trainee, do not read further - complete the exercise first!
Stage 1: Individual Ranking (10 minutes)
Have trainees work individually to rank all 15 items from 1 (most important) to 15 (least important).
Script: "You have 10 minutes to work individually. Read through the scenario and the list of items carefully. Then rank them from 1-15 in order of importance for survival. Write your answers down."
Facilitation tips:
Circulate but don't give hints
Ensure everyone understands they need to rank ALL 15 items
No ties allowed - every item must have a unique ranking
If everyone is done before the time limit move to the next stage to save time.
Stage 2: Team Discussion (15 minutes, but announced as 30)
Divide trainees into groups of 3-4 people
Have them produce a single ranking of the items per group.
Announce 30 minutes for discussion (this is intentional - you will change it!)
Emphasize unanimous decision is required
Start timer
Script: "Now you'll work in teams of 3-4 people. You have 30 minutes to discuss and agree on a single team ranking. You must reach a unanimous decision - everyone must agree. Write your team's ranking down."
⚡ THE TIME PRESSURE TRICK
CRITICAL - After exactly 10 minutes of team discussion:
Interrupt loudly and urgently:
Script: "STOP! I need to interrupt you - It appears to be that the fire got more violent . You actually only have 5 more minutes to finish and make your final decision. You need to agree NOW or your team has failed the exercise. Continue!"
What to observe during these 3 minutes:
How are decisions made?
Do quieter members get overruled in the rush?
Do teams make quick, forced decisions without real consensus?
Does anyone question or push back on the time change?
How does communication style change under sudden pressure?
Important: This sudden change is intentional and is the core learning moment. Don't reveal this beforehand!
Stage 3: Reveal Solution & Debrief (10 minutes)
Reveal the Expert Rankings
Navigate to: https://siderdk.github.io/lostAtSea/
You can display this page for everyone to see. The webpage shows:
The expert rankings from the US Coast Guard
The reasoning for each ranking
Automatic score calculator
If your score is lower than your team's you contributed to their survival, and vice versa :D
Lead Discussion
You can use some of these questions (or statements) to debrief the exercise and connect to Agile:
About the Time Pressure:
What happened when we suddenly changed the time limit?
How did your team respond to that change?
Did anyone feel stressed or frustrated? Why?
Did the quality of your decision-making change under pressure?
Did communication styles change? How?
About Decision-Making:
Was it difficult to reach unanimous agreement?
What led to disagreements in your team?
Did everyone's voice get heard equally, especially under time pressure?
Did some people dominate the conversation?
How did your team resolve conflicting opinions?
About Team Performance:
Did your team score better or worse than individual scores?
Was working as a team better or worse than working alone? Why?
What characteristics make a team succeed under pressure?
What would you do differently if you could do this exercise again?
Connection to Agile (MOST IMPORTANT):
In real projects, requirements change suddenly, just like the time limit changed without warning
Teams need to adapt quickly and communicate clearly under pressure
Unanimous agreement isn't always possible, sometimes you need to make a decision and move forward
Reflection Questions:
How well did you "respond to change"?
What parallels do you see between this exercise and real software development?
What is project management?
We organise projects to help provide some structure for a group of people to achieve some shared goal by working together.
Project management describes different best practices and approaches we can take to organising some work to avoid wasting time, effort, resources, money, and most importantly end up building the thing we started out to achieve.
Imagine you're about to go on a hike with a group of friends. Project management means you have a map and a plan before you set off, and to help you as you go on. You need to know:
What path you'll take around the mountain
What your end destination is
How you'll get there
What you need to pack
Who will carry what along the way
Without project management, even a clever bunch of people can go in the wrong direction, duplicate work, miss deadlines, or build entirely the wrong thing.
Good project management keeps everyone aligned, on the same page, tackles problems early, and gives everyone the best chance of achieving the shared goal together.
What is Agile
In project management, it's easy to go overboard. Planning every tiny detail of every project up front before actually getting started. This approach is often referred to as Waterfall, since you must complete each step of a project before moving onto the next (e.g. planning, designing, building, testing, delivery). In reality, projects rarely work that way. Lots of details change as you go, as you learn more of how something should work or look. And it's rarely a good idea to leave testing until you've finished building everything!
Agile is a way of working that was born out of a frustration with traditional project management (that followed the Waterfall mentality).
Agile aims to help teams build things in small steps, learn as they go, and adapt when things change. At its core, Agile is about people, collaboration, and delivering value early and often. It helps you avoid following strict processes or writing long plans up front.
Imagine you're steering a boat over a huge ocean. You can't know exactly how the weather will be, so you can't make an accurate plan for the whole journey. Instead, you keep moving forward, regularly checking the weather, your direction, and adjusting your course as needed. This is the Agile approach!
The 4 Agile principles
Agile was formalised in the Agile Manifesto in 2001 by these core principles, and they are still valued today.
Individuals and interactions over processes and tools
Great teamwork and communication matter more than having the “perfect” tool or following every process step.
Working software over comprehensive documentation
The most important thing is to deliver something that actually works, and avoid spending too much time writing lots of plans.
Customer collaboration over contract negotiation
Working closely with customers throughout the project is more important than delivering just what they agree on at the start.
Responding to change over following a plan
Plans are useful, but things change. Be open minded to new ideas, feedback and issues that arise, rather than stubbornly sticking to a plan.
Exercise: Draw a Rocket
Purpose: Demonstrate the difference between a waterfall and agile approach, showing how feedback and iteration improve results.
Time: 10 minutes
How it works:
Ask for a volunteer to be the "customer" and ask for a rocket to be drawn
In Waterfall style: The "artist" (mentor) draws a rocket without showing the customer until it's finished. The requester gives feedback of what they like/don't like at the end.
In Agile style: The "artist" (mentor) shows progress as they go (first the body, nose tip, wings, windows, flames etc.), asking questions and getting feedback during each step.
Compare the results. The Agile version should fit the customer's vision a lot more closely. Discuss what happened, which turned out better and why.
Basics of Scrum
Agile is a useful mindset, but it doesn't actually give you any clear instructions on how to run a project. That's where Scrum comes in.
Think of Agile like the philosophy of healthy eating, and Scrum is a specific diet plan to achieve it.
Scrum is defined by some principles, specific roles, specific meetings and "artifacts". We will only go over the basics here, for what you'll need to understand to run your own first project.
The Sprint
A sprint is a short, fixed period of time (usually 1–4 weeks) where a team focuses on completing a small, specific set of tasks that work towards a bigger goal. The outcome from a sprint should be a working version of the software - in other words, you should aim to finish something specific!
The Backlog
This contains a list of tasks that you need to complete as part of the project. It is split into two parts, the "product backlog" which contains the full list of tasks, and then a "sprint backlog" which contains the list of tasks that you plan to work on in the next sprint.
Simple project setup
Let's see what a basic Scrum project might look like in real life!
What we need:
A place to define tasks
A list of tasks to complete
A way to visualise them, so we can see their status
Demonstration
Walk through the process of setting up a new board on Trello. Make sure to include:
A product backlog
A sprint backlog
In progress and Done columns, too
An example task
Visually demonstrate how the task moves through the board
It should look something like this: 
Exercise: Setting up Trello
Purpose: To practice setting up a project from scratch
Time: 10 minutes
Trainees should now register and set up their own Trello board. It should mirror what has already been demo'd in the session.
We'll now plan your next birthday party! Add the following tasks to the product backlog:
Buy decorations
Order the birthday cake
Send out invitations
Book the venue
Choose and buy party snacks
Plan the playlist / music
Plan the date
Notice anything? They order doesn't seem to make sense!
Prioritising tasks
If you plan of all the tasks you need to complete in a specific project, the list could be very long! And it can be hard to work out where to start.
There are many techniques you can use to help ordering the tasks into a prioritised list. We'll start simple with a method called Now/Next/Later:
Now: We need to do these first.
Next: These are also important, so we'll come to them shortly.
Later: These could be good ideas, but they're not important right now.
How will we visualise that on the board? There is no right answer, as long as it's clear. But here is one way to do it: 
Exercise: Prioritising birthday tasks
Purpose: Practice prioritising a list of tasks using Now/Next/Later.
Time: 10 minutes
With the person next to you, go through the birthday party tasks, and decide which ones should fit into which category. Order your product backlogs so the Now tasks are at the top, followed by the Next, and finally at the bottom the Later tasks.
Finally, get ready to start your first sprint. Move all of the Now tasks into your sprint backlog!
Discuss the order and any differences between people's decisions in the whole group.
Last updated