In this blog posting, the latest in our ongoing disciplined agile program management series, we overview the external workflows that a large delivery team is likely to be involved with.
Workflow With Other IT Teams
The following diagram overviews the major workflows that a disciplined agile program is associated with. Note that feedback is implied in the diagram. For example, where you see the Technology Roadmap and Guidance flow from Enterprise Architecture to Program Management there is an implied feedback loop from the program to the enterprise architects. Also note that the workflows do not necessarily imply that artifacts exist. For example, the data guidance workflow from Data Management could be a conversation with a data management person, it could be a concise description of data standards, or it could be detailed meta data – or combinations thereof. A second example would be a program providing their development intelligence to the IT governance team through automated rollup of metric data via your organizations dashboard technology.
The following table summarizes the workflows depicted in the diagram.
The activities associated with these process blades are often very highly related. For example, in some organizations the activities associated with enterprise architecture and reuse management are fulfilled by a single group. In other organizations some product management activities are performed by the portfolio management team and some by the enterprise architecture team. Some organizations may choose to have a separate group for each process blade. And of course the organizational structure will evolve over time as your various teams learn how to work with one another. Every organization is different.
Program Management and DevOps
A common question that we’ve gotten is how program management is affected by DevOps. For example, you see in the diagram that Operations, Support, and Release Management (amongst others) are shown as things that are external to Program Management. Remember that the focus here is on process, not on team organization. For example, in organizations with a disciplined DevOps strategy in place it is very common to see program teams taking on the responsibilities of operating and supporting their own systems in production, and of doing the work to release their solutions into production. In organizations without a strong DevOps mindset (yet), you are likely to find that operations, support, and release management are done by separate groups outside of your program team. Context counts, and it’s good to have a process framework that is flexible enough to support the situation that you find yourself in.
We recently published an article describing how the Disciplined Agile Delivery (DAD) framework is being extended to cover Portfolio Management activities. The following diagram depicts the DAD goal diagram for Portfolio Management, and as you would expect your organizations has a range of options to choose from. In this diagram we use the term endeavor to refer to a project, product, or experiment.
The article describes each one of these process factors – Identify Endeavors, Explore Potential Endeavors, and so on – in greater detail. A future version of the article will describe the strategies/practices associated with each factor. We have also included a high-level workflow diagram, see below, to overview from the point of view of the Portfolio Management process blade how it fits into the rest of the Disciplined Agile (DA) toolkit.
An interesting aspect of the flow diagram is that it shows the relationship of Portfolio Management to other IT Plan activities. For example, Enterprise Architecture provides a Technology Roadmap and Product Management provides a Business Roadmap and an indication of stakeholder priorities – all critical information that are inputs into the efforts around prioritizing potential endeavors. The point is that this diagram reflects workflow, not organizational design. For example, in some companies there is no Product Management team, instead responsibility for the Product Management activities are spread out amongst several teams. A common strategy is to have the Portfolio Management team responsible for understanding stakeholder priorities and the Enterprise Architecture team responsible for the business roadmap. Another approach would be to have the Portfolio Management team subsume both of those activities. A third approach would be to have three teams, one for each of Enterprise Architecture, Product Management, and Portfolio Management. Different organizations will make different organizational design decisions, and of course these decisions will evolve over time. As always, context counts.
I hope that you find the more detailed Portfolio Management article to be of interest.