Agile software development methods are a known as a paradigm shift from the traditional waterfall model towards iterative development. But there is one major misconception about agile methods, namely that they compete with “Old-time Project Management” (Milliken, 2014), or more precisely, the traditional Stage-gate model. This mistake results from a lack of understanding of the scope of Agile methods. As Zade (2004) notes, Agile methods are a product development methodology, not a project management methodology. This means that agile processes correspond to managing product delivery (MP), a PRINCE2 process. Hence, agile methods are merely a subset of project management, which is a much broader concept as reflected by the comprehensive PRINCE2 method.

From the above reasoning, it follows that it is theoretically possible to combine Agile methods with PRINCE2. According to Karlstrom & Runestrom (2005), agile methods can be more effective when they can benefit from the advantages of a stage-gate model. The two approaches are complementary in the sense that agile methods enable day-to-day operational excellence by empowering developers, while a stage-gate model, in turn, gives a means to coordinate with stakeholders and possibly other development teams. The need for such integration is likely driven by the need for project management support after adopting a particular agile method. The underlying assumption is that specific project management processes contribute to a controlled project environment. So the combination is in potential beneficial. The question remains: is it really feasible from a process perspective?

In this article an example is provided of integrating PRINCE2 with Extreme Programming (XP) in order to illustrate an answer to the above question. The combination of PRINCE2 with XP is on the one hand challenging because of conflicting philosophies (Agility vs. Control), but on the other hand, logical because XP does not provide any guidance with respect to project management, and therefore, PRINCE2 is highly complementary. Even in case of agile methods that do describe (or prescribe) PM practices, there is little conflict with PRINCE2 as these practices are mainly limited to managing product delivery (in some cases also Project Planning). And in the context of managing product delivery, PRINCE2 prescribes a few practises (i.e. activities) that can coexist with Agile practices. In any case, agile processes mostly focus on product development (a specialist discipline).

Combining methods is a form of method adaptation, which is a field of science. In case of XP the need for method adaptation is made explicit. One of the fundamental ideas of XP is that there is no process that fits every project as such, but rather practises should be tailored to the needs of individual project. A distinction can be made between static method adaptation and dynamic method adaptation (Aydin et al, 2005). The key assumption behind static method adaptation is that the project context is given at the start of a project and remains fixed during project execution. The result is a static definition of the project context. Given such a definition, route maps can be used in order to determine which structured method fragments should be used for that particular project, based on a predefined sets of criteria. Dynamic method adaptation, in contrast, assumes that projects are situated in an emergent context. An emergent context implies that a project has to deal with emergent factors that affect relevant conditions but are not predictable, and thus, occur unforeseen. This also means that a project context is not fixed, but changing during project execution. In such a case prescriptive route maps are not applicable. The practical implication of dynamic method adaptation is that project managers often have to modify structured fragments or even innovate new fragments, during the execution of a project (Aydin et al, 2005). The integration of PRINCE2 and XP, which will be illustrated below, is an example of static adaptation. The need for additional project management support when adopting an agile method such as XP is the relevant (static) project context.

Critics will argument that PRINCE2 is far too bureaucratic for XP. And they may have a point when dealing with smaller projects. Moreover, XP as any Agile method is recommended for the smaller type of projects with less than 20 developers. On the other hand, PRINCE2 recommends tailoring or scaling the method according to project needs. For example, in smaller projects the method advises to use informal communication instead of documentation in certain situations. The key thing is that in some cases the added value of project documentation can be justified, and in other cases documentation can be deleted or automatically generated (Karlstrom & Runestrom, 2005). It should be noted that the PRINCE2 principle: Tailor to suit the Project Enviroment is inherently Agile.

Based on analysis of both methods, PRINCE2 and XP, and their processes in particular, it is concluded that integration is feasible. This feasibility of a PRINCE2-XP (or vice versa) integration can be demonstrated by means of a process-data model, see Figure 1 below. The elaboration of such model shows how PRINCE2 complements XP by providing project management support during a project’s lifecycle. It should be stressed that the model does not reveal any conflicting areas between the two domains with respect to processes or concepts. The latter can be explained by the fact that an agile method like XP is clearly confined to product delivery and its management, a sub-process of project management – the point that was made in the beginning of this article and was generalized to all agile methods.

Figure 1: PRINCE2 & XP Integration method fragment

A closer examination of Figure 1 shows the integration of two PRINCE2 processes: Managing Product Delivery (MP) and Controlling a Stage (CS), with three XP lifecycles: Iterations to release phase, Productionizing phase and Maintenance phase, which are embedded but not made explicit. The remaining three XP lifecycles: exploration phase, planning phase and death phase, are part of other fragments, which are not included here. Figure1 illustrates that key XP principles such as incremental and iterative development are not in conflict with the two Prince2 processes. Iterations are represented by loops, which by definition are not prohibited by Prince2. Increments are represented by small releases, and correspond to the Prince2 concept of Work Package. Furthermore, each work package consists of a number of stories to be implemented during the iteration, and is executed during a Stage. During any stage one or more Work Packages are executed. Important feedback from the customer is captured in the Issue Log. Once this feedback is collected after a small release, a decision is made whether new changes as requested by the customer will be implemented in the next release (invoking a new iteration), in a later iteration (or Stage), or even in the maintenance phase.

Table of Concepts:

Table of Activities:

References

Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On the Adaptation of An Agile Information Systems Development Method. Journal of Database Management, Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24

Karlstrom, D., & Runeson P. (2005). Combining agile methods with stage-gate project management. IEEE Software, 22(3), 43-49

Milliken, J. (2014). Agile: The End of that Oldtime Project Management? Retrieved October 8, 2014, from https://www.linkedin.com/groups/Agile-End-that-Oldtime-Project-37888.S.5921359246678577156?view=&gid=37888&type=member&item=5921359246678577156&trk=nmp_rec_act_group_discussion

Onna, M., & Koning, A. (2002). De kleine Prince 2: Gids voor projectmanagement. PinkRoccade Educational Services / Ten Hagen Stam Uitgevers.

Zade, B. (2004). Agile: The End of that Oldtime Project Management? Retrieved October 8, 2014, from https://www.linkedin.com/groups/Agile-End-that-Oldtime-Project-37888.S.5921359246678577156?view=&gid=37888&type=member&item=5921359246678577156&trk=nmp_rec_act_group_discussion.