Master Agile Projects

An agile project approach is contemporary and is postulated as a panacea. Which company does not want to be agile? However, the change towards (partial) agility in an organization requires two fundamental circumstances:

• It must be worthwhile: With agile procedures, better project results are achieved or the project results are brought to product maturity faster with sufficient acceptance.
• It must be possible: Agile approaches require serious adjustments in the organizational culture, i.e. in the attitude and behavior of people at all levels of the hierarchy. In addition, it must be possible to iteratively expand a project result and gradually lead it to maturity.

To go into detail on all aspects of a successful agile transformation would go beyond the scope of this article. The most important prerequisites are summarized in Table 1. It should also be taken into account that every change in an organization - including the one towards agility - requires a lot of maturing time in addition to good preparation and implementation.

Application models and transformation
Organizations usually approach the agile transformation - the change from a classic to an agile project approach - with a lot of heart and soul and careful change management. However, the full expression of agility does not fit into every environment. Basically, we see three different models for the application of agility in organizations (see Fig. 1):

1. The hybrid model: Agile projects combined with classic project portfolio and program management
2. The bi-modal model (also called two-speed): Classical and agile projects coexist and are prioritized by classical or agile project portfolio and program management.
3. The complete agility: Agile management approaches on the levels project portfolio, programs and projects

Classic and agile elements can be combined well and achieve high effectiveness together. The mixture of models is either the final goal or an intermediate stage on the path of agile transformation. There is no right or wrong, but only a better or worse adaptation to the needs and capabilities of an organization.

Opportunities, risks and quality
In our client work, we are often confronted with questions such as: Are opportunities, risk and quality management even foreseen in the agile world? How can we ensure that our project does not get out of control? Who is responsible if there are no classic project managers?

The agile approach implicitly deals with opportunities and risks actively and repeatedly: with regular meetings (Sprint Planning, Daily SCRUM, Sprint Retrospective) and Sprint Reviews. We recommend accentuating opportunities and risks in such a way that the product owner keeps and evaluates his own opportunity and risk backlogs. The corresponding backlog items can be included in the sprint planning as requirements. This has the advantage that the handling of opportunities and risks is integrated naturally and naturally into the operative project handling. Impediments are also detected and solved in a timely manner. This process is supported by the SCRUM master in his central role as solution finder and obstacle eliminator.

Quality management in agile project execution is similar (see Table 2): Quality should be delivered continuously. Quality assurance and any corrections are made in each iteration. Quality is assessed by means of previously defined acceptance criteria for the user stories. Meeting the criteria generates business benefits on the one hand and ensures that the required quality is achieved on the other.

In our view, agile approaches provide good means to address opportunities, risks, and quality more frequently, more transparently, and across multiple roles. We have had good experience with the recommended explicit addressing of these issues.

Controlling and reporting
In classically managed projects, controlling based on the QUARZ dimensions (Q = quality, U = scope, A = effort or costs, R = risks, Z = time) is becoming increasingly established. These dimensions are also present in agile projects, but are handled implicitly:

• Quality: Quality requirements are part of the acceptance criteria. The realization and acceptance of a user story in a sprint thus always includes quality in addition to the business benefit.
• Scope: The scope of delivery and scope of a project are determined by backlog management and checked in the sprint review - often in combination with cost controlling.
• Costs: Project costs tend to be fixed, but the scope is changed.
• Risks: Opportunities and risks are reflected in separate backlogs and automatically flow into sprint planning.
• Time: The sprints are time-fixed. Deviations from deadlines in projects only occur through the execution of additional sprints.

Due to the tendency to fix costs and to vary the scope, controlling in agile projects is often reduced to the processing of the product backlog and the necessary number of sprints. Through an adequate application of agile project procedures, controlling within the individual sprints takes place quasi in real time, which increases transparency and reaction speed. On the other hand, we find weaknesses in cross-sprint controlling related to the entire project. Since investments are also made in agile projects, project-related controlling should not be neglected. We recommend a sharp look at all QUARZ dimensions, including the cost-scope combination.

Taking into account the following application conditions, we have had very good experience with the earned value method for controlling and reporting in agile projects:

• We communicate with graphics from which trends can be derived.
• The Planned Value Curve is designed as a straight line over the entire number or a part of the planned Sprints. It represents the sum of all tasks that are necessary to fulfill the backlog items in the respective sprint.
• To determine the earned value curve, we only consider completed tasks (0/100 approach) from sprint planning.
• For the budget-burned curve, we use the cumulative actual effort that the SCRUM team does per week.
• To make all values comparable with each other, we present them relatively in percentages.
• The earned-value and budget-burned curves are drawn in a sprint-overlapping manner and are thus comparable to the planned-value straight line.

Fig. 2 illustrates this procedure. The earned value methods adapted in this way result in effective, cross-sprint project controlling and are easy to integrate into project reporting. The result is a meaningful overview of project progress (scope), project costs and trend per dimension. The remaining QUARZ dimensions are directly related to scope and costs and complete the project controlling.

Note: To make it easier to bridge the gap to the true "agilists", we usually dispense with the earned value nomenclature, labeling the curves "planned progress", "actual progress", and "actual effort", for example, and naming the chart "project burn-down chart".

Conclusion
The above examples show how valuable classic methods/tools are in agile project procedures and that they can be integrated well. In our experience, adequately executed project management disciplines are an intrinsic success factor despite or precisely because of agility. Organizations such as the International Project Management Association (IPMA) or the Federal IT Steering Committee (FSUIT) have integrated agile approaches into their current project management standards.

We know how the sometimes almost dogmatically separate worlds of classic and agile approaches can be profitably combined. Use our experience to your advantage.