Managing Agile Projects

The two earlier blogs in this series focused on what’s NOT project management.

Agile and Waterfall are two different software development methodologies (see: Agile is NOT Project Management)

Operational maintenance with stable teams dealing with new work and maintenance upgrades on an organization wide basis is not project management even if there are new features being added to the IT infrastructure. This type of work is traditional operational management even if scrum and other Agile techniques are being used (see: De-Projectising IT Maintenance)

Traditional IT project management has grown up around and closely aligned with the Waterfall software development methodology. As with most engineering projects the final product to be delivered is scoped, designed, built, tested and implemented – in that order. This is OK if the client knows what it needs precisely and the number of changes is relatively small. Waterfall falls down (pardon the pun) if the project is a quest to achieve an objective and everything changes routinely.

Agile seems to be an ideally suited methodology for developing the software but if the work is also a project how should the PMBOK® Guide processes be applied? This blog will outline some ideas at a high level, later blogs may dig into some areas more deeply.

The PMBOK® Guide 4th Edition (2008) has 8 knowledge areas:

Project Scope Management
Traditional project management expects scope management to define the output. In an Agile project the final outputs should be defined in terms of achieved capabilities, how the capability will be achieved will be discovered along the journey.

This makes ‘Verifying the Scope’ interesting. There needs to be clearly defined way to assess if the capability has been delivered. How do you measure a ‘user friendly interface’? It’s not impossible to do but how it’s done needs to be clearly defined.

Change control is also more challenging, as is configuration management.

Project Time Management
Ideally time should not be an issue if the objective is to achieve a required capability. In reality there are usually deadlines.

In an Agile project, scheduling and workflow become closely aligned. The key requirement is an overall system architecture that defines the sequence modules need to be built in to allow progressive testing and implementation of capability. The software architecture defines the build sequence that defines the schedule.

Scheduling is at a much higher level though. A ‘sprint’ is likely to be a single activity of 1 to 2 weeks duration. The sequencing of the ‘sprints’ and the number of sprints that can operate in parallel define the resource requirements and the project duration.

Project Cost Management
Agile projects have to be based on a cost reimbursable system. One tool designed to include a degree of competition with the ability to properly compensate the contractor for its work is southernSCOPE the methodology requires tenders to bid on a project at a $ per function point rate based on a project description and the estimated number of function points. At the end of the project the same independent person who prepared the initial estimate, re-counts the function points and the price is determined.

Project Quality Management
This is probably easier under Agile; quality is continually assessed by the involvement of the client and the iterative release of modules to production.

Project Human Resource Management
Basically remains unchanged but the skills of the people needed for an Agile project are likely to be different.

Project Communications Management
The level of trust needed to run a Agile project is much higher than a traditional project. Effective ‘real’ communications in all directions are essential. This is different to producing project reports! More later.

Project Risk Management
Recognize you are on a journey focused on delivering value. Significant time and cost contingencies are needed and should be used to optimize the value of the final product. More later!!

Project Procurement Management
This should not change significantly BUT the procurement process needs to be aligned to what it is buying. Agile works in a collaborative partnering space. In the engineering world these are call Alliance Contracts. Traditional contracts will not support Agile delivery methods.

In conclusion: align the PMBOK to an Agile project delivery method and the overarching PM process will enhance the probability of success. Treat an Agile project in the same way as a traditional Waterfall project and the PM processes will guarantee failure!