Our software dev team is currently using kanban for our development lifecycles, and, from the reasonably short experience of a few months, I think it's going quite well (certainly compared to a few months ago when we didn't really have a methodology).

Our team, however, is directed to do work defined by project managers (not software project managers, just general business), and they're using the PMBOK methodology.

Question is, how does a traditional methodology like PMBOK, Prince2 etc fit with a lean software development methodology like kanban or scrum? Is it just wasting everyone's time as all the requirements are effectively drawn up to start with (although inevitably changed along the way)?


3 Answers 3


I'm not a massive expert in this area. But I think that you can try two things here:

1 Use a Kanban board to visualise the PMBOK/Prince2 process that's being used. Simply show the Project Managers this 'visualisation aid', for me that's what Kanban is for - showing you where you have bottlenecks and blockers. Assuming you get the usual waterfall style problems, you'll be able to show this on your Kanban board as the workflow gets slowed or blocked at various points. You can then use this as a starting point to get them to come around to agreeing to letting you run the project in a more agile manner.


2 Take the requirements and split it into a Kanban style project anyhow, but do some analysis/preparation up front on how you can report progress back to the Project Managers in a Prince2/PMBOK manner (that will be comfortable to them). You might find that the PM's don't care how you run the project, as long as the reporting meets their needs.


Other responders got it right that Kanban can be used to map out your existing process and be a great visual tool. But there is more to it.

Limiting WIP (work-in-progress) works even if you have all requirements up-front. When you have 100 features in the backlog at the start, you can still limit your work to, say 5 (depending on your team capacity) and focus on finishing them. The requirements will change inevitably, but the changes won't affect the features you haven't started yet. One of the lean principles is to eliminate waste, and one of the kinds of waste is excessive inventory - this is how you can reduce it.

Kanban is an engine for improvement. When you begin using Kanban, it may only a management tool for moving work items from requirements to completion. But, with time, it makes you understand your workflows deeper and suggests improvements to the process.

To answer the question in the third paragraph of the original post, adopting Scrum would mean changing people's roles and the process. You would immediately create a conflict with your project managers.


Don't have enough points to vote up karianna but I agree with him. I moved from developer -> software PM -> Project manager which is now expected to do PMP/Prince2 reporting on software projects. It is fairly simple to map any agile/kanban method to fit within the Prince2/PMP structure. In the end the only reason people want/need this is to see the progress! So if you can visually show the progress/bottle necks and risks then I can't see any PM insisting on anything else.

As far as requrements go, I would also tend to let the business requrements not get too detailed so that the developers themselves decide how best to break it down into smaller detailed tasks. It is possible, you just have to sit down with the PM and discuss his/her (reporting) requirements and then see how you can provide him/her with it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.