Agile Project Management was born from the experience that highly prescriptive, planned-based approaches to project management simply weren't working in some contexts. In response the Agile Manifesto and Declaration of Interdependence statements were issued which, on the face of it, argue for flexibility in planning, an emphasis on customer-value, teamwork, and a welcoming attitude towards change. Critics argue that the potential for laxness in structure is enhanced, and along with that the increasing possibility of serious project failure. They are particularly critical of evangelical advocates who treat Agile as a silver bullet when in reality, as Fred Brooks suggested many years ago perhaps there is no silver bullet.

There is no single development, either in technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

Of course, an increase of an order of magnitude in various hardware metrics is not terribly unusual, an issue which has been elaborated in more depth in the past. Indeed, it's a wider example of the relationship between the productivity gains of automation in capital and the scope gains from the creativity in labour, to give a wider example from the economic factors of production. Agile and its implementations (e.g., Scrum) certainly will not result a ten-fold improvement in productivity, reliability, or simplicity, but it certainly can contribute to improvements in these areas, along with emergent creativity, when it's the appropriate tool for the job. When is that? To express simply: Complex projects require more structure. Uncertain projects require more agility. A project that is complex and uncertain requires both.

Agile is supposed to include all the business (time, cost, schedule) decisions that exist in any other project management methods; it's just that due to the uncertainty of particular projects (or as part of particular projects) these decisions will be made in a different point in the process. A high degree of up-front planning and structure works very well when there is a high degree of certainty, such as putting together a building or a computer network of commodity parts and uniform known software, and when all the components are already present. In these case, agile is not an appropriate mind-set, or at best, it should be minimised. Agile is however appropriate when the is uncertainty (e.g., in the client requirements, in an organisation's capabilities, in the supply chain etc) and works particularly well with software development due to its malleable characteristics, which innately allow for iteration, adaption, and changes.

Highly structured plan-orientated project management methods, such as PRINCE2, actually include the possibility of the Agile approach, if one looks carefully enough. For example, PRINCE2 has stages, work packages, and stage boundaries, which are iterative. Likewise when the stage boundaries are managed, the business case, the project plan, and even the project product description, can be up-dated to suit the new circumstances and customer requirements. Whilst some PRICE2 and Agile advocates perhaps will argue that the two are completely separate and never the twain shall meet, they are mistaken in their partisanship. Agile can most certainly provide an approach to a PRINCE2 structured project that makes ample use of the metrics and methods available in a PMBoK toolkit. The degree to which approach is utilised, how much structure is applied, and which tools are used is a judgment which a project manager must give attention to with a view towards recognising hybridisation is advantageous.