Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Welcome back to this occasional DevOps.com series on Enterprise DevOps Q&A. Remember, if you have questions about DevOps in the enterprise, let me know and I will try to answer them (or find someone who can). E-mail me at andi.mann@ca.com, tweet me at @AndiMann, or leave a comment below.
This week brings a question about DevOps that could only come from a large enterprise:
Q. For software development and IT operations, the picture is quite clear. But in my company the PMO has so much control over what projects we take on, what their scope is, when they are due, etc. How can I encourage and enable DevOps in our PMO?
Startups and ‘DevOps unicorns’ likely have never worried about dealing with a Project Management Office (PMO), but this is a very common process gate for enterprise-scale organizations. The PMO provides essential capabilities to plan application strategy, gather requirements, prioritize projects, allocate resources and budgets, manage project risk, and report on delivery, especially across complex organizations. However, as with many uniquely ‘enterprise’ departments, the PMO often seems like a significant bottleneck too.
That means enterprise DevOps initiatives must bring the PMO along too. After all, you cannot deliver business-critical software faster if you have no idea of your business priorities or requirements. You cannot claim a successful release without measuring how (or if) it has delivered on business goals. While this will often happen organically in small businesses, in large enterprises this is the remit of the PMO.
Unfortunately I have not seen a lot of ‘best practice’ (or even ‘good practice’) advice on this yet, as DevOps discussions have focused mainly on smaller organizations. However, what I have seen working in large enterprises to foster a closer relationship between the PMO and the DevOps teams is a shared approach to agile Project and Portfolio Management (PPM).
I have seen this shared, agile PPM working in three key ways:
Align development with business priorities
First, a shared, agile approach to PPM helps the PMO and DevOps teams come together and collaborate to prioritize development of capabilities that matter to the business. The PMO shares portfolio priorities and project plans with dev, ops and other stakeholders; dev and ops share development estimates and operational requirements to enable accurate planning with realistic timelines. DevOps teams can help foster this collaboration by bringing PMO stakeholders into requirement gathering and agile planning, even into standup meetings as part of the scrum methodology. This benefits DevOps teams too, by ensuring immediate feedback and shared alignment against business goals.
Manage agile parallel development and continuous operations
Second, encouraging DevOps teams to track and report on timelines, resources, and deliverables helps the PMO to report back to business leaders on progress across multiple parallel projects. In large distributed enterprises, DevOps teams can assist by sharing granular project status (e.g. burndown, commits, etc.) with PMO stakeholders, so they can measure delivery against business objectives. Shared project reporting also helps DevOps teams to measure themselves, and assign responsibilities appropriately too. This shared commitment to business deliverables is itself a key objective of DevOps in any size organization.
Measure and iterate the SDLC
Third, a shared, agile PPM approach can help drive iteration back into development. After new features have been released, shared reporting means the PMO can immediately measure the impact of new releases on business priorities. This also allows them to ensure DevOps teams have delivered against the prior plan before they reassess the current portfolio and start on the next plan. With shared project reporting, the PMO can adjust project plans to reflect achievements, prioritize the new set of macro and micro gaps, and close the feedback loop back by driving requirements into the next development cycle.
Shared, agile PPM tools and solutions
Much of this change – as with all DevOps change – is primarily cultural; it is not necessary to use specific PPM tools to enable an agile, shared approach to PPM. However, as with many activities in DevOps, automation and tooling can certainly help. Especially in large enterprises with complex portfolios and geographically dispersed teams, a shared PPM toolset may be essential.
As you mature and move from waterfall to agile development and DevOps, all stakeholders will appreciate a shared PPM solution that allows a business view of the current application portfolio, a shared view of planning and priorities, common management for both waterfall and agile projects, and roll-up reporting of application delivery and portfolio value. You may find your current PPM solution already fits; or you may need to consider supplementing or replacing it.
Where agile and DevOps aim (at least in part) to accelerate time-to-market for new business ideas by bringing business closer to service delivery, a formal Project Management Office can seem like a brake on productivity. However, as the whole business needs to go faster, IT teams can help bring the PMO onboard the DevOps train with a shared, agile approach to Project and Portfolio Management.
