Scrum and PMI. Can They Co-Exist?

Scrum, PMI, both? I think that if you try to put the two in the same sentence you will often get very different and even highly polarized responses. I hold a PMP certification from the Project Management Institute and come from that mindset. When I began learning about software development Waterfall was the way! That’s how you did things. The PMI PMBOK facilitates this very well. It’s good for organizational change, building bridges or buildings, and software projects that are fixed… even simple in nature. From a PMI viewpoint we can often make software projects simple if we only break them down enough. That’s a huge point though – we often don’t have the time or resources to do this properly. One can argue that that is an organizational issue, but we have to think and act in reality.

Over the past couple of years I have seen and learned of organizations taking on more and more projects without changing resource allotment. Fewer people to do more things. Less often do we have dedicated BAs, forget about dedicated QA or PMs. Because of that, any sort of project management in the eyes of somebody who holds a PMP is non-existent. I found this very troubling! Documentation…where did it go? Formal test plans? All the things that I found important as a BA and PM appear to be becoming a rarity. Ok – rarity may be exaggeration, but they are definitely a shadow of their former selves. As the workload on a  group grows heavier and heavier it is easy to slip into the mindset that it may be better to just focus on the code… just get it out there…”be agile.”

I felt as though I was seeing this mindset come on as Scrum was employed in my shop  – or so I thought. You see, I am really a project team of one as of late so I really only get to see what is going on in the development side of the house from the outside. For a PMI guy it looks like chaos and skipping integral parts of the software delivery process. However,  I recently had the opportunity to attend a Professional Scum Master course (at Improving Enterprises), and while I already understood the general concepts and principles of Scrum, I did not know it in its entirety and prescribed practice. I didn’t understand all of the nuances and above all its absolute practicality!

I had only previously seen and understood this agile framework as what Scrum.org refers to as Scrum But… Now, this is purely speculation in my part, but I would venture to say that the vast majority of shops that say that they’re using Scrum at not using Scrum. They are using some version of Scrum But… “We are a Scrum shop, but we don’t do retrospectives.” “We are a Scrum shop, but we don’t have product owners.” “We are a Scrum shop, but we don’t have fixed sprints.” You can see where I’m going.

The class that I took was fantastic, and I  have to say that I can now completely buy into Scrum.  I see its purpose and that you can’t get the most from Scrum unless you really use it all. You can’t just take pieces. I also see that while Scrum doesn’t dictate them it also doesn’t call for dropping good practices like requirements docs, test plans, or the best practices found in the planning, execution, and control parts of the PMBOK. Instead it places those responsibilities on the Scrum team. The team must select what is most appropriate to use. I think that it is a sign of a high functioning team when they are not just scraping by with code alone. Documentation is still good…what happens when your product goes into support or a new team becomes responsible for it? If you haven’t been keeping track of what you’re doing and why you’re doing it…well…that new team is just SOL. That being said, a mature and high functioning team will know how much is enough and not get bogged down in too many formalities.

Just as in a formal PMI based project if you were to take absolutely every part of the PMBOK and try to employ it the project would risk unnecessary bottlenecks and resource bog down. The only mandates from Scrum are:

1. The five events – the sprint, sprint planning (including a sprint goal), daily scrum, sprint review, and sprint retrospective
2. A product backlog and a sprint backlog

That’s really not a whole lot! And that’s the beauty of it – it’s up to the team to fill in the gaps… do what makes sense, but don’t ignore those things which are known as good practice.

Coming from PMI and then learning Scrum I see such a tremendous amount of similarity between the two in what they ate trying to accomplish. Think about it… work breakdown structure, planning, risk mitigation, communication plans, product owners, planning  executing, closing, etc. All of these things are part of the PMBOK, and their all part of Scrum albeit under different names. That probably makes a lot of folks on the Scrum-only side cringe.

At the start of this post I stated how troubled I was by what I saw as the breakdown of what I knew as project management. After getting to better know Scrum I can say that I am much more comfortable. I can see a good combination of what I know as a PM and BA with what the Scrum framework provides. I would like to see what a fully followed Scrum framework could provide my shop, but now that I better understand Scrum I can see why we’re using it. I added a PSM I (Professional Scrum Master) certification alongside my PMP, and it was time well spent! I see that together they provide a very good foundation to manage successful projects.