Category Archives: Program Management

Rolling Wave Planning in Disciplined Agile


The basic idea with rolling wave planning is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.

Rolling wave planning is implemented in several places of the DA framework. First, as you can see in Figure 1 below, it is an option of the Level of Detail decision point of the Develop Initial Release Plan process goal. A rolling wave approach to release planning has the advantages of more accurate and flexible planning although can be a bit disconcerting to traditional managers who are used to annual planning strategies.

Figure 1. The Develop Initial Release Plan goal diagram.

Develop Initial Release Plan


The Portfolio Management process blade supports rolling wave budgeting as an option for its Manage the Budget decision point. This is depicted in Figure 2. The advantages are greater flexibility and greater likelihood of investing your IT funding more effectively, albeit at the loss of the false predictability provided by an annual budgeting strategy.

Figure 2. The goal diagram for the Portfolio Management process blade.

Disciplined Agile Portfolio Management


The Program Management process blade supports rolling wave planning of a program itself, as you seen in Figure 3. Planning and coordination are critical on a large program, and rolling wave planning offers the advantages greater flexibility, the ability to think important cross-team issues through, and the ability to react to changing stakeholder needs. The primary disadvantage is that it can be disconcerting for traditionalists who are used to thinking every thing through from the beginning.

Figure 3. The goal diagram for the Program Management process blade.

Disciplined Agile Program Management


As you can see in Figure 4, rolling wave strategies can be applied in Product Management to evolve the business vision/roadmap. A continuous, rolling wave approach is critical to your success because the market place changes so quickly – these days, few organizations can tolerate an annual approach to business planning and in the case of companies with external customers an ad-hoc approach can prove to be too unpredictable for them.

Figure 4. The goal diagram for the Product Management process blade.

Disciplined Agile Product Management


Previously we saw that rolling wave strategies can be applied to evolve your technology roadmap, as indicated in the goal diagram for Enterprise Architecture in Figure 5. The advantages of this approach are that your roadmap evolved in sync with both changes in technology and with your organization’s rate of experimentation and learning. The main disadvantage is that your technology roadmap is effectively a moving target.

Figure 5. The goal diagram for the Enterprise Architecture process blade.

Disciplined Agile Enterprise Architecture

As you can see, rolling wave strategies are an integral part of the Disciplined Agile (DA) framework. In fact, in most situations they prove to be the most effective and flexible strategies available to you. The advantages of rolling wave planning tend to greatly outweigh the disadvantages. More on this next time.

Introduction to Rolling Wave Planning

Rolling wave

For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) framework, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few.  This blog overviews this important practice.

The basic idea is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.

In Figure 1 below you see an overview of how rolling wave planning works and in Figure 2 an example of how a Disciplined Agile Delivery (DAD) team applies it for release planning. Upcoming work is planned in detail, the planning unit “X” is one month in the case of the delivery team. In order to do their work they need detailed user stories and supporting artifacts such as acceptance criteria and supporting models such as user interface (UI) sketches or data source analysis. They have this information for the work that they are doing right now as well as about one month’s of upcoming work. They don’t yet need details for work that is several months away in time. In this case for work that is two to three months in the future they only have user stories developed and work that is four to six months away epics. Work in what the team considers to be the distant future, in this case six or more months away, is described in very high-level terms such as epics or solution capabilities.

Figure 1. Rolling wave planning overview.

Rolling wave planning overview

Figure 2. Rolling wave release planning on a solution delivery team.

Rolling wave release planning overview

Part of the work that the team is doing right now is to keep their plan up to date. For example, if they are working in two week iterations they will pull two weeks of work into the team. During the current iteration they will pull about two weeks of user stories from the near term category (the yellow box in Figure 2) into the very near term (the green box). They may also bring upcoming work into the near term category at this point too.

Rolling wave planning has its source in iterative software development such as the Rational Unified Process (RUP). It is a strategy that is commonly applied by agile software teams and the Project Management Institute (PMI)’s Project Management Book of Knowledge (PMBoK) supports it.

In future blog postings in this series we will work through examples of applying rolling wave planning in practice.

(In Agile) Where do all the managers go?

Business team

On February 23, 2016 I gave a webinar entitled (In Agile) Where do all the Managers go? A recording of the webinar is posted on Youtube and a PDF of the slides on Slideshare. This blog overviews the webinar and provides answers to the numerous questions that were asked during it.

Webinar Overview

The webinar began with a discussion of four trends that are reducing the need for people in management positions:

  1. Technical management tasks are performed by the team. As a result there is much less work for managers to do.
  2. Leadership is addressed by new roles. Team leadership responsibilities are in the hands of non-managers.
  3. Experienced organizations are moving towards stable teams. Important side effects of this are that much less “resource management” is required and team budgeting is greatly simplified.
  4. Status reporting is being automated away. Once again, less work for managers to do.

We then discussed the options that existing managers have in an agile environment. In Disciplined Agile there are four roles that existing managers are likely to transition to: Team Lead, Product Owner, Team Member, and Specialist. Specialist roles – such as Data Manager, Portfolio Manager, Program Manager, and Operations Manager – occur at scale and the corresponding positions are few and far between. Read the article Disciplined Agile Roles at Scale for more details.

We end with words of advice for existing managers: Observe what is actually happening; be flexible; and choose to evolve.

Questions and Answers

We’ve organized the questions into the following topics:

Evolving to New Roles

Will not the existing technical managers be disappointed with only people management work?

That depends on the person. Some will be very happy to do this, some will not.

How will managers fit into a leader role?

It depends on the person again. Some managers are very good leaders right now, some have the potential to be good leaders, and some don’t. They will need training and coaching to fit into their new role(s).

Addressing “Management Activities”

If there are no PMs in Agile, who handles communication with clients (meeting deadlines, priorities, etc.)

The Product Owner. 

How does individual performance to be taken up in Agile team? I think that is more crucial and challenging for Agile Leader / Manager.

It is always difficult to address performance-related activities. There are many lines of thought on how to do this. The most progressive is for the Team Lead to provide feedback to team members on a just-in-time basis. If the Team Lead seems behaviour, either desirable or undesirable, but a team member then they should comment on it right away so as to reinforce or dissuade it as soon as possible. Many organizations still have an annual review process, a strategy that many organizations have abandoned due to it’s ineffectiveness, where functional managers get involved with the review process.

I have seen that you have selected the Team Lead as the responsible of assess team members and budgeting the project. In Scrum the Product Owner is compare to a CEO that’s the reason I would say the Product Owner is responsible for bugdeting and about assessing I prefer a more democratic form which involve all the members. So what do you think about PO managing the budget and a democratic assessing vs one single vision assess?

Yes, I misspoke during the webinar. The Product Owner is often responsible for the team’s budget and is responsible for reporting the current financial information to the stakeholders. The Team Lead is often responsible for similar reporting to their management team.

Having multiple people involved with reviews/feedback is usually a pretty good idea. The People Management process blade captures several potential strategies. However, it is still a good idea for the Team Lead to provide feedback as well, see my earlier answer.

Potential Management Roles

I think there is still a need a bridge manager role between Finance, Teams, and PMO type orgs to ensure Product owners have budget… views. Thoughts?

In smaller organizations this likely isn’t an issue. In larger organizations there is often a Portfolio Management effort that is responsible for such issues.

What might be potential responsibilities of an Operations Manager, Data Manager, …?

Please read the article Disciplined Agile Roles at Scale for descriptions of these roles.

Okay, the data management team needs a team manager/leader. Are large organizations using various resource managers? (Although would be less necessary with stable teams I would think)

Exactly. Large organizations still tend to have people in resource manager roles, although sometimes they have different titles such as CoE Lead or HR Manager, but with stable teams they need far fewer of them.

If the team has a Team Lead/Scrum Master that is only the servant leader for 1-2 teams, is it suitable to have people managers?

What value would a “people manager” bring to the team? This is the fundamental dilemma for managers, for everyone for that matter, when an organization moves to agile ways of working. If they’re not bringing real value to the team then they either need to find ways to do so, which likely isn’t whatever management activities they’re trying to cling to, or they need to go elsewhere and try to add value there.

Do you intend to update the DA 2.0 interative pic on the DAD site to talk about “Potential Management Roles at Scale” as mentioned in page 18 of this presentation?

Yes. We actually have something in beta that we haven’t released yet. We’re just about to release an update to the main picture, which in turn requires an update to the role version of the interactive pic.

What is the most basic difference between Project/Program/Portfolio Managers in Agile?

Quick answer is that there isn’t Project Managers in Disciplined Agile nor in methods such as Scrum, XP, and so on. At the program level (a large team of teams) you likely need someone in a Program Manager (or more accurately Program Coordinator) role to coordinate activities (see the Program Management process blade for details). A Portfolio Manager is focused on the IT level and should be concerned about pre-development activities, development/delivery teams that are currently in flight, as well as operational activities.

Also, please read the article Disciplined Agile Roles at Scale for descriptions of these roles.

People Management

How does one manage the career path of the Team Leads? Is there career progression beyond a TL to be a specialist or does s/he continue being a TL throughout his career?

Everyone is different, so there isn’t one exact answer. It depends on what the person wants to do and what positions are available to them. If their desire is to move into management then there are fewer IT management positions available to them. If they want to become an AO or PO then they need to work towards getting the skills and experience to fulfill those sorts of roles. The People Management process blade includes career management strategies.

How do you evaluate what roles are/will be necessary?

It depends on the needs of the team in the situation that they face. The primary delivery roles typically exist on all delivery teams and the secondary roles start to appear at scale.

How do you see the role of a BA in agile?

Most existing BAs, like most existing project managers, will need to transition to other roles. However, at scale there is a need for some people in the specialist BA role. I recently has a user group presentation recorded on this very topic. See Disciplined Agile Business Analysis: Lessons from the Trenches.

Management Reporting

How do we approach a situation where management wants weekly status reports from a Program Manager who can combine both Team Lead & Product Owner roles, as well as manage multiple projects that may be similar in nature or not.

A few thoughts on this:

  1. It’s an incredibly bad idea to combine the TL and PO roles because it puts too much responsibility in the hands of one person. Furthermore, putting it into the hands of a former manager, someone who may have a command-and-control mindset instead of the collaborative mindset required of agile, can exacerbate the problem.
  2. You may need someone that Team Leads should work with to coordinate activities between teams (such as a Program Manager or Portfolio Manager) and someone that Product Owners should work with (a Chief Product Owner) to coordinate requirements activities. See The Product Owner Team.
  3. I do see stuff like this happen when organizations are transitioning to agile. They are still learning how to make agile work within their environment, they have a lot of people who haven’t yet made the transition, and they have a lot of middle management staff whom they want to treat fairly by finding them other work. Sadly that other work is often overhead that can be done away with given a bit of thinking.
  4. If you institute automated dashboards, what we originally referred to as Development Intelligence in Disciplined Agile, then a lot of your status reporting goes away.


In a typical organization, where to team lead(s) report into?

It depends. We’ve seen them report into a Program Manager or a Portfolio Manager. During the transition effort a Project Management Office (PMO) may still exist so Team Leads might report into there, although we often find that there’s a serious cultural and mindset difference that can be very frustrating for everyone involved.

During Your Agile Transformation

What about managers being responsible to support an agile transformation journey in a large organization?

Yes, they would very likely be working as part of an Agile Center of Excellence (CoE), although that would be mostly staffed by experienced agile coaches. There is a need for one or more senior execs to sponsor your agile transformation.

How to deal with “Project Manager” role renamed as “Agile Project Manager” but expected to do the same responsibilities as traditional PM?

We see this sort of stuff all the time unfortunately. First thing to do is to get these people educated in how agile actually works in practice, we’d suggest DA 101: The Disciplined Agile Experience or DA 104: Introduction to Disciplined Agile as your best option to get the whole picture. Next, work through with them how they would actually add real value on the team (see the discussions earlier). Very likely many of the activities that they think need to be are being handled by someone else or have been automated away. Third, get them some coaching to help them to truly transition to agile.

On my project, I am the Team Lead and there is a Project Manager. So far, I have observed that there are several conflicts in responsibilities. How do we come to an agreement of who handles which responsibilities? For my next project, would you suggest I work on a project with no project manager?

We often have to run facilitated workshops in organizations where we work through the roles and responsibilities that are needed in practice. We do this with a wide range of people and we do so in a collaborative and public manner. You need to come to an agreement as to who does what. Doesn’t sound like that’s happened in your case. When you work through this sort of an exercise you quickly discover that you don’t need a project manager, although there may be some project control officer (PCO) responsibilities that would be assigned to either the team lead or some sort of administrative role (such as PCO).

Do you have any advice on how to deal with the removal of the traditional hierarchy – in a flattening of responsibilities, ‘reporting-lines’ and salaries (or having a vast range of skills and pay-scales all with a job title of ‘team member’?)

This is what an agile transformation will accomplish for your organization. It takes time and investment in your people to implement. I highly suggest that you get some experienced coaches to help you do this.

Management is severely, negatively, personally affected by Agile, and will not look fondly upon it in many cases. Any tips to reduce this? Do you recommend mass management reduction, or multiple smaller rounds?

The first step is to recognize that your organization doesn’t exist to create jobs for managers, regardless of what the managers may think. Agile is about focusing on value, so why wouldn’t a good manager be interested in being actively involved with doing so? My recommendation is always to get training and coaching for everyone, including managers. As I described in the webinar there are many options for existing managers in the agile world if they’re willing to be flexible and evolve. Your organization should choose to help people make these transitions to new roles. However, if people are not willing to make the transition then they shouldn’t be surprised if the find themselves being asked to seek employment elsewhere.

It sounds like the person asking about “who’s responsible for delivery” might have used “responsible” when they meant “accountable” – many managers are the single wringable neck for something in their job description. Do you feel Agile draws the same distinction between the two like ITSM, for instance, does?

Agile is based on a collaborative, teamwork-based mindset. Having said that, it does make sense to have someone ultimately responsible for certain things. For example, the Product Owner is responsible for prioritizing the work on an agile team. Similarly, you may have someone in the Release Manager role who is responsible for overall Release Management within your organization. This is particularly important for regulatory environments where by law you need to have someone not involved with development who makes the final decision as to whether the solution is released or not.

From your observations and experience, what is the average timeframe for the managers number to decrease? How long does the process of the shift take?

It depends. We’ve seen this happen over timeframes as short as six months to several years.  With solid coaching this process will go a lot faster and smoother.

How to motivate and enable senior leaders to give up control?

In agile, particularly in Disciplined Agile, senior leaders have greater visibility and opportunities to steer than what they had in the traditional world. What they need to do is give up their false sense of control that traditional strategies provide. The real issue usually isn’t senior leaders but instead is middle management. They are the people who are currently performing many of the management tasks that are implemented in a more streamlined manner following agile approaches.

How can middle management start the agility journey when top leaders are not yet on board?

Agile typically begins following a stealth adoption strategy where senior leaders are unaware that it’s happening. The point is that anyone, including middle management, can start adopting agile strategies long before senior leadership gets involved. Strategies such as working collaboratively, enabling your team(s) to plan and organize their own work, adopting dashboard technology, and streamlining the bureaucracy whenever possible is very possible to accomplish on your own.

Thanks for being frank about the role(s) for managers in an evolving Agile culture: Agree, traditional project management organization’s aren’t highlighting these trends (and positive outcomes.)

You’re welcome. Traditional project management organizations often go at it from the point of view of how to continue justifying management activities. We go at it from the point of view of how to improve your overall organizational effectiveness and as a result come to a different conclusion.

Stable Teams

Will the idea for stable team become stale after some years? People tend to get frustrated doing same work. What’s the solution in that case?

Stable teams evolve over time. You’ll get people joining the team every so often and similarly leaving the team every so often. It’s natural for people to want to move on and try something new every few years. As a result your organization will still need People Management activities in place that motivate and enable people to manage their careers.

As far as stable teams go, commonly Valve, Inc. is referred to a place where teams are formed around projects that the team members find the most interesting. Project leaders try to sell their project to get developers. Your thoughts?

This is great technique that other organizations may be able to adopt. Allowing teams to form themselves is likely the most effective way to do so. However, like all strategies, there are some potential disadvantages. Team culture may become ingrained and they will not attract people with a different culture who would have the potential to add some real value to the team otherwise.

Is there a method to build the stable teams? Domain, Product, line of business?

There are several strategies for doing this. The most common is to form feature teams that do all of the work to implement a feature as a vertical slice through your entire infrastructure. Another approach is to form component teams that work on a technical or domain component/framework/LoB. A third approach is internal open source. We’ve discussed these strategies in greater detail at Strategies for Organizing Large Agile Teams.

Do you think stable teams concept will work in service-based organisation?

Yes. It’s a bit more difficult because you’d be bringing entire customer projects to the team at once instead of a flow of smaller features. Of course you can break each large project up into smaller features and feed them to teams in an interleaved manner, requiring a sophisticated approach to requirements management.

Training and Certification

What baseline training do you recommend for agile managers?

A good place to start is training on agile thinking, often referred to as how to be agile. Then I would recommend training that describes the full delivery lifecycle from end-to-end, something like DA 101: The Disciplined Agile Experience or DA 104: Introduction to Disciplined Agile. You want to understand all aspects of the agile delivery process, not just the management ones. Scrum training is popular but far too narrow. SAFe training isn’t for beginners.

I would like to participate in a certification workshop/further training. There doesn’t seem to be many offerings in the US. Are there plans to expand training opportunities in the states?

Yes. In fact we have training coming up in the Baltimore area in March and Philadelphia in April. We will have more open enrollment workshops scheduled soon.  Please visit the homepage of the Disciplined Agile Consortium for a listing of upcoming public workshops.

What should we be telling folks that have PMP’s – are they still valid? is PMP training moving toward Agile software development.

Yes, the PMI is moving towards agile but they have a very large ship to turn. Unfortunately the PMI training tends to suffer from the challenges that I described earlier – it seems to promote a rather unrealistic vision of how managers can potentially fit into agile.

The practical realities of software estimation

In IT we are often asked to estimate the expected time/schedule or cost of software development. Sadly, the desire of stakeholders to have “predictable” schedules or costs results in significant dysfunction within a software development team.  When a software team is  forced by their stakeholders to commit to a schedule/cost they must then ensure that the schedule/cost doesn’t slip. For example, to protect themselves from increased time and cost due to scope creep, software development teams will make it difficult for stakeholders to change their requirements during Construction and even go so far as to drop promised scope late in a project. The desire of stakeholders to reduce their financial risk often results in behaviors by the software development team that ensure that stakeholders don’t get what they actually want.  Naturally IT gets blamed for this.

Practical Realities of Software Guesstimation

We need to do better.  In this blog we summarize the things that we know to be true about software development estimation. In no particular order, they are:

  1. Estimates are guesses. Look up the word in the dictionary – An estimate is a rough approximation or calculation, in other words a guess. Unfortunately, too many people think that estimates are promises, or worse yet guarantees.  In our opinion “guesstimate” is a far more appropriate word that “estimate”.
  2. Scope on IT projects is a moving target. Our stakeholders struggle to tell us what they want and even when they do they change their minds anyway.  Any guesstimate based on varying scope must also vary in kind.
  3. Guesstimates are probability distributions. Although your stakeholders may ask for a fixed amount guesstimate, for example “this will cost $1 million”, the reality is that there’s a chance the cost will be less than $1 million and a very good chance that it will be more.  There is ample evidence that the initial estimate for a software development project should be given in a range of -25% to +75%, so your million dollar project should be quoted as a range of $750,000 and $1,750,000.  This is shown in the diagram above by the green distribution curve.  In many organizations this can be politically difficult to do, and strangely enough in many cases stakeholders prefer to be lied to (it’s going to be $1,000,000) rather than be told the truth.
  4. Guesstimates must reflect the quality of the inputs.  A guesstimate needs to reflect the quality of the information going into it – if your scope is fuzzy your guesstimate based on that scope needs to be equally fuzzy.  Sometimes stakeholders want a guesstimate with a tight range, perhaps +/- 10% (the red curve in the diagram), early in a project.  To provide a tight range such as this you need to have a very good understanding of the requirements and the design.  Early in the software development process this can only be done through more detailed modeling, an expensive and risky proposition which often proves to be a wasted effort because the requirements will evolve over time anyway.
  5. Guesstimates anchor perception. The primary danger of providing guesstimates to people is that they believe them.  Tell someone that it’s going to be $1,000,000 and they fixate on that cost even while they are changing their minds.  Tell them that it’s going to be between $750,000 and $1,750,000 and most people will fixate on the cost of $750,000.  Some people will focus on the average cost of $1,250,000 even though the median was $1,000,000 (guesstimates are in effect Weibull probability distributions).
  6. It’s easier to guesstimate small things. ‘Nuff said.
  7. It’s easier to guesstimate work you’re just about to do instead of work in the distant future. It is much easier to identify the details of work to be done right now, and thus turn a large piece of work into a collection of smaller pieces that are easier to guesstimate.  In part this is because you have a much better understanding of the current situation you are working in and in part because you are more focused on the here and now.
  8. The people doing the work will likely give a better guesstimate.   They are more motivated to get the guesstimate right, particularly when they must commit to it, and have a much better idea of their abilities.  Granted, someone may need to coach people through the guesstimation effort.  In Disciplined Agile this is a responsibility of the team lead.
  9. Someone who has done the work before will give a better guesstimate than someone who hasn’t. Experience counts.
  10. Guesstimates reflect the situation that you face.  Which organizational situation do you think will result in a short schedule and lower cost: Five people co-located in a single room or the same five people working from different locations in difficult time zones?  Or how about a team working under regulatory constraints versus the same team without those constraints?  Context counts.
  11. Multiple guesstimates are better than a single guesstimate. Getting guesstimates from several people provides insights from several points of view, hopefully prompting an intelligent conversation that enables you to develop a guesstimate with better confidence.  Similarly, the same person producing guesstimates for the same piece of work using different guesstimation strategies will also provide a range of answers that you can combine.
  12. Guesstimates should be updated over time. As your understanding of what stakeholders want improves, and your understanding of how well your team works together, you should update your guesstimates.  As your understanding of the fundamental inputs into your estimate improves you are able to produce a better estimate, thus enabling the stakeholders of that guesstimate to make better decisions.
  13. It costs money to produce a guesstimate. The precision of an estimate is driven by the detail and stability of the information going into it. Want a tighter range on your estimate?  Then you’re going to have to have a better handle on the requirements, design, and capabilities of the team doing the work.  This greater precision requires greater cost.  The fundamental question posed by the #NoEstimates community is effectively “Is the value of improved decision making capability from having the guesstimate greater than the cost of creating the guesstimate?” The implication is that you must ensure the cost is much less than the benefit, hence their focus on finding ways to streamline and even eliminate the guesstimation effort.
  14. Guesstimation is far more art than science. See point #1 about estimates being guesses.  The best guesstimates are done by the people doing the work, just before they need to do the work, for small pieces of work.
  15. Formal software guesstimation schemes are little more than a scientific façade. Function point counting, feature point counting, and COCOMO II are all examples of formal strategies.  They boil down to generating numeric guesses from your detailed requirements and design, plugging these guesses into an algorithm which then produces a guesstimate. These are all expensive strategies (they require detailed requirements and design work to be performed) that prove to be risky (because they often force you into a waterfall approach) in practice.  Yes, they do in fact work to some extent, but in practice there are much less expensive and less risky strategies to choose from.  People like these type of guesstimation strategies because they provide a false sense of security due to their complexity and cost.
  16. Past history isn’t as valuable as people hope.  Some formal guesstimation strategies are based on past history, but this proves to be a false foundation from which to build upon for several reasons.  First, people have different levels of capability which change over time as they learn. Capers Jones has shown that developers have productivity ranges of 1 to 25, the implication being that if you don’t know exactly who is on a team and how well they work together your corporate history will be questionable.   Second, technologies evolve quickly so past history from working with older versions of technologies or completely different technologies becomes questionable at best.  Third, people and teams change (hopefully for the better) over time, implying that an input into your guesstimate is fuzzy at best.  Fourth, because every team is unique and faces a unique situation basing estimates on past history from other teams in different situations proves questionable.
  17. Beware professional guesstimators. They tend to break many of the rules we’ve described above.

To summarize, when you are required to provide estimates for your software development efforts that you should take a pragmatic, light-weight approach to doing so.  This blog posting has provided many practical insights that should help guide your decisions.  These insights and many more, are built right into the Disciplined Agile framework.

Disciplined Agile Program Management: Internal Workflow

In this blog posting, the latest in our ongoing disciplined agile program management series, overviews the workflow internal to program management.

Workflow Within a Program

The workflow within a disciplined agile program is depicted in the following diagram.

Disciplined Agile Program Management - Internal workflow

As you can see in the workflow diagram, someone in the role of Program Manager coordinates the three leadership teams (described in greater detail in Large Agile Teams):

  1. Product Delivery Team.  This team is responsible for dealing with cross-team “management issues” such as moving people between teams, resolving disputes that cross team boundaries, and any coordination issue that doesn’t fall under the purview of the other two leadership teams.  The Program Manager often leads the Product Delivery team, which is made up of the Team Leads from the delivery sub-teams, and may even be a Team Lead of one of the delivery teams as well.
  2. Product Owner Team.  This team is responsible for requirements management, prioritizing the work, and assigning work items to the various sub-teams. This team is led by a Chief Product Owner (CPO), not shown, who is often a Product Owner for one more more sub-teams.
  3. Architecture Owner Team. The AO team is responsible for facilitating the overall architectural direction of the program, for evolving that vision over time, and for negotiating technical dependencies within the architecture.  This team is led by a Chief Architecture Owner (CAO), also not shown, who is often an Architecture Owner on one or more delivery sub-teams.

An important difference between the Disciplined Agile approach and SAFe is that the delivery sub-teams may be following different lifecycles.  The Disciplined Agile Delivery (DAD) framework supports several delivery lifecycles, including the Scrum-based agile/basic lifecycle, the Kanban-based lean lifecycle, a continuous delivery lifecycle, and the Lean Startup-based exploratory lifecycle.  Even when the sub teams are following the same lifecycle they may be working to different cadences (or not) – in the Program Management goal diagram we explicitly show that there are several strategies for sub team cadences.

The workflow diagram also shows that some programs may include a parallel independent testing effort in addition to the whole team testing efforts of the sub-teams.  The delivery sub-teams will make their working builds available to the testers on a regular basis, who will integrate all of the builds into their testing environment.  This independent testing effort often addresses end-to-end system integration testing as well as other forms of testing that make better economic sense when done in a centralized manner.  Independent testing is common for large programs that are tackling complex domains or complex technologies or that find themselves in a regulatory environment that requires independent testing.  The SAFe equivalent to a parallel independent test team would be called a system team, in this case one doing system integration plus independent testing.  Same basic concept, slightly different wording.


Related Postings

Why Do We Need Agile Programs?


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 examine some of the reasons why large IT delivery teams are formed and strategies to reduce or even eliminate the need for such teams.

There are several reasons why large IT delivery teams exist in the first place:

  1. Some endeavours are inherently big. Sometimes an organization will decide to take on a complex effort, such as developing an operating system, an air traffic control system, a financial transaction process system at a bank, and many other examples.
  2. Overly-specialized staff promote larger teams.  When IT staff are narrowly focused it requires many people to work, at least part time, on a team so that the team has sufficient skills to get the job done.  When people are generalizing specialists your teams become much smaller and collaborative.
  3. Overly bureaucratic processes promote larger teams.  Sometimes the systemic bureacracy in the organization requires large numbers of people to address that bureaucracy.  I once assessed a eighty-person project team who were doing work that only required between ten and fifteen people to do the “real work” and everyone else to conform to the overhead of their traditional CMMI-compliant process.  Sadly they didn’t rework the team and failed to produce anything after three years and many millions of dollars of investment.  As an aside, it is possible to effectively combine CMMI and disciplined agile approaches, but you need to overcome the cultural dissonance of the two paradigms.
  4. Working on large teams can lead to greater rewards.  Similarly, someone is “empire building” and purposefully creates a large team so that they will be rewarded for doing so.  We have worked in two organizations where before their agile transformation the pay grade of a manager was determined by the number of people the person managed.  Worse yet, in one organization the people on the larger teams tended to get better bonuses, and quicker promotions, than people on smaller teams regardless of the actual ability of the team to deliver value to the organization.

In our opinion only the first reason is a valid one for building a large agile team.  The other reasons reflect aspects of organizational cultures that need to be fixed in time.  Luckily, there are several strategies that you can employ to reduce the size of a team:

  1. Reorganize the problem into a collection of smaller problems.  Disaggregation of a large problem is performed through a combination of agile envisioning and agile business analysis. This is a key responsibility of your product management efforts: to feed reasonably-sized portions of work to IT delivery teams.
  2. Reduce the problem.  Sometimes a large problem can be shrunk down through pruning features out of the vision, or at least by deferring them until later.
  3. Address your organization’s culture. As we discussed earlier, most of the reasons that organizations build large IT delivery teams are the result of cultural challenges.  Fix the real problem by adopting agile and lean ways of thinking and working.
  4. Organize the large team into a collection of smaller teams.  In other words, create a program.

When you find yourself in a situation where you need a large IT delivery team, and those situations do exist in many organizations, and you can’t find a way to reduce the size of the team, then you will need to adopt strategies to coordinate that team.  The disciplined agile project management blade describes such strategies.

Related Postings



Disciplined Agile Program Management: External Workflow

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.

Disciplined Agile Program Management

The following table summarizes the workflows depicted in the diagram.

Process Blade Process Blade Overview Workflow with Program Management
Continuous Improvement 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.
Data Management 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.
Enterprise architecture 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.
IT Delivery 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.
IT Governance 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.
Operations 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.
Portfolio Management 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.
Product Management 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.
Release Management 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.
Reuse Engineering 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.
Support 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.

Related Postings

Disciplined Agile Program Management: A Goal Driven Approach

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.

Disciplined Agile Program Management

The process factors that you need to consider for program management are:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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).
  9. 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.
  10. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).

Concluding Thoughts

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.


Related Postings

Disciplined Agile Program Management 101

Team of 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.

Large Agile Team Organization

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.

Agile Product Management Team


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.


Related Postings




Disciplined Agile Program Management – The Product Owner Team

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).

Large Agile Team Organization

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.

Product Owner Team

This team is responsible for requirements management activities within the program.  This includes:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Tailoring Considerations

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.