Figure 1 overviews the major workflows that a Disciplined Agile® (DA™) program is associated with. Note that feedback is implied in the diagram to keep it simple. For example, where you see the Roadmaps & Models 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 improvement suggestions workflow with Continuous Improvement could be a conversation between two or more people, it could be an email, or it could be a detailed document – or combinations thereof.
Figure 1. The relationship of program management to other aspects of your process.
The following table summarizes the workflows depicted in the diagram.
|
Process Blade |
Workflow with Program Management |
|
All teams should use or reuse existing assets whenever appropriate. |
|
|
Your continuous improvement efforts should result in improvement suggestions gleaned from other teams that the program can learn from, and your program team should choose to share their learnings too. |
|
|
The program will generate data that can be used in your organization’s overall business intelligence strategy, and your program will use such intelligence as input into their decisions. |
|
|
The enterprise architects will produce roadmaps and models that delivery teams should follow where appropriate. |
|
|
The governance team will provide guidance to all teams, including large delivery teams. This guidance will focus on a range of topics, including: financial and quality goals; regulatory constraints; technical guidance (security guidelines, data standards, …); and other subjects pertinent to the program. |
|
|
Your organization’s portfolio management activities will provide the initial vision and funding required to initiate a program, as well as ongoing funding for the program. |
|
|
The Product Management team will provide a product roadmap, define the minimum business increments (MBIs), and share stakeholder priorities with the program team. |
|
|
Your program will release solutions via your organization’s release management strategy. |
|
|
Your support/help-desk team will provide change requests, including defect reports, identified by end users. These change requests are potentially new requirements for your program. |
There is clearly overlap with some of the activities in the portfolio management, enterprise architecture, release management, product management, and governance process blades. The issue is one of scope. Where these process blades address activities across your organization, the scope of the related activities within program management is the program itself. For example, where enterprise architecture addresses architectural issues for the entire organization, the architecture activities encompassed by program management relate only to the architecture of the solution being produced by the program.