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.
||Process Blade Overview
||Workflow with Program Management
||Addresses how to support process and organizational structure improvement across teams in a lightweight, collaborative manner; how to support improvement experiments within teams; and how to govern process improvement with your IT department.
||Your continuous improvement efforts should result in improvement suggestions gleaned from other teams that the program can learn from.
||Addresses how to improve data quality, evolve data assets such as master data and test data, and govern data activities within your organization.
||The data management group will provide data guidance, such as naming conventions and meta data regarding legacy data sources, to all delivery teams.
||Addresses strategies for collaborative and evolutionary exploration, potential modelling, and support of an organization’s architectural ecosystem in a context-sensitive manner.
||The enterprise architects will produce a technology roadmap that delivery teams should follow and be a good source of development guidance (such as programming guidelines, user interface conventions, security guidelines, and so on). Delivery teams will provide development intelligence (metrics) and feedback pertaining to the usage of key architectural components and frameworks to help inform the decisions of the enterprise architects.
||Addresses how to develop solutions in a disciplined agile manner. This includes the four lifecycles – basis/agile, advanced/lean, continuous delivery, and exploratory – supported but the DAD framework plus the program management blade (effectively a large team following one or more of the lifecycles).
||There will be dependencies,both technical and functional, with other delivery teams (not shown in the diagram). These dependencies between teams must be negotiated and managed appropriately.
||Addresses strategies for consolidating various governance views, defining metrics, taking measurements, monitoring and reporting on measurements, developing and capturing guidance, defining roles and responsibilities, sharing knowledge within your organization, managing IT risk, and coordinating the various governance efforts (including EA governance).
||The IT governance team will provide guidance to all IT teams, including large delivery teams. This guidance typically focused on financial and quality goals as well as any regulatory constraints where appropriate. Delivery teams will provide development intelligence to the IT governance team to enable them to monitor your team and provide informed guidance to it.
||Addresses how to run systems, evolve the IT infrastructure, manage change within the operational ecosystem, mitigate disasters, and govern IT operations.
||Your operations group will provide operations intelligence (metrics) to IT delivery teams, in particular around the usage of systems and features that a team is responsible for. This enables the IT delivery teams to make informed decisions regarding the value of delivered features.
||Addresses how to identify potential business value that could be supported by IT endeavors, explore those potential endeavors to understand them in greater detail, prioritize those potential endeavours, initiate the endeavours, manage vendors, and govern the IT portfolio.
||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. It will also provide guidance, often around management and governance conventions, to the team. IT delivery teams will make their development intelligence (metrics) available to the portfolio management team to help inform their decisions.
||Addresses strategies for managing a product, including allocating features to a product, evolving the business vision for a product, managing functional dependencies, and marketing the product line.
||The Product Management team will provide a business roadmap and stakeholder priorities to all IT delivery teams, including programs.
||Addresses strategies for planning the IT release schedule, coordinating releases of solutions, managing the release infrastructure, supporting delivery teams, and governing the release management efforts.
||Your program will release solutions into production via your organization’s release management strategy.
||Addresses how to identify and obtain reusable assets, publish the assets so that they are available to be reused, support delivery teams in reusing the assets, evolving those assets over time, and governing the reuse efforts.
||All IT delivery teams should reuse existing assets – such as services, frameworks, and legacy data sources – whenever appropriate.
||Addresses how to adopt an IT support strategy, to escalate incidents, to effectively address the incidents, and govern the IT support effort.
||Your support/help-desk team will provide change requests, including defect reports, identified by end users to all delivery teams. These change requests are in effect new requirements.
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.
This posting, the latest in a series focused on a disciplined agile approach to program management, overviews the activities associated with program management. The Disciplined Agile (DA) framework promotes an adaptive, context-sensitive strategy. The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique. In this blog we present the goal diagram for the Program Management process blade and overview its process factors.
The following process goal diagram overviews the potential activities associated with disciplined agile program management.
The process factors that you need to consider for program management are:
- Allocate work. Work items must be allocated to delivery teams, or to open source efforts in the case of programs which include internal open source components, throughout the lifecycle. The type of work and the focus of the sub-team are the primary determinants of how work is allocated. However, team capacity and load balancing concerns, for example a team has run out of work or a team currently has too much work, will also be considered when allocating new work. Work allocation is the responsibility of your product owners although team capacity planning and monitoring is typically performed by the program manager and team leads. Regardless, these activities should be performed collaboratively by the available people at the time.
- Prioritize work. The work performed by the teams – including new requirements and fixing defects – needs to be prioritized. There are several ways to prioritize the work, such as by business value, by risk, by severity (in the case of production defects), or by weighted shortest job first (wsjf) to name a few strategies. Prioritization is an ongoing activity throughout the lifecycle and is the responsibility of your product owners.
- Plan program. Traditional programs are often planned on an annual or even ad-hoc basis. Agile programs, at least the disciplined ones. tend to be planning on a rolling wave basis.
- Organize teams. There are three common strategies for how you can organize delivery teams within a program – feature teams, component teams, and internal open source – each of which has advantages and disadvantages. In addition to delivery teams, in a large program you are likely to find the need for leadership teams – the Product Owner team, the Architecture Owner team, and the Product Delivery/Management team – made up of the product owners, architecture owners, and team leads from the delivery teams respectively. These leadership teams are responsible for work/requirements coordination, technical coordination, and management coordination within the program respectively.
- Coordinate teams. There are several ways that the sub-teams can coordinate with one another. For example they could choose to have cross-team coordination meetings (also called a Scrum of Scrums (SoS)); they could visualize the work through task boards, team dashboards, and other information radiators such as a modeling wall; they could choose to have “big room” planning sessions where all team members are involved or “small room” agile modeling sessions where a subset of people are involved; or even traditional (or agile) checkpoint meetings. All of these strategies have their advantages and disadvantages, and all can be applied by the various types of teams mentioned earlier.
- Coordinate schedules. There are several strategies that a program can adopt to coordinate the schedules between sub teams. The easiest conceptually, although often hardest to implement in practice, is to have all sub-teams on the same cadence (e.g. every sub-team has a two week iteration). This is what both SAFe and LeSS prescribe. Another option is to have multiplier cadences where the schedules of sub-teams align every so often. For example, we once worked with a large program where some sub-teams had a one-week iteration, some had a two-week iteration, and a few had a four-week iteration. We’ve also seen another team where sub-teams had one, two, or three week iterations that provided alignment of iteration endings every six weeks. Most common, although rarely discussed, is for sub-teams to have disparate cadences. This is guaranteed to occur when teams are following different lifecycles (remember, the DA framework supports several). For example, when some sub-teams are following the Scrum-based agile/basic lifecycle that has iterations, yet other sub-teams are following the lean or continuous delivery lifecycles that have no iterations, then you have an alignment challenge. Or if you have sub-teams adopting any iteration length they like (we’ve seen some programs with sub-teams with two, three, four and sometimes even five week iteration lengths) then they also in effect have disparate cadences.
- Schedule solution releases. Programs need to schedule their own releases, in accordance to your organization’s release management strategy, which involves coordination between the sub-teams. When the cadences of the sub-teams are (reasonably) aligned then it is easier to coordinate production releases. For example, when all sub-teams have two-week iterations (or at least the sub-teams with iterations do) then they could potentially release into production every two weeks. In the case of multiplier cadences, there is the potential to release into production each time the iteration endings align.
- Negotiate functional dependencies. An important responsibility of the Product Owner team is to manage the functional dependencies between the work being performed by various sub-teams. There are strategies to manage dependencies between two agile sub-teams, between an agile sub-team and a lean sub-team, and even between an agile/lean sub-team and a traditional sub-team (this isn’t ideal, but sometimes happens).
- Negotiate technical dependencies. Similarly, an important responsibility of the Architecture Owner team is to work through technical dependencies within the solution being developed by the program.
- Govern the program. The program must be governed, both internally within the program itself while still operating under the aegis of your organization’s overall IT governance strategy. Program-level metrics, particularly those tracking the progress of sub-teams and the quality being delivered, are vital to successful coordination within the program. Sub-teams should also be working to common conventions, ideally those of the organization but in some cases specific to the program itself (perhaps your solution is pioneering a new user interface look-and-feel or new data storage conventions). Programs, because of their size and because they are usually higher risk, often have more rigorous reporting requirements for senior management so as to provide greater transparency to them. The implication is that a program’s dashboard often has a more robust collection of measures on display.
How Scaling Affects Program Management
Although program management primarily addresses the team size scaling factor, your tailoring decisions will still be affected by the other scaling factors:
- Geographic distribution. Chances are very good that large teams will also be geographically distributed in some way. There are two flavors of this: Are teams geographically distributed (e.g. in different physical locations) and are people within a team geographically dispersed (e.g. people are working in cubes, on different floors, in different buildings, or from home)? Both add risk. Coordination within the program becomes more difficult the more distributed the teams are, and more difficult within teams the more distributed the people are. Distribution hits the leadership (the product owner team, the architecture owner team, and the team lead/product delivery) teams particuarly hard because members should be located with their delivery sub-teams but also need to work regularly with their counterparts located elsewhere. The implication is that the team may require more sophisticated tooling to enable collaboration and more importantly be prepared to invest in travel regularly to foster better communication between disparate locations. Furthermore, when your stakeholders are geographically distributed it may require your Product Owners to get support from agile Business Analysts in the various locations to help elicit requirements from them.
- Compliance. Compliance, either regulatory compliance required by law or self-imposed compliance (i.e. CMMI-compliancy), will definitely have an effect on your approach to program management. In fact, the larger the program the more likely it is to fall under regulatory compliance due to the greater risk involved. Regulatory compliance generally requires greater governance both within the program and outwards facing as well. Under some regulations your coordination efforts will require proof that they occurred, such as some form of meeting minutes that capture who was involved, the decisions made (if any), and action items taken by people. Compliancy may also motivate more sophisticated approaches to capturing requirements by your Product Owners and to documenting technical concerns by your Architecture Owners.
- Organizational distribution. The larger the team, the more likely you are to involve contractors, consultants, or even to outsource portions of the work. When external organizations are involved the Program Manager will likely be involved it the contract management effort, which in turn may require assistance by the team leads.
- Technical complexity. The larger the team, the more likely it is that they are taking on greater technical complexity. Or, another way to look at it, greater complexity often motivates the creation of larger teams to deal with that complexity. Greater technical complexity will motivate greater attention to architecture and design, thereby motivating more regular collaboration of the Architecture Owners.
- Domain complexity. Similarly, team size and domain complexity tend to go hand-in-hand. Greater domain complexity will require the Product Owners to work in a more sophisticated manner and may even motivate them to get support from agile Business Analysts (or junior Product Owners as the case may be).
In some ways “program coordination” is a more accurate term than “program management.” Unfortunately “program management” is a far more common term within the IT community so we have decided to stick with it.
Our next blog posting in this series will describe the workflow of program management with other key IT activities such as portfolio management, enterprise architecture, and IT delivery teams.
An IT program is a large IT delivery team composed of two or more sub-teams. The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goal of producing a consumable solution for their stakeholders. In this blog posting we explore the team structure of a typical large agile program and the type of activities that program management addresses.
Team Structure of a Large Program
We described in detail the team structure of a large agile program in Large Agile Teams. The key ideas are that a large team is organized as a team of teams and that structures are required to coordinate people, requirement, and technical concerns within the overall program. Where a “scrum of scrums” may suffice for this coordination on small-to-medium sized programs (say up to five or six sub-teams), it quickly falls apart for larger programs. As a result large programs will find that they need: a Product Management (or Product Ownership) strategy where the Product Owners coordinate their activities; an Architecture (or Architecture Ownership) strategy where the Architecture Owners coordinate their activities; and a Product Delivery (or Management) strategy where the Team Leads coordinate their activities. The Program Manager, a specialist role, is responsible for coordinating the overall leadership team.
The following structure shows how the Product Owners of each sub-team are also members of the Product Management team for the program. Similar structures, see Large Agile Teams, will also exist for Product Delivery and Architecture as well.
What Program Management Addresses
There are several important concerns that program management needs to address:
- Architecture. The sub-teams must have a common architectural strategy that they are working to. The initial architectural strategy will be identified early and will evolve throughout the lifecycle, requiring the architecture owners on each team to coordinate their efforts. Although there are several ways to do this, a common strategy is for all of the AOs to hold a weekly architecture meeting to work through program-level technical issues. Subsets of the AOs will also hold impromptu meetings during the week to deal with immediate technical issues as needed.
- Work item management. The sub-teams work together to develop a consumable solution for their stakeholders. The implication is that they need mechanisms in place to allot the work between the sub-teams, including development of requirements, change requests, and fixing of defects. The product owners on each team will need to coordinate their efforts throughout the lifecycle. Common strategies to do this include the POs holding joint look-ahead modelling sessions (called backlog grooming/refinement sessions in Scrum) with key stakeholders; work coordination sessions where they identify dependencies between requirements and match the work to the sub-teams; and impromptu sessions between a subset of the POs throughout an iteration to work through dependencies between work being performed by different sub-teams.
- Management coordination between sub-teams. The sub-teams will need to coordinate “management issues” with one another on a regular basis. These management issues may include conflict resolution between people on different teams, enabling people to move between teams, financial tracking across teams, and many other concerns. As a result the teams leads, and any appropriate team members involved with a given issue, will need to meet regularly to address any issues. A common mechanism for this is for the team leads to hold their own daily coordination meeting after their team’s coordination meeting, a strategy that is often referred to as a “scrum of scrums”.
- Sub-team cadences. The Disciplined Agile framework, unlike other agile scaling strategies, does not insist that sub-teams follow the same iteration cadence (or even that sub-teams follow an iteration-based lifecycle). For example, one sub-team may have a one-week iteration length, five sub teams have a two-week iteration length, and two sub-teams follow DAD’s continuous delivery lifecycle which doesn’t have iterations at all. Or you may find a program where every sub-team has two-week iterations. Or a strategy where all teams take a continuous delivery approach. Each of these strategies make sense in certain situations, but none of them make sense in all situations. There is no single “best practice“.
- Release cadence. There are two fundamental issues here. First, how often will the overall program release into production? Will it release monthly? Quarterly? Bi-annually? Something else? Second, how often will the sub-teams release their work internally to other sub-teams so that it may all be integrated and tested as a whole? At the end of each iteration? At the end of each day? Several times a day?
- Governance. The program will be governed. This governance is both inward facing, the program should govern itself, and be outward facing, the program is part of your organization’s portfolio and therefore will be governed as part of your organizations overall IT governance strategy.
Relationship with Other Process Blades
There is clearly overlap with some of the activities in the portfolio management, enterprise architecture, release management, product management, and IT governance process blades. The issue is one of scope. Where these process blades address activities across all of IT, 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.
In future blog postings we will explore how to take a goal-driven approach to program management and what the program management workflow looks like.
Large solution delivery teams, let’s say fifty or more people, are often referred to as programs (programmes in UK English). Such teams are often organized into teams of teams, as depicted in the diagram below. Each of the sub teams will work on their part of the overall solution and to do so effectively there needs to be coordination between the sub teams. On large agile teams this coordination often proves to be complex, which is why a leadership team is introduced. This leadership team coordinates:
- Requirements. Requirements are managed by the Product Management (also called a Product Owner) team. This team is made up of the Product Owners from each sub team. They will meet as needed, typically several times a week. This group is the focus of this blog posting.
- Technical concerns. The Architecture (or Architecture Owner) team, comprised of the Architecture Owners from each sub team, is responsible for identifying and then governing the architectural strategy for the program. Activities of this group include negotiating changes to the architecture vision over time, resolving disputes about technical issues between sub teams, and sharing technical learnings across sub teams. It is common for this team to meet weekly with ad-hoc discussions occurring on an as-needed basis.
- Management concerns. Management concerns, such as members of different teams not getting along, transfers of people between teams, and schedule dependencies will be coordinated by the Team Leads from the sub teams. This team is often called the Product Delivery team or simply the Management team (yuck). As with the Product Management and Architecture teams this team will meet regularly as appropriate.
- Itself. This is the responsibility of the Program Manager. This person may be a Team Lead on one of the sub teams, although more often than not fulfilling this role proves to be a full time job. The Program Manager will guide the overall program team, ensuring that the three leadership sub teams are working together effectively and that they are meeting to coordinate their own activities as appropriate (and typically on different schedules).
Product Management/Ownership Team Organization
The Product Owner in each sub team is a member of the Product Owner team for the program, as depicted in the following diagram. Individual Product Owners will typically spend 80-90% of their time on activities that are directly related to supporting their sub teams and the rest of the time to requirements management activities at the program level. The Product Owner team is lead by a Chief Product Owner (CPO). The CPO may be a PO on a delivery team, this is common on small programs, although for larger programs the responsibility of leading the Product Owner team will prove to be full time work. In organizations with a strong Product Management culture, the Chief Product Owner may be a senior Product Manager.
This team is responsible for requirements management activities within the program. This includes:
- Identifying the initial scope of the program. The PO team will perform just enough initial requirements modelling, with active stakeholder participation where possible, to identify the initial scope of the program. This scope is very likely to evolve over time, but for now the goal is to explore the scope sufficiently to get the program headed in the right direction. See the process goal Explore Initial Scope for more details.
- Ongoing requirements elicitation. A primary job responsibility of anyone in the Product Owner role is to elicit and explore stakeholder requirements. In the case of a program the entire PO team must coordinate their requirements elicitation efforts.
- Assigning requirements to sub teams. As new requirements are identified the PO team will collaborate to identify the appropriate sub team to perform the work and then assign the work to that team.
- Managing requirements dependencies. There are always dependencies between requirements, and these dependencies should be managed by the appropriate Product Owners. For example, if a requirement (R1) assigned to sub team A depends on a requirement (R2) assigned to sub team B then ideally R2 should be implemented either before or at the same time as R1. Otherwise the people implementing R1 will need to mock/stub out the missing functionality until it becomes available. Read Managing Requirements Dependencies Between Agile Teams for more details.
- Developing a product roadmap. The PO team is responsible for developing a product roadmap for the program which lays out a high-level business direction for the product. This roadmap should reflect your organization’s overall business roadmap, if you have one.
The Product Owner team will meet as often as they need to. We’ve seen some PO teams meet on a daily basis for 30 minutes each to manage requirements between sub teams. We’ve also seen PO teams that meet weekly for two hours to do this work. The important thing is that they self organize to determine what works best for them.
The Product Owner team may include business analysts (an example of a specialist role in DAD) who supports the POs in working with stakeholders to understand their requirements. This is particularly important whenever the team is addressing significant domain complexity or whenever stakeholders are geographically dispersed.
In medium-sized enterprises this Product Owner team approach may be applied to your entire IT department. In this case the focus of the PO team is that of your entire portfolio of ongoing IT solution delivery efforts and not just a single program of interdependent teams.
In large enterprises the Product Owner team for a program may be part of a larger Product Management team for the entire organization. More on this in a future blog posting.