When you adopt agile practices, especially agile life cycle plans – it is really simple to have your project manager become the scrum-master, right? Isn’t that what everybody does? After all, it’s just swapping a gantt chart for a burn down chart, right?
It certainly is what all of the project managers do when their companies start to adopt agile life cycles – but is it the best thing, or even a good thing?
Since I don’t believe that the dogmatic Scrum = Agile equation is true, I will avoid the term scrum master, and instead define a role called agile delivery manager. I believe that this more accurately describes what a scrum master serving a truly agile team does. An agile delivery manager is responsible for aspects planning AND execution of the software delivery process, but he is not usually responsible for the budget, the schedule, the staffing and resource planning, nor is he responsible for managing other organizational risks and constraints.
Responsibilities:
- planning and executing the delivery activities as defined in the life cycle as implemented.
- ensuring information (typically feedback from later process areas to earlier process areas) is flowing appropriately, observed, analyzed and consumed by the team and used to improve software delivery practices.
- coaching the team through understanding of new or adjusted practices introduced into the life cycle.
- creating accountability within the team for fulfilling team members responsibilities within the agile life cycle as implemented.
- helping the team focus on working in a rational sequence following a rational approach with a reasonable probability of delivering desired value according to an established schedule.
- exerting influence within the team to resolve all of the human dynamics issues.
- managing, and escalating risks from delivery activities to a greater governance structure. This assumes that there is a governance structure beyond the agile team.
Requirements for Success:
- understand enough of the business domain to be able to hold the team’s focus on the business value proposition within each goal the team commits to.
- understand enough of the technical domain to understand the technical risks arising from the technology paradigm and the software development process.
- understand the agile life cycle and agile practices in use, and the information flow required including the metrics and data points used in feedback loops.
The project manager role is broader, less focused on delivery team productivity, and more focused on a broader consortium of stakeholders. A project manager role can be executed as either active or passive – depending on leadership within the team. Project managers typically have responsibility for budget and schedule commitments, as well as intra and inter-organizational dependencies and schedule coordination.
This is in stark contrast to the delivery manager who is focused exclusively on the team, the practices, and daily information flow that supports rapid adaptation and tactical problem solving in the software development process and practices.
When one expects a single individual to excel at both sets of responsibilities concurrently, with different focuses and different required capacities, one might be disappointed at the result.
D Bonneville
January 24, 2017 at 10:22 pmI know this article is a few years old, but it came up first when I searched for “director of delivery vs project manager”, and cleared up some fuzzy understanding on my part. However, your last sentence, after the whole body of the article, seems to contradict itself. You say “When one expects a single individual to excel at both sets of responsibilities concurrently, one can be surprised at the result.” Don’t you mean “When one expects a single individual to excel at ONE SET of responsibilities concurrently, one can be surprised at the result.”, the point being that the director of delivery is focused on his team, etc., and not focused on the budget, scheduling, etc? Or did I miss the point?
Rich
January 26, 2017 at 11:42 amSurprised is a negative. You are correct. It was certainly ambiguous. Since then I have learned about Elliott Jaques work that cumlminated in Stratified Systems Theory and how roles are separate from “jobs”. I would say that the delivery manager as I defined it has a much shorter time-span of discretion than a traditional project manager, and should focus on the iteration length or “measurement cycle” of the team and maybe one or two iterations forward. Whereas, a project manager has a time span of discretion that is a release at the minimum, and maybe one forward. An agile product owner has a time-span of discretion of a “budget cycle” and maybe one forward. I use delivery manager as a proxy for scrummaster (‘cuz not all agile teams do scrum). I am not sure that is what you are thinking when you mean delivery director.
Depending on the complexity of the product or project there is also “horizontal” discrepancies in the responsibility that differentiates the three roles. delivery manager is focused on a team or a small number of teams and is responsible for “pace”. The product owner is dedicated to one product and all of its teams and stakeholders or customers and is mostly responsible for sequence. The project manager is split between the team/product and any other contracts or dependencies on other teams, products, vendors or parties and is responsible for outcomes that require coordination across parallel work streams.
D Bonneville
January 26, 2017 at 11:57 amSurprised = negative. I missed that! It makes sense now. At my company, “delivery manager” as you define it seems about the same as “director of delivery”, but our DoD will have several projects going on at the same time. Our agile teams do not scrum by default, and we loosely sprint, with kanban all the way, but that can vary. The rest of your definitions for time-span of discretion very helpful. Thanks.
Rich
January 27, 2017 at 4:11 pmIf you are interested in the time-span of discretion stuff check out the Management Skills blog by Tom Foster. He is a great resource for Stratified Systems Theory stuff and has lots of very down to earth examples. Also his book “Outbound Air” is also a great read and brings the concepts in novel form rather like “The Goal” did for Theory of Constraints back in the day.
Also if you want to learn specifically about agile program management in the large check out books or blogs by Johanna Rothman – she is my go to guru for agile management issues.