When Agile Works and When It Doesn’t: Myths, Limitations, and Real Business Effectiveness

Agile has become one of the most frequently mentioned approaches to project management. It is seen as a tool for enhancing organizational agility and responsiveness to change, as well as a way to execute projects faster and more efficiently. The use of Agile in individual projects, its conditions and limitations, and the key differences between applying “agile” and “waterfall” approaches to project management are the focus of this article.

Project Types

According to project management standards, projects can be classified by product development life cycle into the following types:

Plan-driven — projects whose main constraints are planned (with some allowable deviations) at the initial planning stage and executed according to the PDCA cycle (Plan-Do-Check-Act).

Change-driven (adaptive) — projects whose main constraints are planned throughout the project, with the project divided into parts called iterations. The purpose of this division is to acknowledge that the project during implementation will undergo many changes, and therefore the approach to managing the project must allow for continuous updates to requirements.

Hybrid — projects whose elements (phases or parts of the product) can be executed using either plan-driven or adaptive approaches.

Adaptive projects, in turn, include two approaches to project execution:

• Iterative — the project is executed in short segments, each containing a PDCA cycle (Plan-Do-Check-Act). This approach is applied to projects whose initial requirements are poorly detailed, and thus these requirements are refined or changed during project execution.
• Incremental — the product is produced and delivered to the customer in parts. This approach involves implementing customer requirements by prioritizing them based on several factors, the most important of which are the value of the requirement and the risk associated with its implementation.

Agile — is an adaptive project using both iterative and incremental approaches. Many methods (frameworks) have been developed and applied based on this type of project.

This family of methods is designed to achieve the following goals:

• Deliver project results to the customer as quickly as possible (increments);
• Continuously make adjustments to the project (iterations);
• Reduce the time and cost spent on project planning.

Agile is often perceived as a more modern and effective approach compared to the classic Waterfall model. However, in practice, not all Agile projects are completed on time, within budget, or with the planned results. Moreover, alongside the spread of flexible methodologies, a reverse trend is also observed — companies returning to traditional management models. To understand why this happens, it is worth examining the limitations of each approach and their impact on project effectiveness.

Explore the capabilities of the Project Management & Accounting module in Microsoft Dynamics 365 Finance.

Learn more

Common Myths

Misconceptions create problems when applying one approach or another in practice, and, as experience shows, they are related both to lack of experience and imposed stereotypes, in which advantages are highlighted but limitations are omitted.

Myth 1. You don’t need to plan; you just need to act.

This slogan is often cited as one of the Agile principles. It sounds appealing but raises many questions: Do what? In what order? Using which resources? At what cost? How to deliver the product to the customer? In practice, Agile requires simplified planning (compared to Waterfall) because:

1. a) The project is executed in short iterations (sprints) lasting 2 to 4 weeks (recommended), and planning such an iteration should not require as much effort as a three-year Waterfall project;
2. b) If a large number of changes is expected from the start, it makes sense to plan each iteration (sprint) in detail, not a set of iterations (release), and certainly not the entire project, as that would have little practical value. This does not cancel the estimation of the cost and duration of the entire project before it begins.

Myth 2. Any project can be executed using Agile methodologies.

This is an obvious exaggeration, since there is a set of factors that determine the choice of a particular project life cycle method, taking into account the strengths and weaknesses of the method as well as its natural limitations (see below).

Myth 3. Agile is an “overhyped bubble” — widely promoted but useless in practice.

This is the opposite extreme of Myth 2, and it’s just as inaccurate. Agile works very well for specific types of projects — especially when it serves as the main delivery model (for example, Change Management initiatives, Six Sigma projects, software development, etc.). It is also an essential component of hybrid project models, which are becoming increasingly common, particularly with the rapid evolution of modern technologies, especially in the IT domain.

Myth 4. Agile teams don’t need management because they are self-organizing and can make all decisions on their own.

Self-organization is indeed a desirable attribute of modern project teams and human resources in general. However, the claims that a) a team is self-organizing by default, b) no management is required, and c) if the team needs guidance, it’s “not Agile,” are, to put it mildly, questionable. A team’s ability to self-organize depends on many factors: its size, team dynamics, experience and qualifications of the members, the level of stress in the project, the project’s importance to the Customer, the organization’s management culture, and more. In practice, the choice between directive and service-oriented leadership should reflect the real situation — whether the project is adaptive or predictive — and may change from one project phase to another.

Myth 5. Waterfall is outdated, and Agile is the new way of managing projects.

Both incremental and iterative approaches have been used for many years. The only truly new concept is the time-boxed approach, which strictly limits the duration of an iteration (as in SCRUM). It offers clear advantages but also notable drawbacks, which we discuss later. It is important to remember that the effectiveness and suitability of any project delivery approach depend on specific conditions — not on whether the method is “modern” or “old-fashioned.”

Myth 6. Moving sticky notes on a Kanban board is Agile.

Colorful sticky notes arranged by status do look appealing, and many teams spend a surprising amount of time perfecting the “art” of moving them around. Some genuinely believe this is the core of Agile — or even project management as a whole. Unfortunately for them: a) Kanban was not designed as a project management method; b) status boards are merely visualization tools. They may be used to track the project’s actual state — but they don’t have to be. There are far more powerful tools available for managing and monitoring real project progress.

Appropriateness

Every project is inherently defined by the “triple constraint.” Before work begins, one of the three constraints — Scope, Time, or Cost — is agreed with the Customer as the primary one, and all planning and execution decisions revolve around it. Setting two primary constraints makes delivery significantly more difficult; setting all three essentially turns the project into a heroic challenge. In Waterfall (a predictive model), the primary constraint is usually Scope — what must be delivered to achieve the result. In Agile methods, the primary constraint is typically Time. In other words, Agile is first and foremost an attempt to deliver value to the Customer as quickly as possible — usually in incremental portions.

Agile essentially relies on a trade-off: Scope (and quality) is exchanged for speed of delivery. Beyond this core principle, several additional factors influence the choice of delivery approach:

• The degree of interdependence between product features — i.e., whether a particular feature can function independently or requires other features to be implemented first.
• The level of detail (and quality) of the project’s technical specification — low-quality or insufficiently detailed requirements increase the risk of scope changes during delivery, which in turn creates the need for iterative development and shorter iteration cycles.
• The type of contract (if the project is contractual) — for example, a fixed-price contract typically assumes highly detailed requirements and minimal scope change risk; in such cases, using an iterative approach offers little value.
• The size of the project team — the larger the team, the more complex the coordination effort, often requiring decomposition into smaller groups and making it harder to manage numerous short iterations.
• The required quality of the final product — the more critical the product is for the Customer, and the stricter the quality expectations, the more important it becomes to keep Scope stable and avoid changes.

Summary of the recommendations and constraints regarding choosing an approach:

Ideal Conditions for Agile Projects

• Undefined or highly flexible project scope — frequent changes are expected.
• The Customer needs the project result delivered as quickly as possible.
• The final product can be delivered incrementally.
• The project is internal (no contract involved).
• The project is external but uses a “pay as delivered” (Time & Materials) contract.
• The project team consists of up to six people.

Suitable Conditions for Waterfall Projects

• A clearly defined scope where changes are predictable, making iterations unnecessary.
• Delivery time is a secondary factor.
• Product features are tightly interdependent, limiting or preventing incremental delivery.
• The project may be internal or external, under any contract type.
• The project team can be of any size.

If a project is “borderline,” i.e. shows characteristics of both categories, a Hybrid approach may be the most effective option:

• Certain project phases may follow Agile, while others follow Waterfall.
• Some product features may be delivered using Waterfall, and others using Agile.

The lists of misconceptions and “applicability” criteria provided above are not exhaustive, as there are additional factors that influence how effective a particular project delivery approach will be. For example, an important and increasingly relevant topic is the overall agility of the organization delivering the project (Organizational Agility), as well as the agility of the Customer (if the project is performed under contract). The environment in which the project is executed often becomes a critical factor in its success.

That said, the questions, constraints, and recommendations discussed in this article are key to understanding which project management method is most appropriate in a given situation. It is also important to remember that choosing the right delivery approach can significantly improve the chances of success but does not guarantee that the project will be completed within the established constraints — or completed at all. Each initiative carries its own set of risks, both at the evaluation and prioritization stage (Portfolio Management level) and during execution (Operational Management level), and these risks directly affect the outcome and the feasibility of achieving it. 

Optimize your business with the Project Management & Accounting functionality in Microsoft Dynamics 365 Finance.

Learn more

Vlad Berezin

Business Development Manager, SMART business

20+ years of experience in business management, project management, and sales. President of the Project Management Institute (PMI), Kyiv Chapter from 2007 to 2012. Hands-on experience delivering ERP, HR, marketing, organizational development, EPM, PPM, BPMS, and business process (BP) projects.