Considerations for Agile/Adaptive Projects

When integrating a project, the PM needs to allow the team to perform detailed product planning and delivery. The PM should also facilitate collaborative decision making and ensure the team's ability to respond to changes.

Requirements go through scope discovery wherein stakeholders propose beneficial additions to requirements. Prototypes help to refine the requirements.

The product owner creates the product vision and roadmap, eventually resulting in a product backlog. This backlog is delivered in one more releases, with each release having multiple sprints or iterations. The features or user stories for each iteration are decided at the start of that iteration, based on customer needs, and termed as the iteration backlog. Burndown charts are used to plan and track pending user stories on daily basis whereas burnup charts for completed user stories. Multiple approaches (traditional, agile, hybrid) can be mixed. Scaling factors which apply to agile projects are team size, geographical spread, organizational complexity, policies and technical complexity.

Thus in agile lifecycle, high priority items from product backlog are worked in an iteration. The project management processes performed in each iteration are: collect requirements, define scope and create WBS, validate scope and control scope. Whereas in a predictive life cycle, collect requirements, define scope and create WBS are done once and later only in case of changes. Validate scope done for each deliverable/phase review and control scope will be ongoing. Thus the product backlog (product requirements, user stories) will be the current needs of an agile project. 

Initial labour cost estimation is lightweight as scope is not finalized, whereas detailed estimation may be performed for short term horizons (iterations). In case of strict budgeting for high variability projects, frequent cost adjustments will be necessary.

Frequent quality reviews using retrospectives will be performed. New approaches for quality improvement are tried by performing root cause analysis during retrospectives of initial iterations, and based on the evaluation; the decision to use, adjust or drop them in subsequent iterations is made. Small batches of work help to uncover quality issues early in the lifecycle when overall change of cost is lower.

An agile team has generalized specialists not SMEs in order to adapt to customer demands. Collaboration among people becomes very important in order to gain agreements for fast capacity adjustments or to use lean methods.

Agile communications are quick and frequent with regular reviews, which motivate team and provide transparency.

In agile projects, more risks have to be addressed in general due to incremental work and changing customer demands, therefore frequent risk reviews are required, or in every iteration.  Cross functional teams, knowledge sharing and a living requirements document also help to manage risk effectively.

When contracts are used in agile project, a shared risk model with sellers is advised. MSA (Master Service Agreement) for overall work, and appendices or supplements for adaptive work will work better than signing off a single contract.

Agile projects require direct engagement with stakeholders than through management channels as it is co-creative process. Transparency is essential and for this purpose, information radiators or wall charts create the desired effect.

A decision making method in agile projects is the fist of five. When the PM requires the team member inputs to make a decision,  a fist indicates no support, all fingers open implies full support, anyone not showing at least 3 fingers will have to discuss their objections.