Have these two approaches been causing your company friction? We've been concerned that they can seem to pull in different directions from a management point of view; but the business situation in iMedia - flexibility, fast-changing scope, and clients who want to see faster results - all play towards Agile.
It can come across as an us versus them situation between programmers and the rest of the team and management. Yes, you guessed it, it all comes down to control!
First let's clear up the Agile/DSDM approach conundrum. Agile techniques can fit under a Dynamic Systems Development Method (DSDM). DSDM has guiding principles that back iterative and incremental development: Agile seems to fit perfectly here. But DSDM goes further as it enshrines higher level management aspects like focusing on the business need, communication and quality: aspects of a project that fit with Prince2 methods. The linking mechanism may well lie in understanding DSDM.
However, DSDM, like Agile, is seen as an IT project methodology, whereas Prince 2 fits an international general project management image. There's the positioning of the relative approaches in a nutshell. If you work with clients who have a general business background they are more likely to relate to Prince2 principles which make overall communication easier in theory. If your clients are used to working with IT, they may well be au fait with Agile and/or DSDM approaches so communication at the product development stage might not be as big an issue as it can be. Doesn't it all relate to the project context?
If there is friction between your inter-team approaches involving Prince2 and Agile, there are pros and cons on both sides and both parties need to understand the core criticisms that can be valid. So, Agile methodology can be seen as: lacking discipline, lacking rigour, over-emphasis on product development, needing strong collaboration from clients, client-driven, putting over-reliance on visual documentation, nibbling away at the true project.
Prince2 can be seen as: over-bureaucratic, using linear development (a waterfall approach in IT terms), light on product development, a straight-jacket,over- business-driven, prefers non-visual documentation, takes too long to start, over-zealous about specification.
These can all be true depending on the context of the project, and projects differ as we know. Perhaps emphasis on one approach may be needed for one project and the other for another. What is clear is that unless your team are all pulling in the same direction, your project will suffer. The answer might lie in combining the best of both approaches because then they might demonstrate that ‘flexibility and dynamism can exist from within a structure of stability and control’. See page 8 of Agile project management: Integrating DSDM into an existing PRINCE2® environment, Best Management Practice White Paper.
This white paper is worth a look if your company is having bother with these aspects. Another perspective that reinforces the two working together can be viewed at Indigo Blue Consulting.