Keith is the Chief Executive of agilekrc and has over 30 years’ experience in I.T. and project management. In 2007, Keith led the team that created DSDM Atern and was subsequently part of the team that created AgilePM. In 2011 Keith was awarded “Most Valuable Agile Player UK” at the Agile Awards.


Mirosław Dąbrowski: AXELOS made a stable move towards Agility by publishing PRINCE2 Agile with you as a Lead Author. Also back in 2007 you wrote a book explaining how to combine PRINCE2 with DSDM. I’ve got a lot of questions from Polish market asking about the difference between PRINCE2 Agile and DSDM/AgilePM. Should we look at them as competitive? Is there room for both standards?

Keith Richards: They are essentially in the same place which is in the project space. So it is not for business as usual, it’s not for continuous development of products, it’s not for programmes. If you are running temporary initiatives that have a start and the end and the Business Case let’s say maybe 6 months long or 8 months long – this is a project and both AgilePM/DSDM and also PRINCE2 Agile address this problem. They are both frameworks to address working in the project environment. So they are in the same space you can therefore say they are competitive products. The difference however is that PRINCE2 Agile is a qualification and you need to be PRINCE2 Practitioner to start with. If you are not a PRINCE2 Practitioner you can use either. If you are PRINCE2 Practitioner the most sensible choice will be to use PRINCE2 Agile. Many of our customers of agileKRC are DSDM and AgilePM users and we have no intention of advising them of doing anything different. If it isn’t broken don’t fix it.

MD: So basically you can choose AXELOS approach or AgilePM. AgilePM has been a bit longer on the market. Where and when we should use them? Can you provide key differentiators?

KR: You’re correct, AgilePM/DSDM has been around longer, it’s established, it’s been out for 4 or 5 years, maybe the last 2 or 3 years it’s been quite popular. I was lucky enough to be Lead Author in 2007 when we created the new version of DSDM. So that is one advantage, many people are using it. PRINCE2 Agile has not got much experience, it’s only been out a couple of months. Yet PRINCE2 Agile is much more up to date. It includes and covers flow based Agile methodologies like KanBan. It refers to things like Cynefin and Lean Startup. It is much more current, so to say a 2015 view of Agile. As one of the examples, the technique Story Point Estimation it’s been around for a decade or more in Agile, but just recently the people are saying maybe there are better techniques. Maybe it is becoming out of date. Not to say that it is out of date. But PRINCE2 Agile is able to be a very current version looking o Agile in today’s eyes. So what you loose with it’s immaturity you gain with the fact that it is more current.

One of the best distinguishers between the two both is that AgilePM/DSDM has very good structures for business systems. Of all of the terminology it is very much business focus, it is really for business systems in an IT environment. Where PRINCE2 Agile is much more generic, it is much more for customer-supplier situations. It’s terminology and it’s basis is a second reason if you want to differentiate.

Another differentiation is that DSDM/AgilePM has been independent of anything. PRINCE2 Agile is very much like PRINCE2 and therefore you will find some organizations that love PRINCE2 they are very good in PRINCE2 and therefor this will help with their decision. But equally you will find organizations that have problems with PRINCE2. That’s not a problem in PRINCE2 itself, it is only a framework. It is a problem of interpretation of the PRINCE2 guidance. They’ve made too many documents, it’s become too bureaucratic. It’s look like command and control. And therefore PRINCE2 may have bad reputation so it’s may be worth bringing something new.


MD: As a maincustomer of PRINCE2 Agile I see public organizations, but public sector likes to have predefined process, like step by step 1,2,3,4. PRINCE2 is a methodology, PRINCE2 Agile is a guidance. As an example you have a few options to choose from when combining Team Manager and Scrum Master roles. How you can sell it or target it to the public sector?​

KR: I think that if you are very linear in thinking that’s not a very Agile thinking  So the first thing I would say it doesn’t matter whether you are using Agile/DSDM or PRINCE2 Agile. If you’re linear in thinking you need to move to an Agile way of iterative and incremental thinking. The point of view you said is very interesting one because writing the product was quite hard and there was a team of more than 40 people involved. This simple question of where does the Scrum Master fit, does not have an easy answer. So this is why there are options and one of the reasons why there are options in PRINCE2 Agile is that it’s depend on the maturity of the agile teams you are encountering. If they are very mature you can run Agile in the certain way and link the delivery teams in to the project in that way. I understand that this may seem more like guidance and less prescriptive. But in order to get PRINCE2 Agile to work a lot of the times it cannot be prescriptive. The analogy I use, it’s like driving a car. If it is dark and you’re in the snow you would drive one way, if it’s in daylight and dry you will drive another. But I don’t think there is any real difference between AgilePM/DSDM and PRINCE2 Agile. I think they are both provide guidance, they are both providing frameworks and with both you can be over bureaucratic, you can put into rigidly, equally you can put into too flexible.

MD: So it’s all about how you interpret and implement a specific method?

KR: It is very important, this bad implementation point you said. There are many very good project managers who understand how to use the tools and they understand how to use the framework. And the same applies with the AgilePM/DSDM. You can do both badly, you can do both well.

MD: PRINCE2 Agile offers a tool called Agilometer. Can you elaborate more on Agilometer?

KR: Yes, we are getting a very good feedback on Agilometer. One of the things that certainly I’ve noticed from the experience and all the team that worked on this, agreed with was that Agile is not really a situation of ‘yes or no’, whereas sometimes people refer to it as ‘all in’. A good example of this is the very expression of ‘an Agile project’. If you have an Agile project then by definition there are projects that are not agile. What we came up with was the fact that really everything can be Agile, but it’s a matter of degree. You can have a very, very agile project and you can have a project that is not that Agile. But zero is not really an option, you can still use a lot of techniques, you can still use a lot of behaviours. 100% agile is almost impossible to achieve. We made it really important to get across this point that it is a question of how much agile you can use in every situation. Not a question of yes or no. What was created out of that was a risk assessment tool, a very simple tool that is easy to use but highly productive. That was to identify six key sliders that really if you like define what is an agile environment. What you do, you look on each slider. Importantly you look at them independently. You must not to average the sliders. That will give you a bad result. You look on your sliders and you look where your areas of weakness from an Agile point of view is. If I may give you one example, we have something like the communication slider. If everyone is collocated and we are on the same room it would be on 5, high. If you’re delivery team is in India or your project is spread on three continents your slider will go low. What does means, there is risk to agile’s communications, therefor we have to address it and try to move the slider and mitigate those risks.

MD: Years ago, OGC developed P3M3 model for assessing maturity. I see some connections between Agilometer and P3M3. Do you have any information if the AXELOS is planning to extend P3M3 with Agile aspects?​

KR: To be honest Mirek, P3M3 is not my area of expertise. Yet one question I get all the time is about “where does the PMO fit into Agile”? Many people think PMO is irrelevant to Agile. I think it’s right in the centre. The PMO is the guardian of your processes. If you are moving your processes to a much more iterative and incremental way of working and collaborative way of working, then the PMO needs to be able to support this. And therefore you need to check your maturity. But not being and expert at P3M3 I don’t know what the levels of maturity it’s measure. But I know from my own view, in the back of PRINCE2 Agile we have a health check and there a lots of factors you try to look at. Is this happening or not happening? So for example is collaboration happening? Is communication happening? These things would be an example of maturity.

If I may give you one specific example just to show how difficult things are. Things like facilitative behaviour, facilitative management of people… a little bit on the line of servant leadership… are people team players? So if you are looking on maturity of your teams or your organizations, you need to identifying and measuring these. And in fact you may even reward these behaviours in people competencies. So there is some tremendous levels of maturity and sophistication we can go into in those areas. Which I don’t think many people are even thinking of this at the moment. Many people are talking about agile maturity models, there are many different varieties. But I think this is a big area to exploit.


MD: Regarding the PRINCE Agile exams. There are lots of discussions on why there is no PRINCE2 Agile Foundation exam. Does AXELOS have plans to introduce PRINCE2 Agile Foundation exam in the nearest future?

KR: I don’t think there is. But from all that I know, we are looking at countries like Poland or other European countries, people will get the Foundation level and maybe they don’t go further to the Practitioner level. Whereas in the UK you will go to Practitioner level more often. I know that AXELOS is looking at this, because they do not want to have a disadvantage in such big markets like Poland…

The main reason why there is no Foundation level is really because PRINCE2 Agile is an extension to PRINCE2. So if you done PRINCE2 Foundation, you know Foundation level PRINCE2. If you have done Practitioner, you done Practitioner level of PRINCE2. The next thing up is really to be Practitioner in an extension. So AXELOS decided not to go back to the Foundation level.

One of the requests I made of AXELOS was the exam is going to be hard. The pass rate will be around 68-70%. We will get a lot of people failing the exam, because it’s difficult. There are too many exams at the moment that really are impossible to fail I would say. I believe this is not credible in the long term. I’ve heard someone referring to it as integrity debt…

MD: Any change in the exam regarding classic Practitioner exam?​

KR: It is Scenario based. But it is straight multiple choice, ABC or D. There is no Reason or Assertion, because a lot of feedback on things like reason/assertion is (actually) not really good way of testing people’s knowledge. AXELOS and the exams teams decided to drop the reason/assertion sections.

The exam is based on Blooms taxonomy level 3 and 4 questions. You have to know how to apply Agile aspects to PRINCE2. You have to know how, when and where to apply Agilometer.

MD: Yet the goal of the exam is not to be qualified as a master of Agility, but to prove that the candidate knows where and how we can inject Agile aspects into classic PRINCE2? I believe a clear example is how to use Burndown charts instead of Highlight Reports. The form is different but the purpose and set of information are quite similar.​

KR: In simple terms I generally agree with your point. Again, this is the problem with PRINCE2 Agile approach and the work we did was that you cannot just say replace this with that. Sometimes you cannot replace information with the burndown chart. If the project board are not that familiar with reading burndown charts. They may need to agree to present the information so they can read it this way… but again burndown chart provides some of the information for the Highlight Report. You still need to give information about risk and issues. So it may be spreadsheet it may be poster on the wall. The level of formality is to do with risk and appropriateness. Sometimes a camera shot of risk register presented on a wall is fit for purpose as long as it is a risk log. How you do it depends on your Agile level. It’s needs to be more informal and that’s what you do, you can replace this with this. This is why often in the PRINCE2 Agile guidance there are statements: “you can replace this with that”, “you may replace this with that”. Occasionally we say, “you do replace this with that”. But once you to start say replace this with the burndown chart, people will automatically will do it. But sometimes it is not appropriate to do this… honestly sometimes we had people changing the word may to will or will to may… the guidance has to credible, the guidance has to be correct.

MD: This closes our talk with thought that PRINCE2 Agile is a guidance rather that predefined/prescriptive methodology.​

KR: I think that AgilePM/DSDM and PRINCE2 Agile are all mixture of do this, you should do this and here is the guidance. But there are always some prescriptive elements. For example, do a business case. I think this is a good advice. Always do a business case. But how you will report this to the Project Board here is a place for guidance. This or that will be the recommended approach.

One of the most complicated things about this guidance, as we discussed is like driving to the conditions. You cannot tell someone that they go around the corner at 40 miles per hour if the corner is covered in snow and ice. You have to say – drive appropriately. But for example, you will always say put the safety belt on, because of the law.

MD: The analogy which I’m using on my trainings is a perfume. When you want to buy a perfume. In a classic/traditional approach you will read specification document about the product and you will try to understand your emotions and feelings which can hardly be possible. You have to simply feel it, taste it, smell it. Empirical process control​

KR: But also I think your analogy is very interesting because really to get the best result with the perfume it is best to involve the customer. Maybe by iterative and incremental way. If you go to the perfume shop, you have a small taste of perfume and slowly evolve and elaborate on your vision through a set of prototypes. You wouldn’t buy of all the perfume without trying first and ideally with the customer and the end user. I like this analogy. Smells good :).

It is good? You ok with the interview Mirek? “Dobsze, dobsze”?

MD: Not just “dobsze” but even zajb***  :)

KR: Ohhh I can’t remember what… what is was? … :)

keith_richardsKeith Richards

Keith is the Chief Executive of agilekrc and has over 30 years’ experience in I.T. and project management. In 2007, Keith led the team that created DSDM Atern and was subsequently part of the team that created AgilePM. In 2011 Keith was awarded “Most Valuable Agile Player UK” at the Agile Awards. In 2014 he was appointed lead author for ‘PRINCE2 Agile’. He is a published author on subjects relating to combining agile with PRINCE2.

Contact:,, +44 (0) 1934 710332, +44 (0) 7768 080 386

Mirosław Dąbrowski
Chief Operating Officer (COO) w ENP rozwijającej, wdrażającej i utrzymującej platformy eCommernce o łącznych rocznym cash-flow przekraczającym 10 mld PLN. Agile & Lean Coach. Konsultant oraz architekt rozwiązań IT z bogatym 13 letnim doświadczeniem w informatyce (help-desk, programista, tester, grafik, UX designer, analityk biznesowy i systemowy, administrator, kierownik projektu, audytor, product manager, scrum mastera, dyrektor). Mocno związany z inżynierią oprogramowania oraz ecommerce. Posiada 5 lat międzynarodowego doświadczenia jako Agile Coach (8+ jako Scrum Master). W Polsce uczestniczył w transformacjach między innymi w ABC Data oraz BZWBK. Autor narzędzi do badania dojrzałości projektów zwinnych. Anglojęzyczny, międzynarodowy trener z szerokiego obszaru zarządzania oraz umiejętności miękkich (zarządzania tradycyjne oraz zwinne) oraz IT (programowanie, testy, bezpieczeństwo, audyt). Posiada 12 lat aktywnej praktyki trenerskiej w ramach której przeszkolił oraz coachował ponad 5000 osób w Europie. Wiodący autor 50 akredytowanych szkoleń. Akredytowany trener PRINCE2, PRINCE2 Agile, MSP, MoP, P3O, ITIL, MoV, M_o_R, PRINCE2 Agile, RESILIA, AgilePM, OBASHI, ASL2, BiSL i wielu innych standardów. Facylitator Playing Lean oraz Lean Startup. Ma za sobą ponad 100 certyfikacji w zakresu inżynierii IT oraz szeroko pojętego zarządzania. Twórca 50+ interaktywnych map myśli nt. zarządzania oraz IT (ponad 2mln odwiedzin i 150.000 polubień): Prelegent na wielu międzynarodowych konferencjach (w tym tych największych jak Agile Europe organizowanych przez Agile Alliance), autor, mentor, wykładowca. Aktywny członek zarządu PMI Poland Chapter. Inicjator programu transformacji usług IT w PMI PC. Jako IT Product Manager jest odpowiedzialny za portfel inwestycyjny z obszaru portali internetowych. Dba o roadmapę oraz wizję rozwoju (w tym utrzymanie oraz standaryzację) w ramach 10 portali internetowych PMI PC. Dwukrotny finalista prestiżowego międzynarodowego konkursu Agile Awards w kategoriach: "Najlepszy zespół stosujący metodykę DSDM/AgilePM" oraz "Wkład w promocję metodyki DSDM/AgilePM na świecie". Jedyny w Polsce certyfikowany DSDM Agile Trainer-Coach oraz Certified Disciplined Agile Coach (CDAC). Ekspert merytoryczny organizacji AXELOS (właściciela metodyki PRINCE2). Tłumacz standardu PRINCE2 Agile. Ambasador konsorcjum DSDM International (pierwszy w Polsce certyfikowany DSDM Agile Professional). Tłumacz metodyki AgilePM. Pasjonat metodycznego podejścia do zarządzania projektami oraz nieustannego rozwoju ku nieokreślonej doskonałości.