A range of IT commentators are confusing a product development methodology with project management. Agile is not an IT project management methodology any more than choosing to use pre-cast concrete in preference to brickwork is a construction project management methodology.
Agile is certainly a useful product development methodology for many IT applications and would probably be extremely useful in other situations such as developing training materials and many business change projects where most of the deliverables are relatively intangible. However this cannot turn it into a project management methodology.
Project management is the process of defining scope, deciding on methodologies, creating teams, and all of the other project management processes defined in the PMBOK® Guide. If agile is chosen as the product development methodology for an IT project it will certainly influence the way the project is planned, resourced and controlled but Agile itself is not ‘project management’. This is no different to the need to plan and execute a building project differently if all of the walls are delivered to site as precast panels compared to having workers build the walls in situ using bricks or blocks. If a project exists, project management is the overall controlling process not the selected work delivery process.
What is lacking in most commentary I’ve seen on Agile is any sensible discussion on using Agile within a project environment. The critical changes to scope management, change management, cost management and time management needed to effectively deal with the fluidity of Agile, within the constraints of a project, need discussion. Project Management is still about delivering optimum value based on a predefined framework of time, cost and output and managing changes within this structure.
It would seem many of the advocates of Agile are actually suggesting abandoning project management in situations where the client cannot really define its requirements and adopting a different form of management where conversations control the process development in a collaborative environment and the overall team’s focus is on achieving a ‘happy outcome’ for everyone. The primary constraint in this space is the resources capacity to deliver ‘sprints’ and the organisation’s budgeting process is focused on paying for a more or less stable team of people working consistently on improving the business’ IT infrastructure to service its operational areas.
This would suggest there are limitations to the traditional ‘project management’ paradigm (and I have always felt PM was a focused form of management – see Project Fact or Fiction from 2002) and the emergence of a different paradigm. If this observation is correct the real focus of discussion should be where PM works best and where the new collaborative ‘agile paradigm’ works best.
Comments are welcome and I will blog more on this idea later!!
One size does not fit every situation even in an agile world! The focus of this new article is to identify the differences in management approach needed to maximize value in three different situations where an ‘Agile’ approach can be used.
Pat Weaver
Lynda Bourne
Aavssitedev's Blog