What is the role of a Software Delivery Lead? I often get asked this question. The answer isn't short or simple. So I decided to write it up here and point all those people who ask me, to this article.
I must be honest, writing this does not feel comfortable. I fully accept that this piece will never be the only definition of the Delivery Lead (DL) role and that many of you would disagree to an extent or fully with my understanding. So, in a way, this is a very selfish exercise for me, allowing me to point people to my article every time I need to explain my understanding of the Delivery lead role in Software Development context. If you are already utilising the Delivery lead role in your organisation I would also suggest to look into my article about the Discovery Lead role (coming soon).
You will see that, in the text below, I have managed to (almost) avoid using terms like Agile, Lean and Scrum. While these terms could add some useful context for some people, I have grown extremely disappointed with the use of the terms in the wider community and for me they have been semantically stretched to a point that makes them significantly less useful.
And one final thought before I get to the point – this article was prompted by another similar article, which was shared by someone on a slack channel I happen to be in. I do find value in the above article however 1) it is not my definition so I wouldn’t point people to it and 2) it discusses a slightly different role and I often find myself working in an environment where several Delivery leads and one Delivery manager are working together to deliver a large piece of work and the roles, as I see them, are quite different.
For me, there are three characteristics of the Delivery lead role which make it different from many other well-defined roles in Software development.
1. The goal of the Delivery Lead is to create the best possible conditions for all of (note: these are not in priority order; they are equally important)
a. the delivery team - to produce the required finished item e.g., product, service, etc. (I will call this “right way”)
b. the Business team – to choose well what is to be delivered and when (“right thing”, “right time”)
c. the customer (“end user”) – to ensure they can solve their problem using the finished product/service (“right thing”)
2. In my world, the role “delivery lead” evolved from the role ScrumMaster so naturally it has some overlap and much influence from Agile delivery methods and Lean Start-up.
3. The role can have a different shape between engagements depending on the context, therefore there is a lot of flexibility of what a delivery lead does day to day.
I will now go into detail for each one of the above points. You may find that some of the explanation is vague and if so, I am willing to address that. But I would prefer to stay generic, rather than to suggest practices which are only applicable in certain context or are one of many choices.
Helping the delivery team deliver
As hinted earlier, this part of the role can take different shape, depending on the environment. The DL may need to borrow practices or approaches from different fields, perhaps discover what’s the latest on certain topic and maybe experiment to see what works.
To begin with, I would suggest, establishing how to measure the rate of delivery. And when I say measure, I need to stress immediately that we only measure to learn and never to compare or judge. To measure the rate of delivery, a DL could borrow techniques from Lean, Kanban or even Scrum, as well as other methods. I am sure there’s more than one way and I won’t get into an argument which one is better. But if you must know, personally, I am a fan of Kanban metrics (or if you can use innovation accounting). Once you know how you measure progress, you can then use it as a benchmark so you can see how changes you and the team make will affect this benchmark. As you progress you can monitor how the metrics change over time and improve them to serve you better.
What do I mean by “taking a different shape”? Here’s an example (or two). Say a DL joins a team of individuals who have previously worked in a very siloed environment. The biggest challenge for that team might be to develop the skills necessary to work effectively as one team. While continuous integration/deployment might be great to have, this team is more likely to benefit initially by learning to work effectively together. So, the DL should focus on improving that aspect first. In another scenario the DL might be joining an established Scrum team that do many things well, but they deploy their code to production only once per month. The DL then might focus on exploring how would the team go about to move towards continuous deployment.
Then there’s the human aspect of the role. Things happen in people’s lives, and we can’t ignore them. One day everyone would be cheerful and happy and the very next day some people might be worried or anxious. There often isn’t anyone else around to do something about it and the DL will need to step in. Often just being present and asking, “How are you” and listening is all that is needed.
The DL role is one of continuous discovery of what works well, how to measure better, how to do better, how to protect and help the team and the individuals in it to do better. On the journey the DL might find that they are equipped to handle some of the challenges and not others, so they would have to remain open minded, continue to educate oneself about approaches that worked for other teams or individuals and remain positive while helping their teams and people grow.
Are there non-negotiable qualities or practices that a DL will need to employ regardless of the context? There probably are, and a few come to mind, although saying anything more specific would be an opinion and most certainly not the only thing that works. Just so I don’t leave this very vague, I can narrow it down to the following principles, or values if you like, which I teach as a good foundation - communication, simplicity, feedback, courage, and respect (some of you will recognise them as the XP values)
You might have noticed that I called this section also “right way”. The DL role is a lot about finding the right way in the current context. The right way to help this specific team in this specific environment achieve as best as they can. This will most certainly not be a universally right way. And it almost certainly will keep evolving. Context really is king.
Helping the business team choose what to be delivered
Many winters ago, I worked with an exceptional team of brilliant individuals. People with extensive experience and understanding of Agile and XP practices, which was relatively rare at the time. Working in that team, I was able to learn and record useful tips and practices many of which I continue to apply. At the time, we were lucky enough to work with a client who was able to accommodate many of our requests, including the availability of a Product Owner of the right calibre. Here’s how we defined the product owner role (for our purposes)
And there she was our PO, as if taken from the textbook, capable of doing all the above and always confident and knowing what to do next.
Little did I know at the time, that over the coming years, I will face many frustrating moments with organisations finding it very difficult to provide a person who can do all the above. Moreover, even if there was somebody, resembling that magical, empowered PO that we once had, they were very unlikely to know what to do next. Here are the main issues I’ve come across:
o The PO sits way too high in the organisation and while they can make decisions, they are unable to make decisions on priority or scope at the level the delivery team needs them
o The PO sits lower in the hierarchy and therefore are unable to make useful decisions on either priority or scope
o The PO is unable to make decisions without consulting with SMEs which leads to constant delays
o The PO seems confident (perhaps even overconfident) and is allowed to make decisions on priority and scope however their decisions lead to bad results
There are many books and articles discussing the Product Owner/Manager role. When the DL is lucky enough to work with a great product manager, then there might be very little for the DL to do in that respect. Which means that the DL will need to adapt to the needs of the organisation. Here’s what I think the DL can do to help PO/PMs do better
o Ensure there is a clear definition of what is considered successful in the smallest possible chunks of functionality (e.g. features)
o Ensure that there is a good way of establishing if a feature is successful or not, and the ability to test the likelihood of success before the feature is developed. This could be through 3rd party analytics, custom built solution or even manual or semi-manual testing.
o Ensure that there is a good strategy in place to prioritise features that will be developed.
With the above in place, the PO/PM should be in a good position to decide what is “right thing” or the right feature to be focusing on right now (“right time”).
Helping the customer succeed
Arguably this should be at the forefront of any list. It is equally, if not more, important than the rest of the points. The purpose of any business should be first and foremost to serve their customers, followed by serving the people of the business and finally generating profits to allow the business to continue serving its customers and people.
While this thinking may have become popular in more recent years and in some forward-thinking companies, it is sadly, far from being the norm. Therefore, it represents an opportunity for the DL to add value by teaching the PO/PM and the organisation about the benefits of shifting towards serving customers as the highest priority of the organisation. This isn’t a well prescribed activity and can take different form depending on the context. Here are some ideas of what the DL can do to help shift the focus to the customer
· Question every feature and business decision about how it helps the customer (end user)
· If a form of user testing is not already in place, work towards introducing it and expanding to cover the customer (end user)
· Remind the PO/PM to consider the customer when making prioritisation decisions.
In order to achieve the “right thing” for the customer, the DL may need help from others e.g. User experience designers, User researchers, User testing specialist, etc. It will be once again a case of finding out what is possible and what works in the specific context.
DL role roots and the need to adapt
As I mentioned before, for me the DL role evolved from the ScrumMaster role in Scrum. While I am sure others will have had different experience, the progression from ScrumMaster carries a lot of practices that are implied. For instance, as DLs, we will organise our teams to be able to work with a business owner (PO/PM or others) to plan a piece of work (e.g. an iteration) and to deliver working software often. The teams are also likely to employ many XP practices like Planning, TDD, Refactoring, pairing, small releases and so on.
The DL role is difficult to define precisely because of the need to adapt to the specific conditions and needs of the organisation and people. I cannot stress how important this is. Every organisation is a little or a lot different from the others we’ve worked with, and we cannot and should not try to apply the same process we have used elsewhere. There will always be some who would try to sell you a fully prescribed process that will work everywhere. My advice would be to stay away from them. Remember that your role is to your team, the business, and your customer (end user) achieve their goals and people who have never experienced your context will never be able to give you a very good advice.
In conclusion I find the DL role quite exciting as it gives you an opportunity to get involved with different aspects of the organisation and to help different people achieve their goals. The DL role may not be a specialist role, but you can get involved in all of “right way, right time, right thing” and that covers just about everting in the process of creating software.
Welcome to our blog!
About the author
Plamen is a LeanStack coach and an experienced Software Delivery consultant helping organisations around the world identify their path to success and follow it.