Study smarter with Fiveable
Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.
Agile methodologies aren't just buzzwords for your IT strategy exam—they represent a fundamental shift in how firms create value through software development. You're being tested on your ability to distinguish when and why different frameworks work, not just what they're called. Understanding these methodologies means grasping core strategic concepts: iterative value delivery, waste elimination, adaptive planning, and cross-functional collaboration. These principles directly connect to competitive advantage in fast-moving technology markets.
Don't fall into the trap of memorizing methodology names and features in isolation. The real exam value lies in understanding which approach fits which strategic context—a startup pivoting weekly needs different tools than an enterprise managing regulatory compliance. Know what problem each methodology solves, what trade-offs it accepts, and how it aligns development work with broader business strategy.
These methodologies structure work into fixed time periods (sprints or iterations), creating predictable delivery rhythms. The underlying principle is that regular deadlines force prioritization, enable frequent feedback, and reduce the risk of building the wrong thing for too long.
Compare: Scrum vs. XP—both use iterations, but Scrum focuses on process and roles while XP emphasizes technical practices. If an FRQ asks about improving code quality, XP is your answer; for team coordination issues, point to Scrum.
Rather than fixed iterations, these approaches optimize continuous work flow through visualization and constraint management. The core mechanism is making work visible and limiting concurrent tasks to expose bottlenecks and reduce context-switching costs.
Compare: Kanban vs. Scrum—Kanban suits maintenance and support work with unpredictable demand; Scrum works better for feature development with definable scope. Teams often migrate from Scrum to Scrumban as they mature.
These frameworks apply lean manufacturing principles to software development, focusing on removing non-value-adding activities. The strategic logic is that eliminating waste directly improves margins and speed-to-market without requiring additional resources.
Compare: Lean vs. FDD—Lean provides principles for identifying waste; FDD provides structure for feature delivery. Use Lean vocabulary when discussing strategic efficiency; cite FDD when explaining how to organize development work.
These methodologies explicitly acknowledge that one size doesn't fit all—they scale practices based on project characteristics like team size, risk level, and domain complexity. The underlying insight is that methodology overhead should be proportional to project risk.
Compare: Crystal vs. DSDM—Crystal adapts methodology weight to project size; DSDM adapts scope to fixed timelines. Crystal asks "how much process do we need?" while DSDM asks "what can we deliver by this date?"
| Strategic Concept | Best Methodology Examples |
|---|---|
| Predictable delivery rhythm | Scrum, XP, AUP |
| Continuous flow optimization | Kanban, Scrumban |
| Technical quality practices | XP, FDD |
| Waste elimination | Lean, Kanban |
| Scaling to project context | Crystal, DSDM, ASD |
| Customer collaboration | XP, DSDM, ASD |
| Hybrid/transitional needs | Scrumban, AUP |
| Uncertainty and innovation | ASD, Crystal |
Which two methodologies would you recommend for a team struggling with too much work-in-progress and frequent context switching? What specific practices from each would address this problem?
A firm is transitioning from waterfall to Agile but leadership wants to maintain some structured phases. Which methodology best bridges this gap, and why?
Compare and contrast how Scrum and Kanban handle changing priorities mid-cycle. Which is more responsive, and what trade-off does that responsiveness create?
If an FRQ presents a scenario where a small startup needs to pivot frequently based on customer feedback, which methodology family would you recommend and what characteristics make it appropriate?
Explain why a team might choose FDD over Lean Software Development, even though both focus on efficiency. What does FDD provide that Lean principles alone do not?