This book (Agile Project Management in easy steps, 2nd edition) is primarily intended for project managers who are moving into the project management of agile projects. It will also be of interest to agile developers who wish to know more about project management. Finally, it will also be of interest to anyone else who wishes to know more about the management of agile projects.
The traditional approach to projects and project management started by defining exactly what the project was expected to produce. This was termed the requirements or specification and was agreed and signed off between the project team and the business or customer. The project team then went away and built a product or system that they thought met those requirements and, some time later, presented the finished product to the customer. The problems with this approach are set out later in this chapter but the end result was all too often that it was not what the customer needed.
The agile approach to projects starts out with the expectation that the requirements (or features) will evolve and change during the course of the project. What is fixed and agreed between the project team and the customer is the resources that will be used and the time that will be taken by the project team to deliver as much as possible of the prioritized features the customer wants. The difference between the two approaches is illustrated below:
Traditionally, project management and software development were largely based on a sequential design process referred to as the ‘waterfall’ model. However this did not suit the software development process, where requirements could and often did change during the course of a project and more agile methods were evolved.
Project Management Methodology
Although traditional project management methodology can be applied to all types of projects, there are some special constraints that apply to agile projects. The features (requirements) are not only allowed, but expected to change and evolve through the course of the project, while the resources and time are frozen. So the project will deliver as much of the prioritized requirements as can be delivered in the available time and within the cost budget.
Within each phase of an agile project, the developers collaborate closely with representatives of the business or customer so they understand the detail of the next step and can create an evolving solution. Before the product, process or software goes into production the business can decide if they want to continue on the same path or make alterations.
Agile Project Management
Because of the radical nature of these methods, the traditional (waterfall based) approach to project management, with requirements being defined and fixed early in the project, did not fit comfortably with this new approach. So a new form of Agile Project Management began to develop.
In 2010 the DSDM Consortium published a definition of Agile Project Management, based on the DSDM method and interfacing with other agile methods such as Scrum and XP. This Agile Project Management differs from traditional project management in a number of key respects:
On a traditional project, the Project Manager may be actively involved in directing the work of the team and telling them what to do. This is sometimes referred to as Command and Control. In Agile Project Management the Project Manager is more of a facilitator and his/her role is to ensure that the collaboration between the business and the developers is effective.
As the required features are expected to develop and change during the project, the traditional approach of fixing requirements and allowing time and resources to flex to meet them is reversed. In an agile project, time and resources are fixed (through time-boxing and small teams) and features are allowed to change at the start of each new iteration of the product.
In a traditional project, the Project Manager would develop and own the project plan. In an agile project, the features are constantly changing, so planning for each phase, release or iteration is carried out as late as possible. Further, although the outline project plan is produced by the Project Manager, the detailed plans are produced by the Development Team.
In place of the traditional (waterfall) project stages, agile projects use a number of phases, containing several iterations, leading to a number of product releases and, therefore, a series of implementations.
The traditional project concept of change control is replaced by the Features Backlog. This is a list of prioritized business requirements, which is controlled by the business.
In place of the traditional approach to risk management and concerns about scope creep, a broader approach to risk is taken in an agile project. The Developers own the development risks and the business takes a more proactive role as the Product Owner.
In a traditional project, the Project Manager hands out work packets to the team. In an agile project, this is managed by the Development Team, and the Project Manager takes on more of a supportive role to the team.
In a traditional project, the Project Manager has a detailed Gantt chart against which to monitor progress. In an agile project, his/her role is to record the effort used on a Burn-down chart.
In an agile project, the Project Manager’s role is to facilitate and support the team, not to tell them what to do.
Want to know more?
For the essential guide to Agile Project Management, click here. A valuable source of inspiration for both newcomers and the more experienced, Agile Project Management in easy steps now in its second edition, explains the key principles, techniques, and processes to ensure your agile project is a success. This edition explains the key principles, techniques and processes of agile project management, working through an entire project, explaining the main activities and deliverables, so you’ll be a pro in no time!