When discussing the fundamental changes brought about by DevOps, we tend to focus on a few roles: The people writing the code, the people provisioning and supporting infrastructure, and the people testing and doing QA.
As DevOps culture spreads, however, so does its impact on other areas of the organization. Take project management: DevOps fundamentally changes how IT teams approach projects, shifting away from monolithic, multi-month (or multi-year, in some cases) initiatives in pursuit of greater speed and agility in the software development lifecycle. That means changes for project managers, too.
But make no mistake: Project managers can still be valuable in the DevOps age.
“A need for speed and velocity – and cutting-edge DevOps technologies and processes – does not replace the need for knowing what you’re going to do with them,” says Josh Collins, technology architect at Janeiro Digital. “A strong project management practice is required in order to keep projects moving on schedule with a clear focus on dependencies.”
But PMs do need to evolve for the DevOps age, just as developers, ops practitioners, security pros, and others need to drop some old habits in favor of ways that are better suited for the digital era.
“PMs can’t just be focused on the Gantt chart and calling meetings,” says Robert Reeves, co-founder and CTO at Datical. “PMs need to be more involved in the actual guts of the dev and release process.”
We asked Collins, Reeves, and other IT leaders for their insights on how the project manager role needs to evolve for DevOps. Their recommendations:
Apply agile to project management
Agile is not just a software development methodology; it’s a way of managing the ongoing need for long-term projects in concert with the continuous integration/continuous delivery (CI/CD) approaches of the DevOps era.
“To reconcile the agility and speed of DevOps with long-term projects, you need to understand the nature of agile development,” Reeves says. “If you are not agile, you duck into a basement and come out after a few months – years, maybe – with a release. And you are going to [make mistakes that] you can’t fix because there is no opportunity to course-correct without a change order.”
Take a microservices approach to projects
Just as microservices architecture breaks up the monolithic enterprise app into more granular services, projects can also be split into much smaller, interdependent pieces of work.
[ What DevOps specialties are in demand? See our related article, DevOps jobs: 4 trends to watch. ]
“Traditionally, project management has been more monolithic and waterfall-methodology-driven,” says Mike Kail, co-founder and CTO at CYBRIC. “With DevOps transformation, the PMO function needs to take a ‘microservices’ approach that enables much higher velocity due to the smaller sub-projects.”
This mindset is baked into an agile approach to PM, says Reeves. Not only is it far more suitable for DevOps culture, it simply leads to better outcomes.
“With agile, you course-correct with every release. You take that big release and break it down into ‘fun-size’ portions, so it’s easy to show results and get feedback. Even if you are wildly off course, you can correct,” Reeves says.
PMs should be experts in dependencies
The microservices approach to project management includes another corollary: Just as there are plenty of potential benefits to isolating services in a “do one thing and do it well” manner, it’s also important to understand how those smaller pieces work with one another. Here, PMs need to play an increasing role.
“As velocity of delivery increases, the importance of [shining a] spotlight on dependencies increases. There is now less time between deployments to integrate something from an upstream team or less time to get a full requirement from a stakeholder,” Collins says. “Using a scrum methodology to break down work into the right atomic units where their dependencies can be well-known is critical. Tools like Kanban boards can allow immediate views into lapsed dependencies and the ensuing blocked work.”
Project plans needs to evolve
Rethinking project management practices for DevOps requires a shift in one of the PM’s traditionally significant roles: Developing and managing a project plan.
“Reducing the timeline of a delivery cycle means you can no longer afford to update a project plan once a week,” Collins says. “Project managers need to be in the know on a daily basis, hustling down issues before the train leaves the station.”
“In the age of DevOps, IT project managers must plan differently,” says Ian Buchanan, developer advocate at Atlassian. “A common misunderstanding is to only adjust for the time dimension – for example, just plan a milestone at the end of every two-week sprint. This misses how essential both speed and quality are to DevOps.”
Buchanan offers this advice for PMs on supporting that vital combination:
- Create integrated plans that account for unplanned work. “That means creating project buffers with the evidence of past performance for things like incidents and defects [unplanned work].”
- Ensure that the feedback from testing, staging, and deployments to real customers is being used to re-plan. “Scope may need to be added and/or removed frequently based on the new information.”
- Find ways to break large projects into chunks that enable the business to get incremental value. This is again the “microservices approach” to PM, but with the additional dimension of measuring value to the organization of each increment of work. That’s not necessarily a new PM practice, Buchanan notes. “For example, if you upgrade the OS on 100 servers, each server is an increment of value. However, DevOps opens new ways for this to happen, like using feature flags to roll out a feature to a subset of users.”
PMs should use the same tools as the team
DevOps is about, among other things, tighter alignment and collaboration among once-siloed roles. That includes (or should include) standardizing on a toolchain. PMs should not be an exception here.
“Project management needs to be tightly integrated from both a practice and tools perspective,” Buchanan says. “IT project managers need to use tools that help teams manage all their work, not just the project work. Software developers have been doing this with scrum for years. In a DevOps world, that means all the work flows through a simple work tracking system, including IT project work and incidents. This is critical to ensure that fast-changing priorities are simple and clear.”
Reeves notes that PMs in a DevOps environment should be able to answer the question, “Is it done yet?” – or its close relative, “When will it be done?” – with zero human interaction. If you need to ask someone, that’s a problem, because it means the project management function isn’t properly integrated with the same tools and tracking mechanisms the rest of the team relies on to do its work.
“The biggest challenge in project management is seeing if individual tasks are progressing on time. Agile sprint burn-down, velocity, and other metrics tell you exactly that,” Reeves says. “It’s not enough to ask the dev and test teams if they are on schedule; project management is about seeing those metrics for yourself in a tool like JIRA. The same goes for the release. It’s not enough to look at a ticket to check status. PMs should be looking for the DevOps teams to provide them dashboards on how the release is progressing.”
Project managers need to embrace MVP approach
PM success in DevOps culture requires being a bit less precious about the “finished” product, according to Kail – project plans might still have end dates, but the work is never really finished in a CI/CD world. And, as Reeves notes, managing projects in an agile manner enables you to course-correct and fix flaws on a regular basis without a massive change-management effort or a whole new project altogether.
“[Project managers] need to take the ‘done is better than perfect’ view and embrace [the] Minimum Viable Product [approach],” Kail advises. “Continuous measurement of all things important to the project is key, as is the tightly coupled collaboration.” Kail points to regular scrum meetings or stand-ups as a good mechanism for doing this.
[ Check out our related article by Ebix CIO Muthu Arumugham: Why minimum viable product isn’t just for startups. ]
PM titles will likely evolve with DevOps
The traditional IT project manager role seems unlikely to become extinct in the foreseeable future. But as DevOps organizations mature, it’s quite probable that PM responsibilities and skill sets with be fused with other job titles and roles, just as DevOps jobs will continue to morph.
“Although the skills and experience of a PM can bring value to any team, the very name may be going out of style for software. DevOps brings a focus to flow – a continuous cycle of work in a value stream,” Buchanan says. “The kind of generalized practices suggested by PMBOK are replaced by highly specialized techniques that rely heavily on automation. Increasingly, the function of project management is being reorganized into roles like scrum masters and product owners.”
