Your first thought upon seeing the title was probably something like, “Oh for f… sake — another teardown of this topic?”
I get it, truly. I’d react the same way — if not for one small thing: I fundamentally disagree with most of the takes I’ve seen on the matter.
So maybe hold back the outrage for now — this content might surprise you. And if you’re an analyst whose work experience is equal to or less than the time Agile has been a thing, I especially recommend you read on.
Let’s dive in.
I get it, truly. I’d react the same way — if not for one small thing: I fundamentally disagree with most of the takes I’ve seen on the matter.
So maybe hold back the outrage for now — this content might surprise you. And if you’re an analyst whose work experience is equal to or less than the time Agile has been a thing, I especially recommend you read on.
Let’s dive in.
So what’s the current dominant view on software development process models?
You’ve got Waterfall: linear, rigid, ancient — mammoth dung — clearly outdated and ripe for retirement.
And then there’s Agile: bright, righteous, modern — iterative at its core and therefore obviously superior.
So, naturally, most discussions frame it as a binary: good vs. evil. Let’s unpack that a bit.
What is Waterfall, really? Let’s not overthink it — straight from Wikipedia: The waterfall model is a breakdown of developmental activities into linear sequential phases, meaning that each phase is passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks.
I’m not going to dissect the model itself — we can all read, and the internet is full of comparison articles. Yes, it seems that for the vast majority of projects, Waterfall is wildly inefficient. And Agile often feels like the prescription we’ve all been waiting for. However the same Wikipedia states the following: Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, and extreme programming.
That’s your first clue: the world isn’t made of just Agile and Waterfall.
Let’s move on to something more solid: the PMBOK Guide, 7th Edition. Surely a bit more rigorous than Wikipedia:
A development approach is the means used to create and evolve the product, service, or result during the project life cycle. There are different development approaches, and different industries may use different terms to refer to development approaches. Three commonly used approaches are predictive, hybrid, and adaptive.
1. A predictive approach is useful when the project and product requirements can be defined, collected, and analyzed at the start of the project. This may also be referred to as a waterfall approach.
2. Hybrid approaches often use an iterative or incremental development approach.
3. Adaptive approaches are useful when requirements are subject to a high level of uncertainty and volatility and are likely to change throughout the project. While agility is a wide mindset that is broader than a development framework, agile approaches can be considered adaptive.
Still not convinced? Let’s remember our beloved Karl Wiegers, who captures all this beautifully — in a single diagram:
And then there’s Agile: bright, righteous, modern — iterative at its core and therefore obviously superior.
So, naturally, most discussions frame it as a binary: good vs. evil. Let’s unpack that a bit.
What is Waterfall, really? Let’s not overthink it — straight from Wikipedia: The waterfall model is a breakdown of developmental activities into linear sequential phases, meaning that each phase is passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks.
I’m not going to dissect the model itself — we can all read, and the internet is full of comparison articles. Yes, it seems that for the vast majority of projects, Waterfall is wildly inefficient. And Agile often feels like the prescription we’ve all been waiting for. However the same Wikipedia states the following: Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, and extreme programming.
That’s your first clue: the world isn’t made of just Agile and Waterfall.
Let’s move on to something more solid: the PMBOK Guide, 7th Edition. Surely a bit more rigorous than Wikipedia:
A development approach is the means used to create and evolve the product, service, or result during the project life cycle. There are different development approaches, and different industries may use different terms to refer to development approaches. Three commonly used approaches are predictive, hybrid, and adaptive.
1. A predictive approach is useful when the project and product requirements can be defined, collected, and analyzed at the start of the project. This may also be referred to as a waterfall approach.
2. Hybrid approaches often use an iterative or incremental development approach.
3. Adaptive approaches are useful when requirements are subject to a high level of uncertainty and volatility and are likely to change throughout the project. While agility is a wide mindset that is broader than a development framework, agile approaches can be considered adaptive.
Still not convinced? Let’s remember our beloved Karl Wiegers, who captures all this beautifully — in a single diagram:
Now let’s bring in some logic:
Before the Agile Manifesto dropped in 2001 — and long before its principles made their way into Eastern Europe — people still managed to get software built. If you think it was all pure Waterfall — teams sobbing while grinding away at an absurdly rigid, linear process — think . Iterative development approaches have been mainstream for quite a while now. None of the projects I or my colleagues worked on pre-Agile ever used the term “Waterfall” or followed its principles religiously. People simply worked iteratively — but without putting Agile values and principles front and center.
So, what’s the takeaway? When people compare Waterfall to Agile and inevitably conclude that Agile wins, they’re comparing a horse to a jet plane — and then smugly pointing out how much faster and better the plane is. But they conveniently ignore the fact that cars came in between, and for a long time completely dominated the transportation scene. Likewise, most teams who don’t follow Agile today aren’t doing Waterfall either. Even worse: if your team waves the Agile flag but lacks any real grasp of the mindset and values behind it (which is not uncommon), you’re basically working the same way as those so-called “dinosaurs.” Just because you renamed iterations to “sprints” and chopped up specs into “user stories” doesn’t mean you’re Agile. Don’t kid yourself. And no, I’m not talking about edge cases where the horse actually is better. I’m talking about the statistical majority of projects.
What does all this mean for a business analyst?
First of all, I’ve often seen people contrast a “monolithic spec created predictively at the start” with “just-in-time user stories.” Agile evangelists love this narrative — it showcases the “power and flexibility” of Agile. But again, it’s horse vs. jet, good vs. evil. In all my years working as an analyst before Agile went mainstream, I can count on one hand the number of times I had to write a complete spec before development began. Requirements were developed iteratively — even if we didn’t call them “user stories,” they weren’t fundamentally different in nature. Classic artifacts like specs and technical documentation can be developed iteratively. They can also be broken into chunks not unlike user stories. This caricature of pre-Agile analysis as rigid and inflexible is both misleading and limiting. It narrows your toolkit and forces you into artificial constraints.
Next comes a section for relative newcomers — focused more directly on business analysis. We’ll discuss planning the business analysis approach within the context of development models, based on the BABOK framework — but with my personal spin.
Before the Agile Manifesto dropped in 2001 — and long before its principles made their way into Eastern Europe — people still managed to get software built. If you think it was all pure Waterfall — teams sobbing while grinding away at an absurdly rigid, linear process — think . Iterative development approaches have been mainstream for quite a while now. None of the projects I or my colleagues worked on pre-Agile ever used the term “Waterfall” or followed its principles religiously. People simply worked iteratively — but without putting Agile values and principles front and center.
So, what’s the takeaway? When people compare Waterfall to Agile and inevitably conclude that Agile wins, they’re comparing a horse to a jet plane — and then smugly pointing out how much faster and better the plane is. But they conveniently ignore the fact that cars came in between, and for a long time completely dominated the transportation scene. Likewise, most teams who don’t follow Agile today aren’t doing Waterfall either. Even worse: if your team waves the Agile flag but lacks any real grasp of the mindset and values behind it (which is not uncommon), you’re basically working the same way as those so-called “dinosaurs.” Just because you renamed iterations to “sprints” and chopped up specs into “user stories” doesn’t mean you’re Agile. Don’t kid yourself. And no, I’m not talking about edge cases where the horse actually is better. I’m talking about the statistical majority of projects.
What does all this mean for a business analyst?
First of all, I’ve often seen people contrast a “monolithic spec created predictively at the start” with “just-in-time user stories.” Agile evangelists love this narrative — it showcases the “power and flexibility” of Agile. But again, it’s horse vs. jet, good vs. evil. In all my years working as an analyst before Agile went mainstream, I can count on one hand the number of times I had to write a complete spec before development began. Requirements were developed iteratively — even if we didn’t call them “user stories,” they weren’t fundamentally different in nature. Classic artifacts like specs and technical documentation can be developed iteratively. They can also be broken into chunks not unlike user stories. This caricature of pre-Agile analysis as rigid and inflexible is both misleading and limiting. It narrows your toolkit and forces you into artificial constraints.
Next comes a section for relative newcomers — focused more directly on business analysis. We’ll discuss planning the business analysis approach within the context of development models, based on the BABOK framework — but with my personal spin.
There’s a wonderful knowledge area in the BABOK called Business Analysis Planning and Monitoring. It focuses on organizing business analysis activities within a project, managing their execution, and adjusting plans through ongoing monitoring.
The very first task in this area is to Plan Business Analysis Approach. This involves defining — in broad strokes — how business analysis will be conducted, whether by an individual or a team. This decision significantly influences the structure of work, the techniques to be used, and the artifacts to be produced.
BABOK categorizes approaches into two major types:
Sound familiar? These are similar to the software development approaches described in PMBOK. There's no mention of a hybrid approach, but of course, it exists — just imagine these two types as endpoints on a spectrum, with a wide range of practical, real-world variations lying in between.
The very first task in this area is to Plan Business Analysis Approach. This involves defining — in broad strokes — how business analysis will be conducted, whether by an individual or a team. This decision significantly influences the structure of work, the techniques to be used, and the artifacts to be produced.
BABOK categorizes approaches into two major types:
- Predictive (favoring upfront planning)
- Adaptive (favoring flexibility and responsiveness over early planning)
Sound familiar? These are similar to the software development approaches described in PMBOK. There's no mention of a hybrid approach, but of course, it exists — just imagine these two types as endpoints on a spectrum, with a wide range of practical, real-world variations lying in between.
The predictive approach aligns with traditional development models like Waterfall or more rigid iterative methods — where phases are clearly defined and deliverables are planned in advance. Requirements in this context are usually gathered early — either for the entire project or for individual iterations.
The adaptive approach, by contrast, is built on flexibility — a “respond as we go” mindset. Unsurprisingly, it fits neatly with Agile and other less formal iterative models, where the team may take a “we’ll figure it out when we get there” attitude toward requirements. This naturally comes with higher risks — something critical might surface late and require costly rework — so adaptive methods are more suitable for flexible contracts or projects where mistakes are less costly.
Key Differences Between Predictive and Adaptive Approaches:
The adaptive approach, by contrast, is built on flexibility — a “respond as we go” mindset. Unsurprisingly, it fits neatly with Agile and other less formal iterative models, where the team may take a “we’ll figure it out when we get there” attitude toward requirements. This naturally comes with higher risks — something critical might surface late and require costly rework — so adaptive methods are more suitable for flexible contracts or projects where mistakes are less costly.
Key Differences Between Predictive and Adaptive Approaches:
1. Requirements Development & Documentation
Traditional business analysis tends to favor thorough documentation. Agile (which we’ll use here as shorthand for Adaptive) leans toward lightweight documentation and stronger collaboration. If an Agile analyst can walk over and have a quick chat instead of writing a long requirements doc — they will.
Yes, it’s faster and often more efficient. But lighter documentation comes with trade-offs and risks — a topic for another article. For now, let’s focus on artifacts.
Two key attributes define BA artifacts: formality and level of detail.
Highly detailed artifacts capture everything — down to the smallest algorithmic nuance — and often include multiple “views”: user-oriented (Use Cases), system-level (Functional Specs), data-oriented (Data Models), and so on. Formal, detailed artifacts are typically structured according to strict templates (like full-scale SRSs, or comprehensive Vision & Scope documents) — the kind that Agile analysts tend to avoid.
On the other end, Agile artifacts (User Stories with acceptance criteria, wiki pages with UI mockups and annotations) are often informal and incomplete by design. Traditional analysts may scoff at them as “rough drafts,” but these formats allow more creativity from developers.
There’s a deeper philosophical divide too:
As you’ve probably guessed, predictive approaches gravitate toward formal, detailed artifacts. Adaptive approaches embrace lightweight, flexible ones.
2. Techniques for Eliciting & Managing Requirements
Traditional BA favors deep-diving techniques — Use Cases, SWOT, Risk Analysis, Financial Analysis — all aimed at capturing both the current state (AS IS) and the future state (TO BE) with precision and care.
Agile analysts, on the other hand, often use lightweight tools like Lean Canvas, Impact Mapping, or Personas to move faster, even if a bit less thoroughly.
3. User-Centric Thinking
Agile puts the user front and center. Not that traditional approaches ignore users — they don't — but they evolved in a time when systems were more backend-heavy and user experience wasn't prioritized.
Agile’s rise brought new techniques rooted in empathy: Personas, User Stories, Customer Journey Maps — many of which blur the line between BA and UX. These techniques are now standard in Agile and help prioritize real user needs over rigid system specifications.
4. Distribution of Workload Over Time
In traditional approaches, analysts do most of the heavy lifting early on — during the project’s initiation or planning phases. They may later step back, only providing occasional support or updates.
In Agile, work is more evenly spread out. Requirements are developed iteratively, often in two-week cycles, with the analyst actively involved in every sprint. There's also continuous interaction with the team and stakeholders — because documentation is lighter, conversations are critical.
Agile also encourages progressive elaboration of requirements. Where traditional analysts strive to finalize and polish everything before passing it to developers, Agile analysts intentionally start with rough ideas and refine them as development progresses.
5. Change Management
In traditional models, change handling depends heavily on the contract. If the client tries to alter the scope mid-project, the analyst may respond: “Sorry, that’ll cost extra.” Or they may embrace it, especially under a time & materials agreement.
Agile is more consistent: change is expected and welcomed. The focus is on short-term plans. Sure, there’s long-term planning, but in Agile, you assume everything could shift — and it often does. New sprint, new priorities. Agile analysts smile and adapt.
6. Roles and Responsibilities
Traditional teams are role-based. The analyst “owns” the requirements and works with stakeholders, but the responsibility rests primarily on them.
Agile promotes cross-functional collaboration. Requirements are everyone’s concern. The analyst facilitates early discussions and involves technical experts right away. Together, the team shapes and refines those rough requirements over time. This shared process distributes ownership and increases team alignment.
Choosing the Right Business Analysis Approach:
To wrap up, here are some practical factors to consider when planning your BA approach:
Traditional business analysis tends to favor thorough documentation. Agile (which we’ll use here as shorthand for Adaptive) leans toward lightweight documentation and stronger collaboration. If an Agile analyst can walk over and have a quick chat instead of writing a long requirements doc — they will.
Yes, it’s faster and often more efficient. But lighter documentation comes with trade-offs and risks — a topic for another article. For now, let’s focus on artifacts.
Two key attributes define BA artifacts: formality and level of detail.
- Formality refers to the lack of freedom in document templates.
- Detail means both the depth (how thoroughly requirements are specified) and the breadth (how comprehensively they cover the system).
Highly detailed artifacts capture everything — down to the smallest algorithmic nuance — and often include multiple “views”: user-oriented (Use Cases), system-level (Functional Specs), data-oriented (Data Models), and so on. Formal, detailed artifacts are typically structured according to strict templates (like full-scale SRSs, or comprehensive Vision & Scope documents) — the kind that Agile analysts tend to avoid.
On the other end, Agile artifacts (User Stories with acceptance criteria, wiki pages with UI mockups and annotations) are often informal and incomplete by design. Traditional analysts may scoff at them as “rough drafts,” but these formats allow more creativity from developers.
There’s a deeper philosophical divide too:
- Traditional techniques aim to build a knowledge base of evolving, up-to-date requirements.
- Agile techniques focus on task definition — “Build this specific thing.”
As you’ve probably guessed, predictive approaches gravitate toward formal, detailed artifacts. Adaptive approaches embrace lightweight, flexible ones.
2. Techniques for Eliciting & Managing Requirements
Traditional BA favors deep-diving techniques — Use Cases, SWOT, Risk Analysis, Financial Analysis — all aimed at capturing both the current state (AS IS) and the future state (TO BE) with precision and care.
Agile analysts, on the other hand, often use lightweight tools like Lean Canvas, Impact Mapping, or Personas to move faster, even if a bit less thoroughly.
3. User-Centric Thinking
Agile puts the user front and center. Not that traditional approaches ignore users — they don't — but they evolved in a time when systems were more backend-heavy and user experience wasn't prioritized.
Agile’s rise brought new techniques rooted in empathy: Personas, User Stories, Customer Journey Maps — many of which blur the line between BA and UX. These techniques are now standard in Agile and help prioritize real user needs over rigid system specifications.
4. Distribution of Workload Over Time
In traditional approaches, analysts do most of the heavy lifting early on — during the project’s initiation or planning phases. They may later step back, only providing occasional support or updates.
In Agile, work is more evenly spread out. Requirements are developed iteratively, often in two-week cycles, with the analyst actively involved in every sprint. There's also continuous interaction with the team and stakeholders — because documentation is lighter, conversations are critical.
Agile also encourages progressive elaboration of requirements. Where traditional analysts strive to finalize and polish everything before passing it to developers, Agile analysts intentionally start with rough ideas and refine them as development progresses.
5. Change Management
In traditional models, change handling depends heavily on the contract. If the client tries to alter the scope mid-project, the analyst may respond: “Sorry, that’ll cost extra.” Or they may embrace it, especially under a time & materials agreement.
Agile is more consistent: change is expected and welcomed. The focus is on short-term plans. Sure, there’s long-term planning, but in Agile, you assume everything could shift — and it often does. New sprint, new priorities. Agile analysts smile and adapt.
6. Roles and Responsibilities
Traditional teams are role-based. The analyst “owns” the requirements and works with stakeholders, but the responsibility rests primarily on them.
Agile promotes cross-functional collaboration. Requirements are everyone’s concern. The analyst facilitates early discussions and involves technical experts right away. Together, the team shapes and refines those rough requirements over time. This shared process distributes ownership and increases team alignment.
Choosing the Right Business Analysis Approach:
To wrap up, here are some practical factors to consider when planning your BA approach:
- The development model and methodology in use. As you’ve seen, certain approaches are better suited to certain frameworks.
- Risk and complexity of the solution. The more critical or complex the system (e.g., medical software, military applications, nuclear systems), the more formal your approach should be.
- Contractual model and client preferences. Strict contracts (e.g., fixed price) usually call for a more predictive, structured approach.
- Stakeholder distribution. If key stakeholders are geographically dispersed or in different time zones, predictive methods are often more effective due to communication constraints.
- Team experience and stability. A seasoned team can handle ambiguity better and fill in the blanks creatively. The less stable the team, the more valuable formal, persistent artifacts become — especially for onboarding and continuity.
- Longevity of requirements. Will requirements need to be preserved long-term (for maintenance, support, regulatory compliance)? Predictive artifacts serve better as lasting knowledge bases.
Final thoughts. Ultimately, the most sustainable approach is one you tailor to your project. That’s why it’s crucial to understand the spectrum of BA approaches and their nuances. Expand your toolkit of techniques, artifacts, and strategies, so you can build a solid, flexible foundation — whether for yourself or your team.
What doesn’t help is treating Agile as gospel and User Stories as the one true BA technique. If you can only operate within the Agile playbook, you’re not truly an adaptable analyst — and that will limit your ability to succeed across different contexts.
What doesn’t help is treating Agile as gospel and User Stories as the one true BA technique. If you can only operate within the Agile playbook, you’re not truly an adaptable analyst — and that will limit your ability to succeed across different contexts.