There’s a new role that is starting to take shape in the realm of software development, and that’s the role of Delivery Lead but what exactly is this role and why, suddenly, is there a need to define this new space in the fast-paced world of software?
Let’s take a closer look at this role and see if we can bring some clarity to why this role has started to emerge in the industry. In this article I’d like to set the stage and address the question of “why?”. In a subsequent post, I’ll dive deeper into what Delivery Lead does day-to-day and the value they bring.
Oddly, it’s easier to define what a Delivery Lead is not, so let’s start there. There are a couple roles that are related and sometimes get confused with this role: Project Manager, and Scrum Master. Suffice it to say a Delivery Lead role is neither of those, and here’s why…
A Project Manager is a well defined role that has existed, it seems, since time began. PMI (the Project Management Institute) is the arguably the leading authority of all things project management (at least in North America) and has written the bible on project management. That bible is called the PMBOK (Project Management Book of Knowledge) and it’s currently in its sixth edition. This guide delves deep into defining what a project manager does, what a project is, and the various stages, or lifecycle, of a project. I’ve had the (mis)-pleasure of reading this book from cover-to-cover and am fairly familiar with what’s inside. Based on the contents of this book, it’s clear that a Delivery Lead is not a Project Manager.
The entire software development world has eschewed “classic” Project Management, and particularly “waterfall” approaches to planning software for some time. Those deep dark waterfall-esque caves are where classic Project Management flourishes; this is where Agile comes in, but we’ll get to that topic for later.
A project is any temporary, unique (non-routine) effort that has a beginning and end. Building software rarely involves projects.
PMI defines a project, roughly, as any temporary, unique (non-routine) effort that has a beginning and end. That’s great in things like construction, or when you’re renovating your home, but software delivery is a whole different beast, and an ugly beast with two heads, at that. Software companies rarely dedicate themselves to discrete efforts that “begin” and “end” and then go away; rather, building software is an on-going effort — an evolution. It often has a start, albeit often a messy and rather ad-hoc one, and there’s rarely an end.
This is particularly true when a company starts with a simple, basic idea and then scales quickly. That original idea sustains a company often for years and that initial effort snowballs into an enormous cloud of confusion and uncertainty that has to be wrestled and reined-in in order to stay relevant and keep providing value to the company as it scales.
Project Managers are good at initiating, planning, executing, monitoring, and closing projects (conveniently, what the PMI defines as the 5 phases of a project lifecycle), but software, like a misbehaved school boy, doesn’t adhere to this neat lifecycle. Rarely are there common and discrete phases in software development that need planning; at least not in any well-defined manner. And that’s why a Delivery Lead isn’t a Project Manager.
Making software is chaos: it’s enormously complex, unpredictable, and it becomes obsolete the moment it’s written. It’s more akin to growing a plant than constructing a building. Once the seed is planted, it needs constant watering, love and sunlight to flourish. Forget to water it once and the leaves start to brown and whither; if you’re not careful the entire plant dies with it.
Software also has very little tangible value until it’s made accessible to somebody, which is why the notion of “Delivery” is so important in the software space. Indeed, software delivery used to involve throwing your code onto a server and seeing what happens, but this has evolved into its own deep and delicious realm of knowledge with its very unique challenges, depth and complexity.
Delivery Lead’s are almost exclusively associated with building software. The knowledge and skills of project management are useful in many realms, but they’re not that useful in software delivery.
Okay, so we get it — software is complex. Classic Project Management doesn’t align well with the chaos and complexity involved; so where does that leave us? Well, this is where Agile comes in.
Any discussion about software delivery would be incomplete without mentioning Agile. I don’t want to dive too deep into the pool of Agile in this article; there’s already a lot of knowledge out there and most people will already be quite familiar with Agile. Suffice it to say:
In software, if classic Project Management is the disease, then Agile is the cure.
And the promises are real. Agile is a great framework for delivering software! It often gets a bad reputation, especially amongst developers who, at times, feel subjected to tyranny of sprints and meetings, but I think this reputation is due more to poorly implemented or over-zealous interpretations of the framework, rather than a flaw in Agile itself.
Most software companies will choose Scrum as their Agile framework of choice. There are many other frameworks but we’ll stick to Scrum because that’s probably the most common one being used. Scrum has three main roles: Scrum Master, Product Owner, and the development team. Arguably, the client or stakeholder has a role here too, although they’re not an official role in Agile; let’s just not forget about them. A Scrum Master is a role that’s team-facing—Scrum Master’s are servant leaders to the team. Often, the Scrum Master is also a member of the team and also doing the work, which most often is software development or quality assurance.
Therefore the Scrum Master is a SME: what the project management world calls Subject Matter Experts (the people who do the work). In our case the “subject” is software development. So it goes without saying that most Scrum Master’s understand the work really really well since many of them live and breathe it in the trenches along with the team. This should permit them an inherent authority and garner some respect from the team. That knowledge allows them a unique perspective where they truly understand the complexities and challenges of software development — and that’s valuable knowledge! The point I’m trying to make here that the role of Scrum Master isn’t a disposable one, it’s a valuable and unique role.
So why, then, are a few companies creating a Delivery Lead role and throwing the Scrum Master role out the window? The answer is: I’m not sure. A Delivery Lead is an entirely different focus. It’s not a roleintended to replace the role of Scrum Master, or worse yet to replace Agile altogether, rather it exists (or rather co-exists) to augment and compliment it.
Delivery Leads aren’t a part of the Agile world, but they’re surely allies.
One other thing worth noting is that the Delivery Lead role seems to have emerged in larger, more mature companies that are scaling, and I think that’s no coincidence. When a company scales, it begins to encounter a whole new range of challenges. Chiefly amongst them is the inability to deliver software reliably, and quickly. Agile tells us getting working software into the hands of stakeholders for feedback is important, and we need to do it quickly, but as a company scales the ability to do that inherently slows.
There are new processes, skills, pipelines, and infrastructure that need to be built to support a growing and maturing software company. Initially, this added responsibility falls on the existing developers, who once only had to worry about writing code, but soon find their primary focus shift to building automated test suites, pipelines, and cloud infrastructure. [We could get into discussion on DevOps here, but now is neither the time or place for that].
Then there’s the added complexity of inter-team communication and cross-functional initiatives. Major change require coordinated efforts across all teams and Scrum Master’s soon find their focus shifting externally, from their own team to the development organization as a whole, as they desperately scramble to try and provide some glue to hold all these new disparate initiatives together and focus efforts.
At the same time managers and executives begin to drown in information and complexity as their ability to keep a finger on the pulse of daily operations slips. Team-focused metrics, like velocity or predictability, become less important in the fog of scale, and longer-term cross-team initiatives, like reducing tech-debt or improving performance, tend to emerge as the pimrary focus. This results in a natural shift in reporting needs of executives in the organizational. Scrum Masters are very well-equipped to report on team metrics, but less so to report on cross-functional happenings at the level executives require.
This is where Delivery Lead roles start to emerge and become important; to fill the vacuum that emerges as a company begins to scale.
How exactly? We’ll delve into the three main aspects of a Delivery Lead role in a subsequent article, but there are three main areas a Delivery Lead can add value:
- By helping to deliver software
- By working with teams
- Through providing leadership
We’ll pause here and in my next article explore each of these avenues in a bit more depth and also talk about how this is a strategic role.
The views and opinions expressed are those of the author and do not necessarily reflect the official policy or the position of any entity.