About that Scrum Master/Agile Project manager role…
This article isn’t out to start a flame war and say there’s no such thing as an Agile Project Manager. What it is going to discuss is that having a Scrum Master/Agile Project Manager role is an oxymoron and shows a complete misunderstanding of the Scrum Master & Project Manager role; if you’re project managing anything then I’d offer you’re not going to be doing Scrum.
It’s alright to accept this as well, you don’t have to do Scrum. I’m not sure you can really run anything that is classified as a project in an agile way, but I know for sure you can’t do Scrum within the constraints required by project planning and management. If this is deemed to be a truth then it follows you can’t be a Scrum Master & Project Manager.
But why?
M’learned peer Willem-Jan Ageling explains the significant differences between the Scrum Master and Project Manager jobs here and I’m going to expand on the differences between Product and Project development which he’s touched upon in that article.
Cross functionality and self organisation
Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. — Scrum Guide [SG]
Given the above — and understanding that in Scrum we work in timeboxes (Sprints) of a month or less — you could assert that we have very short projects. If you were being disparaging you’d say that Project Managers are essentially team admins, having to herd cats to help get stuff done, but given the fact that Scrum teams are self-organising and have all the people within the team needed to get stuff done…there’s no one to herd, and a very short timeframe to keep in sight.
Projects vs Products
I freely admit that I find the idea of a project being agile highly circumspect. Based on my experiences I believe that what most people mean by “Agile Project” is that work is dropped incrementally in smaller chunks, which we can make changes to and learn from, but not fundamentally change what we’re doing/where we’re headed. By way of example let’s say we complete the coding of a feature, we then test it and find a few issues. These are fixed, so we release it. The load on the servers are higher than expected so we change our configuration/autoscaling/cluster size/insert something you’d change here.
And then we move on to the next feature in the plan.
This is project delivery (and you could argue that it is agile, the manifesto makes no mention of products). This isn’t Scrum as it isn’t truly empirical. Confusing feedback from the various stages of delivery with that from customers using what you’ve produced is where the distinction truly lies between project and product development. This distinction is important because:
Scrum is a framework for developing, delivering, and sustaining complex products — SG
Trying to apply project management practices to Scrum tends to lead to ScrumBut (or ScrumButt has Mauro Strione has brilliantly called it [welcome to the Shiteration] and captured in the below illustration):
However, if you were genuinely doing Scrum you may make use of complimentary practices such as OKR’s; a useful tool/approach to follow to help support a truly agile approach to product development; I’m convinced it is impossible to truly utilise them and work in a project way at the same time. An objective in the OKR sense is not a list of features we will deliver by a certain time. Rather, it’s something we want the product to have achieved, with the path to get there not completely known or understood. There’s a rough idea, and we know what we’re going to do first, but depending on how the first things go we may change what we do next.
There’s an popular analogy of route planning with maps vs sat navs using traffic information to dynamically route you that supports this really well, I’ll write another article (or find a good one) to explain this further in the future for those who need it.
I’m bringing this sort of approach up as it just does not map to any project management methods, but it’s clearly compatible with Scrum, and therefore the Scrum Masters. As a reminder of some of the services of the Scrum Master to the PO of :
Understanding product planning in an empirical environment;
Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
Finding techniques for effective Product Backlog management; — SG
With Scrum not offering prescribed methods the team is free to discover what works for them in order to get the work done (and make the progress visible to all). If we keep in mind the fact that, when done correctly, each Scrum Team contains all the necessary skills to get work done (and has very few external dependencies) and frequently reviews the progress of the work Done then there’s no need for the sort of work that a project manager does.
Papering over cracks
As an Agile Project Manager you maybe reading this and having a derisive laugh. “This isn’t the real world though” you think, “Scrum Masters need to get their heads out of their arses and see the world for what it is”.
Here’s my perspective. Scrum will not solve your problems, but it will highlight problems that are preventing you from utilising Scrum in its entirety (and therefore being unable to realise all of its expected value). Having an Agile Project Manager to help “make it work” is missing the point, you’re papering over cracks, hiding inefficiencies/deficiencies from view. The reason we say there’s no need for Project Managers in Scrum is because there shouldn’t be, if we were doing it right.
Scrum is, in my opinion, a habit breaking (and new habit forming) framework; it’ll be uncomfortable, there will be moments where you realise you can’t so something it requires of you. You are — as a group of people and as an organisation — going to have to change, don’t rob yourself of the opportunity by hiding the ugly problems by having someone who’s there to co-ordinate all the things that shouldn’t need co-ordinating.
Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. — SG
So what?
My aim was to show the real differences between project and product development, and how that Scrum (being a framework for developing and sustaining complex products) is so comprehensively different to project development that there is no way you could be both a Scrum Master & Agile Project Manager at the same time.
You’re either doing Scrum or you are not. It doesn’t mean you aren’t being agile in your approach if you aren’t, it doesn’t mean that there is no such thing as an Agile Project Manager either; it does mean that you cannot possibly have both in the same area of work.
More often than not these “dual roles” are on projects and they are using practices inspired by Scrum to do the work in iterations, but this is not Scrum. It’s iterative, not empirical.
I firmly believe that it is important to be honest with yourself about this, there’s little value in pretending you’re doing Scrum when you are not. Following Scrum means something (or it should). There’s a certain level of expectation associated with it: the roles, the production of a done increment each sprint, following empirical product development. If you need an Agile Project Manager then employ one of them, but be under no illusions that you’re doing Scrum and accept that you may not reap the expected rewards.
