Gale sprints¶

Gale sprints are short, focused, and slightly uncomfortable. That is the format on purpose.

A sprint compresses a task that normally expands to fill whatever time is available, and asks what can actually be done in a fixed, shorter period. The answer is usually more than expected, with the qualification that it requires being ruthless about what not to do, which turns out to be where most of the learning lives.

Sprints can be run solo. Pick one thing from this list, set a timer, do only that thing for the duration, stop. Repeat as the tide allows. The sprint format works for self-directed learning in exactly the way that open-ended I should really work on this time does not, which is a gentle observation that will be recognised by anyone who has had that thought on a Sunday evening and then not acted on it until the following Sunday.

Patch sprint¶

Imagine a ship with twelve known leaks, limited time in port, and a crew that has other things to do. You cannot fix all twelve. Which ones sink you if left unpatched, and which ones can be bailed?

This sprint takes a realistic environment with a set of known vulnerabilities and a simulated threat that is actively working through the vulnerability list while the patching is still in progress. Teams assess, prioritise, and patch. The time pressure is not the sprint deadline. The time pressure is the thing that is already moving.

The prioritisation is the point. In a world with unlimited time and resources, you patch everything in order of severity, thoroughly. In the world where this sprint takes place, triage is a skill. Which patch is worth doing quickly and imperfectly versus which needs to be done right even if it takes longer? What do you do if patching one thing breaks something else, which it occasionally will, at the worst possible moment?

Teams that finish the sprint with everything patched and nothing broken should be mildly suspicious that the scenario was not realistic enough.

Get everyone aboard¶

MFA rollout sprint. Eighty-three per cent of accounts are covered. The remaining seventeen per cent are a mixture of: someone who is definitely going to do it next week, a shared account that nobody knows how to handle, two service accounts that IT is slightly afraid to touch, and a volunteer who has a 2015 phone and a strong opinion about not changing things that work.

The sprint starts with that seventeen per cent. Participants work through the list, assess each case, and by the end of the session have either resolved it, documented a time-limited exception with a named owner and a review date, or escalated it with a specific question rather than a vague problem.

The point is not to achieve perfect coverage in two hours. The point is to establish that the remaining gaps are known, named, and tracked, which is an entirely different situation from knowing that there are probably some gaps out there somewhere, which is the situation at the start.

The volunteer with the 2015 phone is a solved problem, by the way. The solution is a phone call, a bit of patience, and a willingness to find the method that works for that specific person rather than the one that is easiest to document. It takes longer than clicking a button and produces a more reliable outcome.

Charting what nobody charted¶

Documentation sprint. Before the next person can fix anything, they need to know what exists. This sprint is about producing that knowledge in written form, for one specific part of the environment, in the time available.

The scope is deliberately narrow. Not all integrations: the three integrations between the CRM and the financial system. Not the whole application landscape: the five sector-specific tools and whether they have SSO configured. Not all admin accounts: the admin accounts for the six most critical systems and whether the passwords are stored somewhere sensible.

Narrow scope, real output. The documentation format can be a spreadsheet, a text file, a diagram on a whiteboard that someone photographs. The format does not matter. The content needs to be findable by someone who was not in the room when it was produced.

The sprint ends with one question: could a new person use this to understand the thing it documents without asking anyone for help? If yes, it is done. If no, what is the single most important gap, and can it be filled before the timer runs out?

Cast a light on the shore¶

Security awareness content sprint. One scenario. One audience. One piece of material that is actually good.

Not a slide deck for a training session that will be scheduled for some time in Q3. One thing: a real phishing simulation for the upcoming all-staff day, or a one-pager for a volunteer induction folder, or a five-minute briefing for the next team meeting. The audience is specific. The scenario is realistic. The tone is human.

The sprint produces the finished material, not a draft. A draft needs another session to complete, which means it often does not get completed, which means it joins the folder of things that were almost done and then were not.

Participants who have never produced security awareness content before tend to discover two things during this sprint. First, it is harder than it looks to write about a real threat without being either condescending or alarming. Second, the best materials are the ones where the writer clearly remembered what it was like not to know this yet.

That second one is the skill. The first one is just practice.