The traditionalists are starting to be quite dangerous in the hostile “take over” of Agile and Scrum (Kanban can’t be far behind).
In this post Glen tries to tell us that it is ok to call “project management” what we do in a Scrum (f. ex.) development effort.
Now, that would not be so serious if he did not go and quote the list of activities in the PMBOK and explain that because you are doing those, then you are (by syllogism, one supposes) doing Project Management. Well, it’s not that simple as I try to explain in my comment to this article:
It’s not that simple. One of the biggest changes that Agile brings to the development of software is that, for most (usually) so-called projects, Scrum (or other methods) change the approach to a more continuous work approach, i.e. the work is always ongoing, just the input (requirements) are being managed in a time frame (release).
So, to answer your question (are you doing project management in Scrum?), in many software projects you DON’T have project management, you have WORK management. Nevertheless you have all of the activities you list (except project initiation). Which also shows how useless the list is, because you always have those activities in any endeavour, project or not.
To sum it up. I think that PMBOK is a good read for newbies and people starting in WORK or PROJECT management, just like many other books are, but PMBOK is dangerous in one aspect: it singles out different aspects that should/must be part of every day work. Take the example of Risk management: in Scrum all activities in the process are risk management activities (planning, daily meeting, demo, retrospective…). If you follow PMBOK you get the idea that Risk Management is actually a different activity that may even include different actors/stakeholders. This is BS, pure and simple.
In my opinion PMBOK and the prevailing approaches to Project Management today are simply dangerous and destroy customer/shareholder value.
We need a new paradigm in project/work management and Scrum is a good start!
3 thoughts on “To all PMBOK, PMP and PMI people: you are missing 1 million points! Stop trying to explain something you don’t understand!”
>> in Scrum all activities in the process are risk management activities
A profound point, Vasco!
Gosh. It is hard to post comments on Blogger – so “NOT INTUITIVE” – I hope an improvement is lined up in next iteration !
Right. Now to my comments, on your comments.
“More continuous” work approach. Yes PMBOK understands that, the lifecycle is adaptable and I can really see a fit between scrum sprints for example and iterations of the initiate/plan/execute/monitor-control/close cycle. Note that one should not assume that the plan/execute/monitor are completely sequential in PMBOK: they are NOT. It really depends on what’s your need.
About the “list”, its call the Knowledge Areas. I don’t believe they apply NOT only project management. If they apply then you are probably managing a project, however small it is.
About Initiation. I am very surprised. The team surely comes up with some sort of authorisation to kick off some work, the product owner surely have some initial thought about the features he wants to see built, and the scrum master and the team are surely assigned to the project in the first place…Isn’t it Initiation?
PMBOK has a process group called Integration that exactly does what you said it does not: bringing it all together.
I will agree with you on few things though. Because of its size and structure, PMBOK is heavy to read and digest and once you read it you still need create a PM framework that fits your organisation. PMBOK is NOT a methodology and people easily gets confused because they think it is…and also mistakenly associate it to Waterfall…it is so easy to read it as it was waterfall.
Don’t get me wrong. I love iterative approaches, I always tried to favor them, even in the start-up I am part of I keep on pushing an iterative approach to the planning with many suppliers. I keep having push backs by the CEO because he wants to see a massive Gantt Chart with all dependencies. That’s crazy.
There are two aspects that I see some sort of opposition beetween Scrum and PMBOK: procurement and the project manager role.
PMBOK really stresses the importance of the contract and buy doing so somehow did not stress the “soft skill” of customer collaboration.
With PMBOK, the project manager is responsible for nearly everything. That’s not the case with Scrum where the responsibility is shared.
Again, PMBOK and Scrum and 2 different things and I really enjoy both of them for what they are.
The big difference is that a PMBOK-style project has a beginning and an end, while Scrum and Agile methods attempt to achieve a continuous flow.
There is no “project initiation stage” in Scrum. The pre-work state is seen as an anomaly and the first thing the team does is kick off a sprint to slap together some skeleton code that will eventually become the product.
Comments are closed.