Keywords

1 Motivation and Context for the Demand of an Agile Project Reviews

Agile methods and procedures are only one kind of process implementation from the perspective of the ISO 9000 and other standards. An organization, which have to fit to quality standards like the ISO 9000 have to demonstrate its continuous improvement procedure and an internal quality check procedure. After the rollout of lean [KANBAN] and agile methods and procedures [AGPI] by the Agile Center of Excellence (ACE) to many projects [POTH15] over the past years the “pilot” status of the few early adopters has gone. To fulfill the expectations to be compliant to established standard the ACE has to setup a procedure for cyclic checks about the current implementation of relevant quality management (QM) procedures. Furthermore, the governance responsibility of the ACE as owner of the agile change in the Volkswagen Group IT requires an establishment of a continuous improvement procedure.

Both formal procedures, the QM and the continuous improvement procedure, will described here. To have a lean and effective implementation of both formal procedures the ACE developed them in one operational procedure. This operational procedure is called agile project review. The agile project review is applied to randomized samples, which are “drawn” by a public tombola in the monthly agile community of the Volkswagen Group IT. The “winners” have the chance to get professional feedback from the agile project reviewer team. The top 3 projects are listed on the “champions league” to show the benchmark to all projects and motivate with this gamification approach the projects to improve their results for future agile project reviews.

2 Development of the Agile Project Review Procedure

The ACE decides to develop the procedure in an open fashion, which invites all agile project review “candidates” to design the review. To realize this in an agile community, which happens monthly, the working group was setup. Over months, the working group developed the agile project review in an iterative fashion and got feedback from the agile community in which milestones were presented and discussed. The focus was not to develop a formal assessment model like or oriented on the ISO/IEC 33000. The focus was to define a lightweight review model for a quick deep dive into agile projects and give feedback about the status quo of the established agile mindset [AGMA], the procedures of the project and the alignment of agile teams to the organizational process framework. The documentation and expected outcomes are not as formalized like in the Automotive SPICE because the reviewer team is nominated of a pool of agile guides or coaches of the Volkswagen Group IT. These coaches are working have their communities of practice to align their values and mindset. This makes it easier to conduct the reviews with only a short introduction (training on the job) into the agile project review approach. A complex training like the intacs certifications is not needed.

3 Deep Dive into the Agile Project Review

After presentation of the demand and the development procedure, this chapter presents the agile project review more detailed. This chapter is like a how to derive an own agile project review which fits the demands of your environment.

3.1 The Categories

The working group defined after some discussions and feedbacks the categories of the agile project review. The working group defined the categories generic to address teams at different levels of the spiral dynamics model [BEC05]. The categories are:

  1. (a)

    The customer satisfaction: check if and how often customer feedbacks are collected and evaluate the adequateness of tasks, which are derived from the feedbacks

  2. (b)

    The artefacts: looks about the agile artefacts like Definition of Done (DoD), backlog structure, story format and structure and so on

  3. (c)

    The events: checks the establishment of agile procedures like for scrum [SCRUM] about at least the backlog refinement, sprint planning, daily and the retrospective but also it look for cycle time and other processual aspects

  4. (d)

    The process: looks about the establishment of agile rituals like feedback culture, realize continuous improvement and so on

  5. (e)

    The product safeguarding: check the application of the DoD, evidences for acceptance criteria and CI/CD capability of test-automation or defects in production

  6. (f)

    The alignment to the standard development process: checks some of the important process outcomes of the Volkswagen Group IT development process for a minimum alignment

To answer the question how aligned are agile teams to the organizational process framework, therfore part (f) is relevant. To inspect the team specific internal agile procedures, than part (a)–(e) is relevant.

For rating, four levels are defined. Higher is better. The zero, as neutral element, is applied to categories, which are not applicable in an agile projected review due to specific restrictions.

Figure 1 shows an example of rated categories and one category is not rated and set to zero.

Fig. 1.
figure 1

An example of a rating of the categories

Full size image

During model development, the working group specialists reflected the definitions with their real life experience to assure that the right focus is set.

3.2 Examples from the Questionnaire and the Review Procedure

The amount of check aspects differs between the categories. The amount is depending on the complexity of the categories and the aspects, which are focused for the agile project, review during model specification. To support the evaluation of the review team during an agile project review each aspect has some rating criteria’s. For more help some examples are given in the additional evaluation help field. The working group defined the aspects and especially the evaluation help comments to address teams at different levels of the spiral dynamics model. The “maturity” of the project team leads to different approaches to address issues that should be have positive effects to the rating. Furthermore, the agile project review have to check the minimum requirements of standards like the formal approval of a release.

The Fig. 2 shows an example of the “check list” from the reviews perspective.

Fig. 2.
figure 2

An example of reviewer’s evaluation sheet

Full size image

3.3 The Gamification Approach

To make the agile project review results for benchmarking available the top 3 projects are listed on group level and region level. Region level mostly are locations like plants of the Volkswagen AG. Figure 3 shows a part of this champion’s league table. The position depends on the average of the rating for the 6 categories, described in Sect. 3.1.

Fig. 3.
figure 3

Part of the champion’s league page (in German)

Full size image

3.4 Sampling of Projects

During the agile community, a tombola is celebrated/drawn to realize a transparent selection of the randomized agile project review samples. The tombola is filled up with lots of all as agile defined projects. As agile defined projects are projects with a positive agile readiness approval at the end of the ACE coaching phase. The amount of drowned lots is the workload of agile project reviews up to the next tombola.

Projects are for the time of implementing improvement actions not in the tombola. This period is approximately 6 months. After this time, the project can be volunteer or lucky winner of the tombola.

In addition, volunteer projects can request for an agile project review on top of the tombola winners to get an expert feedback about their current state of their agile journey.

3.5 The Agile Project Review and Its Next Steps

The review is announced to all project team members in the kick-off. The review itself is done on another day. Each review starts with the same question: How comes you and your team from the customer demand to customer satisfaction? During review the project team members show and tell their outcomes about the categories and aspects. The reviewer team logs the relevant comments and outcomes. In addition, the reviewer team ask for open or missing aspects. After the review the reviewer team, which consists of at least two experts, adjust their individual views to common and harmonized rating. The harmonized rating is communicated to the project team at the end of the agile project review. The project team defines based on the feedbacks by their own improvement actions to “fix findings” or to “rise potentials”. The project driven improvement actions should be discussed about adequateness with the reviewer team before implementation. The reviewer team also analyse the agile project review results for structural deficits in the organization to trigger improvement actions on the organization level if needed. Furthermore, the agile community have always the right to initiate a working group to enhance or adjust the agile project review approach.

4 Conclusion

The ACE and the agile community have found a way to realize their governance responsibility. The setup and improvement of the agile project review is steered by the agile community. The selection of the samples is done completely transparent. The results of the agile project review is used for “local” project improvement and for “global” organization reflection and improvement. The feedback character of the agile project review approach gives a high acceptance by the projects, which have “won” the tombola up to now. The presented agile review approach also fits to the three believes of software process improvement (SPI) from [KOR12].