Process Tailoring, Hybrid Models, and Project Pre-Mortem

Process tailoring — a critical component of process improvement: modifying the team's current processes to fit the actual needs of the project, rather than following a fixed, repeatable process regardless of fit. Like a plan, a process needs to evolve as the team learns more about the project and its environment. Different projects genuinely need to be handled differently — a two-person badminton doubles team and an eleven-person football team both compete, but nobody expects them to run the same playbook; a two-person feature team and an eleven-person platform team shouldn't either. The goal is to streamline work to be as efficient as possible, minimize work-in-progress, and eliminate waste — not to preserve a process for its own sake.

Process tailoring is explicitly something a mature team does, not something a brand-new team should rush into — a team still learning the basics of a methodology needs to actually perform it successfully first before it has the experience to know what to safely change.

Blended Agile — combines processes and tools from two or more agile methodologies to make sure the project is using exactly what it needs. ScrumBan blends Kanban boards and WIP limits into Scrum's sprint structure. ScrumLean focuses on waste reduction while still following Scrum's events and roles. Disciplined Agile Delivery (DAD) deliberately draws practices from Scrum, agile modeling, Lean software development, and others into one toolkit.

Hybrid Model — in the stricter sense, this blends agile with traditional/waterfall practices rather than blending two agile methods together: AgileFall, ScrumFall, WaterSprint, and WAgile are all named variants along this continuum, running from plan-driven/low-frequency-delivery on one end to fully agile/high-frequency-delivery on the other. In practice, "blended agile" and "hybrid model" are often used interchangeably — don't over-invest in memorizing a strict boundary between the two terms; focus on recognizing that both exist to mix approaches deliberately rather than defaulting to "pure" anything.

Project Pre-Mortem — a facilitated team activity where the team imagines, in advance, that the project has already failed, and works backward to identify what caused that failure. The exercise surfaces potential causes of failure and risks the team might not otherwise think to plan for, and ends with the team preparing a concrete plan to mitigate or eliminate those causes before they ever happen. It's effectively a retrospective run in reverse, before the work has even started, rather than after something has already gone wrong.

Study focus: a pre-mortem is a proactive risk-identification technique used at the start of a project; it is not the same tool as a retrospective (end of an iteration) or an intraspective (triggered by something going wrong mid-iteration) — all three ask "what's going wrong/could go wrong," but PMI expects you to match each one to its specific point in the project timeline.