How Agile teams use short, focused investigations to reduce uncertainty and improve delivery confidence.
In Agile project management, a ‘spike’ is a short, time-boxed piece of work designed to investigate, research, or test something that’s not yet well understood. It’s a learning activity — not about delivering product features, but about gaining clarity and removing unknowns that could derail later development.
What Is a Spike?
A spike is essentially a mini-experiment that helps a team understand a problem area, validate an assumption, or evaluate potential solutions. The outcome is knowledge: a decision, a recommendation, or data that allows the team to proceed confidently.
Why Spikes matter
Projects often encounter uncertainty — around technology, integration, or business logic. Instead of guessing or delaying decisions, Agile teams use spikes to learn just enough to make informed choices. This prevents wasted effort and aligns teams on a shared understanding of the problem.
Common reasons to run a spike include:
Evaluating a new technology or library.
Exploring how to integrate with an unfamiliar system.
Testing performance or scalability options.
Clarifying ambiguous requirements or workflows.
How to Plan and Run a Spike
Spikes are deliberately lightweight but structured. They should have a clear goal, a fixed duration (typically one or two sprints), and a defined deliverable such as a short report, demo, or technical decision.
A simple planning checklist
Define the question — What uncertainty are you trying to resolve?
Limit the scope — Only explore what’s necessary to answer that question.
Time-box the effort — Prevent open-ended research.
Document findings — Summarise outcomes for the wider team.
When to Use a Spike
Spikes are most valuable when uncertainty blocks progress or threatens sprint predictability. They are also used at the start of new initiatives or when facing complex integrations. In hybrid or traditional environments, spikes serve the same role as feasibility studies — but faster, cheaper, and more focused.
Spike vs Proof of Concept
Spikes and Proofs of Concept both explore uncertainty but differ in scope and intent. A spike is usually smaller, time-boxed, and team-driven — its goal is understanding. A PoC, on the other hand, is a more formal validation effort, often involving stakeholders or sponsors, proving that a concept or technology can work. Many successful PoCs begin as spikes that uncover the key unknowns.
When a Spike becomes a PoC
Sometimes, what starts as a spike evolves into a full Proof of Concept when early findings reveal potential but need wider validation. Teams should formalise this transition by defining success criteria, documenting lessons learned, and ensuring sponsor alignment before scaling.
Summary
Spiking is a disciplined way to manage uncertainty. By running short, focused investigations, teams replace assumptions with evidence and make better decisions. It’s one of the quiet strengths of Agile project management — fast learning that keeps projects on course.
Scale model of Sir Christopher Wren’s design for St Paul’s Cathedral, built in the 1670s to visualise form and proportion before construction.
How early models help teams test ideas, reduce risk, and accelerate delivery.
In modern project management, prototyping is no longer a niche engineering activity — it’s a practical discipline used to reduce uncertainty, clarify requirements, and speed up delivery. Whether you’re developing a new app, service, or process, building something tangible early on helps bridge the gap between concept and execution. A prototype provides stakeholders with something to see, touch, and critique, transforming abstract requirements into actionable feedback.
What Is Prototyping in Project Management?
A prototype is an early, simplified version of a product or system that demonstrates key features or functions. In project management, prototypes serve as communication tools between teams and stakeholders. They can validate assumptions, expose design flaws, and encourage collaboration long before full-scale production begins. Prototyping supports iterative development by allowing feedback loops within each project phase. It’s widely used in software development, manufacturing, engineering, and service design. Depending on the project’s scope and complexity, prototypes can be physical (models or mock-ups) or digital (simulations or wireframes).
Why Prototyping Matters
Projects often fail because of unclear requirements, communication gaps, or late discovery of technical problems. Prototyping mitigates these risks by moving from theory to practice early. It encourages experimentation, supports design thinking, and makes invisible issues visible before they become expensive mistakes. A prototype helps teams answer key questions: Does the concept solve the user’s problem? Can the system be built with available technology? Are we aligned with stakeholder expectations? By testing, refining, and retesting ideas, teams can reach confidence faster and more efficiently.
Skunk Works
SOURCE: Lockheed Martin – Skunk Works Logo
The term ‘Skunk Works’ originated at Lockheed Martin during World War II, describing small, semi-autonomous teams tasked with developing advanced prototypes under extreme time pressure. The concept has since become shorthand for focused innovation: minimal bureaucracy, empowered teams, rapid iteration, and secrecy. Many modern innovation labs and Agile ‘tiger teams’ borrow from this approach — combining freedom with accountability to produce breakthrough results.
Choosing the Right Prototyping Approach
Selecting a prototyping model depends on what the team needs to learn or prove. If requirements are ambiguous, a throwaway prototype is best for discovery. When uncertainty lies in technology or performance, functional prototyping offers insight. Evolutionary and incremental models suit longer-term development or when a prototype will become the final product.
Types of Prototyping Models
Different types of prototyping serve different purposes. Choosing the right approach depends on the level of requirement clarity, the project’s complexity, and how much of the prototype will be reused in the final product.
Throwaway (Rapid) Prototyping
Used when requirements are unclear or evolving. The goal is to create a quick, low-cost model to explore ideas, test user reactions, and clarify needs — then discard it. This approach is common in UX design and early software concept validation. The focus is on learning, not building a production-ready artefact.
Evolutionary Prototyping
Here, the prototype evolves into the final product. Instead of discarding early versions, teams refine and expand them iteratively. This is often used in Agile environments or innovation projects where learning continues throughout the lifecycle. Each iteration builds functionality, guided by continuous stakeholder feedback.
Incremental Prototyping
In large or complex systems, it’s impractical to build everything at once. Incremental prototyping divides the system into modules that are developed, tested, and integrated progressively. It enables parallel workstreams and early demonstration of partial capabilities, reducing integration risk later.
Functional Prototyping
Functional prototypes are built to test performance, durability, or feasibility — often in engineering or hardware projects. Unlike visual mock-ups, they demonstrate real-world behaviour. They are essential when technical validation is the primary goal.
Scale or Physical Modelling
Used when the physical form, layout, or aesthetic impression of a design must be assessed before full production. Common in architecture and industrial design, scale models help stakeholders visualise spatial relationships and design intent. Christopher Wren’s wooden model of St Paul’s Cathedral remains an early and famous example of architectural prototyping.
The Spiral Model Connection
The Spiral Model formalises this iterative, risk-based approach by combining elements of prototyping with structured risk management. Each spiral cycle involves planning, prototyping, evaluation, and refinement. It’s particularly useful for large, complex, or high-risk projects where learning must be continuous and risk reduction is central. In modern practice, prototypes within the Spiral Model often take the form of experiments — structured tests designed to validate assumptions or reduce key uncertainties. Each cycle converts risks into evidence, ensuring progress is grounded in real learning rather than theory.
Proof of Concept (PoC) vs Prototype vs MVP
While related, these terms have distinct meanings. A proof of concept validates technical feasibility — can it be done? A prototype explores form, usability, or interaction — what will it look or feel like? An MVP (Minimum Viable Product) delivers a working version with just enough functionality to collect user feedback and test market response. Together, they form a continuum from idea to product.
Summary
Prototyping has evolved from a specialist engineering technique into a core project management practice. It provides a structured yet flexible way to test assumptions, engage stakeholders, and drive better design outcomes. Whether you’re creating software, hardware, or services, a good prototype helps bridge imagination and implementation — and brings clarity where uncertainty once ruled.
Uncertainty is not new in project management, but in today’s world, the scale and frequency of disruptions demand a different mindset. Financial crises, global pandemics, political upheavals like Brexit and Trump-era shifts, and ongoing conflicts such as the wars in Ukraine and the Middle East create volatile environments where traditional linear planning often fails. Project managers need to adapt, lead with resilience, and keep delivery moving forward in the face of unpredictability.
Why Uncertainty Matters
Projects don’t happen in a vacuum. Economic shocks affect budgets, pandemics disrupt supply chains and teams, political instability alters regulations, and wars create humanitarian and operational challenges. These uncertainties can derail even the best-laid plans — unless project leaders anticipate and adapt.
The Nature of Uncertainty
Former U.S. Defense Secretary Donald Rumsfeld famously framed uncertainty in terms of “known knowns, known unknowns, and unknown unknowns.” The first are the things we understand, the second are the gaps we can identify, and the third are the most dangerous — the surprises we cannot even anticipate. This taxonomy, when combined with Luft and Harrington’s Johari Window, resonates strongly with project management and strategic decision-making, reminding us that uncertainty is layered rather than singular.
Lessons from Recent Crises
Financial Crisis (2008): Projects stalled as funding dried up, highlighting the importance of strong business cases and flexible resourcing.
COVID-19: Remote working, disrupted supply chains, and rapid reprioritisation showed the value of digital tools and agile ways of working.
Brexit: Uncertainty around regulations, tariffs, and workforce mobility required scenario planning and stakeholder communication at scale.
Trump-era shifts: Changing trade policies and executive orders reminded project leaders to account for political volatility.
Wars in Ukraine and the Middle East: Energy prices, supply disruptions, and security concerns stress-tested global projects and highlighted the human cost of instability.
The rise of home and remote working in a post COVID world
Strategic Uncertainty
The Duke of Wellington once remarked that “the whole art of war consists in guessing what is on the other side of the hill.” His observation underscores that uncertainty is not new; it has always been central to decision-making with incomplete information. Leaders and project managers must act even without perfect visibility, making judgments under conditions of incomplete knowledge about competitors, environments, or future conditions.
The Challenge of Prediction
As the physicist Niels Bohr quipped, “Prediction is difficult, especially when it involves the future.” This paradox highlights why uncertainty cannot be eliminated — only managed. We can model scenarios, but the future resists neat forecasting. What matters is building resilience, adaptability, and awareness rather than expecting certainty.
How to Manage Projects in Uncertain Environments
Build resilience into planning: Use scenario planning and rolling-wave planning rather than rigid long-term schedules.
Strengthen risk management: Distinguish between risks you can mitigate and uncertainties you must monitor.
Prioritise communication: Sponsors, teams, and stakeholders need clarity when the environment is unstable.
Embrace agility: Iterative approaches allow adaptation as conditions evolve.
Focus on people: Psychological safety and wellbeing are critical in times of external stress.
Keep sight of purpose: A clear vision and set of objectives anchor teams when external events create noise and distraction.
Leading Through Uncertainty
In uncertain times, project managers are no longer just planners — they are navigators. Their role is to provide clarity when information is incomplete, confidence when conditions are volatile, and purpose when teams face disruption. Uncertainty is not an obstacle to be feared but a reality to be embraced. The most effective leaders turn volatility into an opportunity: they build resilient teams, adapt plans without losing sight of objectives, and guide delivery forward when the path is anything but straight.
Key Takeaways for Project Managers
Accept that uncertainty is inevitable — focus on resilience, not elimination.
Use frameworks (Rumsfeld, Johari) to map what is known and unknown.
Remember Wellington: anticipate the “other side of the hill” with scenario planning.
Fred Brooks was a distinguished American computer architect, software engineer and computer scientist whose major career achievement was managing the development of IBM’s System/360 family of computers and its OS/360 system software. The experiences gained inspired him to write The Mythical Man-Month – an essential read for every aspiring project manager. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. He goes on to say that the hypothetical unit of work done by one person in one month is a myth and this is often quoted as Brooks’ Law.
Adding manpower to a late software project makes it later.
He pointed out that complex software programming projects often cannot be divided into smaller discrete tasks that can be worked on by individuals without establishing complex communication between them. Indeed, some tasks cannot be subdivided at all and have an inherent duration that cannot be significantly reduced by increasing the number of people working on them. He summed this up thus:
Nine women can’t make a baby in one month.
In his book he also posed the question, How does a large software project get to be one year late? The answer is “One day at a time!”. Incremental slippages eventually accumulate to produce large overall delays and so attention to meeting small individual milestones is needed during all aspects of any project.
Whilst many of his other observations are more applicable to the specialist tasks around IT systems development the takeaways for us are:
Throwing resources at a project that is falling behind will not always deliver the outcomes you desire. Onboarding and training new resources takes time and managing larger teams generates its own complexities.
Some tasks cannot be completed more quickly however much effort is applied.
There should be no surprises when someone announces that a project is significantly behind schedule. A project that is a year late has had 365 opportunities for remedial actions to be taken.
