If I were to look from a project level down to the development level, then the Agile approach may look unusual. It may appear unusual if I were to look from an Agile development level to the overall project.
Project-Level and Development-Level For me, a project may be observed from different heights. The topmost being the overall project where I would use specific project management processes to manage the various competing constraints. At a lower level of say subproject or phase level that may in some instances mean product development the world looks somewhat different. At this level, Time & Resources may be more constrained, forcing me to use more creative methods such as Agile development methodology where there is a functional process but not necessarily the same features as the project. Sometimes I have the impression that these different levels of observations are mixed together. Furthermore, some people are more knowledgeable at one level or another depending on the type of projects they have experienced. This can lead some Project Managers to view an Agile development approach as chaotic, disorganised or anarchic depending on their project management experience and background. The reverse may be true as well where an Agile Project Manager viewing the Project from top level may get the impression that its management is outdated, slow and rigid.
Known Constraints At the overall project level, there is something always changing in the ever-contending limitations of Scope, Time, Resources, Cost, Stakeholders, etc. etc. It has always been like this (
say Jim Snyder) and will always be like it. That is the nature of a project. At one extreme, it may be that a certain phase or sub-project has specific constraints whereas in others such constraints may not exist or be relevant, but others may exist. The question then becomes which sub-project is more limited and will cause an increased risk in others. For high-quality standard, it may be necessary to increase the budget or extend the timescales or both to meet the requirements. At all levels, it is helpful to understand the constraints. In my projects, I always ask at the top level as well as at sub-project level what is the most severely limiting factor; Scope, Time, Resources, Costs (or vice versa, i.e. where the highest risk tolerance exists). The Project Manager should be aware that for some phases or sub-projects the constraints or areas of risk tolerance may change suddenly thus making it necessary to re-assess the situation.
Mindset vs Methods In an Agile development environment, methods are used that can be unusual. It can be particularly difficult to decide the development level if the associated mindset (or culture) does not exist in the company or the overall project. Agile methodology requires special kind of leadership, a protected environment and a good understanding of existing resources (time, budget, people). Such mindset does not happen overnight, cannot be made to come about by brute use of a methodology and it is not the same for all project levels. Project Management and Agile development are inextricably linked but they are not the same. They are complementary and should be viewed as such and integrated. In my view, the best way to truly understand how this integration works is through communication. If all those involved at all levels of the project share and understand each other's way of working then, terms like "Classic" and "Agile" will be understood and conflicts will be avoided. (Autor: Daniel Hendling, President PMI Austria Chapter; English version by Faez Tuma)
