Disciplined Agile

The value streams layer encompasses the capabilities required to provide value streams to your customers.  A value stream begins, ends, and hopefully continues with a customer. A value stream is the set of actions that take place to add value for customers from the initial request through realization of value by the customers.  The value streams layer is one of the four layers of the Disciplined Agile (DA) tool kit, overviewed in Figure 1.  These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE).  This blog focuses on the value streams layer.

Figure 1. The layers of the DA tool kit.

Figure 2 depicts the DA FLEX lifecycle, overviewing the high-level workflow for a value stream.  As you can see, a value stream begins with the initial concept, moves through various stages for one or more development teams, and on through final delivery into business operations.

Figure 2. The DA FLEX lifecycle for value streams.

Let's explore the components of Disciplined Agile's value stream layer.  The hexes in Figure 2 and Figure 3 represent process blades, sometimes called process areas. A process blade encompasses a cohesive collection of process options, such as practices and strategies, that should be chosen and then applied in a context sensitive manner.  Process blades also describe functional roles specific to that domain as well as extensions to the DA mindset specific to that domain. 

Figure 3. The process blades of Disciplined Agile's value stream layer.

You can see in Figure 3 that some process blades, such as Product Management and Program Management, are specific to this layer.  Other process blades, such as Strategy and Marketing, are shared between the value streams layer and the disciplined agile enterprise (DAE) layer. This is an indication that you may choose to implement those process blades at both the enterprise level as well as the level of a single value stream - do what is right for your situation.

Expanding upon the Disciplined DevOps layer, the value stream layer adds the following blades:

• Business operations
• Continuous improvement
• Governance
• Marketing
• Portfolio management
• Product management
• Program management
• Research & development
• Sales
• Strategy

Business operations

Business operations focuses on the activities required to provide services to customers and to support your products. The implementation of business operations will vary by value stream, in a bank retail account services is implemented in a very different manner than brokerage services for example. Business operations includes help desk and support services (integrated in with IT support where appropriate) as well as any technical sales support activities such as training, product installation, and product customization. As you can imagine close collaboration with both your Sales and Marketing efforts is required to successfully Delight Customers.

Continuous improvement

The continuous improvement process blade describes how people within your organization can share their improvement learnings with one another in a systematic way.  There are many strategies for doing so, including centers of excellence (CoEs), communities of practice (CoPs) which are also known as guilds, techniques for exploring existing ways of working (WoW), identifying new WoW, and sharing techniques.

Governance

Governance is the leadership, organizational structures, and strategies to enable you to sustain and extend your organization’s ability to produce meaningful value for your customers. Lean governance promotes strategies such as motivating people to do the right thing, enabling them to do so (often via automation), communicating organizational objectives, and preferring visibility over reporting.

Marketing

The goal of marketing is to ensure successful interactions between your organization and the outside world. Disciplined Agile marketing applies data and analytics to continuously source promising opportunities or solutions to problems in real time, deploying tests quickly, evaluating the results, and rapidly iterating. It also means taking a validated learning approach, being customer focused, working in a collaborative and flexible manner, and working in an evolutionary (iterative and incremental) manner. Your marketing efforts will represent your organization and your offerings, both products and services, to the outside world and conversely will represent external stakeholders, and potential stakeholders, to the rest of the organization. In conjunction with product management, Marketing will be actively involved with long-term visioning for your organization’s offerings. Marketing is sometimes called brand management

Portfolio management

Portfolio management addresses how an your organization goes about identifying, prioritizing, organizing, and governing their various endeavors. Disciplined Agile portfolio management seeks to do this in a lightweight and streamlined manner that maximizes the creation of business value in a long-term sustainable manner. Potential endeavors include solution delivery initiatives/projects, stable product development teams, business experiments (along the lines of a lean startup strategy), and the operation of existing solutions.

Product management

Product management is the art of taking strategic objectives and turning them into tactical activities.  Disciplined agile product management is performed in a collaborative and evolutionary manner that reflects the context of your organization. Disciplined agile product management includes the acts of:

• Identifying and prioritizing potential products/solutions to support your organization's vision;
• Identifying, prioritizing, and allocating features to products under development;
• Managing functional dependencies between products;
• Marketing those products to their potential customers;
• Exploring the needs of existing and potential customers;
• Identifying minimum business increments (MBIs) for delivery teams to work on.

Program management

A program is a large team composed of two or more sub-teams (also called squads). The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goals of the overall endeavor. Program management encompasses financial activities, vendor management, coordination of people/staffiing concerns, coordination of the evolution of the solution, and coordination of requirements management issues across the sub-teams within the program.

Research & development

Research & development (R&D) encompasses the innovative activities undertaken by your organization to identify potential new offerings (services or products), or to identify potential improvements to existing offerings. R&D constitutes the first stage of development of a potential new offering.  R&D activities are an important part of both product management and solution development to help explore potential ideas and strategies.

Sales

The aim of your sales efforts is to, you guessed it, sell your organization’s offerings (both products and services) to customers. Your sales people, if any, will work very closely with your marketing team to ensure they are focused on selling offerings that reflect your organizations’ overall strategy. They will also work closely with product management to ensure that what they’re selling is available or can be built in a timely manner. Organizationally Sales is often combined with marketing or may even be matrixed into business operations.

Strategy

Strategy is what you do now, and what you intend to do in the future.  The focus of the strategy process blade is to identify, evolve, and then drive the execution of your organization’s vision. Your vision is driven by the perceived needs of your customers and influenced by the environment in which you operate.

By Jeev Chugh, CDAP | CDAI and Joshua Barnes CDAC | CDAI

Enterprise agile transformation roadmaps using Lean Change are often fueled by the desire to deliver value faster with increased flexibility.  They start with replacing traditional (waterfall) delivery methods with an Agile way of working, using pilot teams to validate early decisions on how to experiment with aspects such as team formation, lifecycle (agile, lean, continuous delivery, etc.) practices and techniques, and so on.  What team members and business and technology leaders alike quickly glean is that the mind shift to collective ownership of the work, decentralized decision making, and all the energy to shift to self-organizing teams is just the first step.  A big step, but one in a long journey.

To truly achieve the sizable outcomes from these enterprise transformations, many aspects beyond that of individual agile teams achieving a good level of maturity in “their” agile ways of working are needed.  One of the shifts that enables such outcomes is adopting a Product Portfolio operating model.  In this model, we transition from assembling a team to deliver a fixed scope via a project and then disband as the project ends to a long-lasting stable team delivering business outcomes via continual improvement of a product.

Along with this change comes the realization that traditional waterfall methods of budgeting and project cost accounting that requires upfront plans and budgets, is in inherent conflict with Agile ways of working; especially so when the agile approach uses a Lean Kanban-based lifecycle (very small batches) or Lean Continuous Delivery (no batches) lifecycle. Thus, to successfully scale Agile, enterprises must work with business and Finance partners to move beyond traditional project-centric funding models and adopt a product-centric funding model that enables rolling-wave planning, dynamic resource allocation, and accelerated delivery.  Moving from funding project scope to funding teams is a seminal part of product centric funding.

However, a clear understanding and alignment on “Product” and “Product Portfolio” terminology is imperative before delving into the product-based funding model and financial governance.  It is often surprising to agile team members through all levels of leadership how hard it can be to all agree on what a “product” is.  We often start by getting an agreement on what a product isn’t, such as a platform or other part of the technology stack or a corporate function such as marketing.

What is a Product?

A product is designed to continuously create business value for the customer by solving their problem or providing a benefit. Products have more permanence, and are living entities that we continuously iterate to meet market needs and finally are retired when the demand for it diminishes.

On the other hand, a project is a temporary endeavor, with a clear definition of the work that needs to be delivered, within a defined budget and by a specified date in time.

Key characteristics of a Product and a Project are elaborated below:

So, what are the benefits of pivoting to a product mode?

High Performing Teams

Standing Projects up and down is Inefficient and runs the risk of disbanding teams just as they enter the norming or performing phase. Organizations often underestimate the staff onboarding costs and ramp up time. Most product-centric organizations try to keep the same people working on a product through the lifespan of the product. Overtime, these teams build the stakeholder relationships and business domain knowledge, being stable and long-lived can benefit from a long performing phase.

Maintain Strategic Focus

Projects are funded independently and investments tend to be quite scattered and fragmented. Often, this leads to executives not having enough confidence that much of their investments are committed to top strategic priorities. Moreover, it really slows the organization’s response to change in business priorities.

Product Roadmaps are aligned with business capabilities and deliver measurable business outcomes. Further, funding is continuous with frequent checkpoints, allowing to dynamically reposition investments should the business priorities change

Ability to Truly Iterate

Projects are funded in one go, the entire agreed upon scope is funded to deliver the projected benefits. These un-validated hypotheses of benefits in the business case are based on a lot of assumptions, and it is often not feasible to clarify the entire scope upfront, despite the significant investment routinely made with traditional approaches. The reality is that many projects regularly miss the mark in terms of delivering benefits, and organizations often don’t have an effective process in place to validate actual benefits post every release.

On the other hand, product funding is continuous and flow based on validated learning of short timelines. This is a truly iterative approach that allows to pivot or preserve strategy to maximize the value delivery.

Customer focused

Project teams measure success as the delivery of agreed up-front scope, on time and in budget. This often means that they get too solution focused and lose sight of whether appropriate value is being delivered to the stakeholders. There is no point in delivering the entire upfront agreed scope if it doesn’t cater to the stakeholder needs anymore.

We all work to create value for our stakeholders as well as the organization. Business outcomes allow us to define value in a measurable way, thus focusing on what matters most from the customer perspective. For product teams, success equals improvement directly related to a business outcome. Hence, rather than seeing their job as delivering a task, product teams focus on delighting and adding value for their customers (internal or external).

Knowledge Retention

Project teams ramp up quickly to build a solution over one or more releases, hand it over to an operations team in the “run” organization and are then disbanded, and the members move on to other project teams. With project teams being continually dragged onto new things, it gets very difficult to retain knowledge in legacy systems and often results in unmaintainable code, making it much harder to support such systems.

On the other hand, knowledge grows in product teams that allows team members to focus on a given business area for much longer. Overtime, these teams build strong stakeholder relationships and business domain knowledge, and can better understand the stakeholder problems and serve to their needs.

System Integrity and Continuous Improvement

Project teams are in constant pressure to deliver the agreed scope in defined timelines. This often leads to cutting corners and applying tactical fixes, increasing technical debt and neglecting long term architectural integrity in favor of short-term feature delivery. As the project team doesn’t face the long-term consequences of these tradeoffs, they are more likely to take such decisions for short-term gain. Over a period, this phenomenon compromises stability of systems, lowering quality and worsens the seed of value delivery.

On the other hand, Product teams have complete and collective ownership of the code and systems. There are no handovers, BAU or Operations team. The same team builds, runs and fixes any defects over the lifespan of the product, allowing them to evolve the system continuously and in a more sustainable manner.  This also fosters a mindset that promotes taking responsibility for their product and the decisions they are empowered to make.

Making the shift to a Product Centric Organization Model

According to a recent Gartner survey, 85% of the organizations have adopted or plans to adopt a product-centric organization model.

To enable accelerated value delivery, adaptive planning, and flexibility required to achieve the digital priorities, many organizations are shifting towards a product centric model. In a product centric model, organizations align funding & resources to product portfolios that support their key business capabilities.

A business capability is the ability of an organization to do things effectively to achieve desired business outcomes and measurable benefits. Each business capability is independent from other business capabilities and realized by combining different functions of an organization to fulfil one functionality. Example, for an FMCG, key business capabilities are often: Direct to Consumer, Wholesale and Retail.

The key primary constructs of translating Enterprise Strategy into traceable User Stories, via Features and Business Outcomes are:

• A Product Portfolio, also known as a Product Line, solely exists to fulfill its contribution toward realizing the overall enterprise strategy. Each Product line is tied to a distinct business capability with end to end accountability to deliver measurable business outcomes.

• The Portfolio Management board allocates funding across each of the Product Lines based on the importance of the business capabilities they support and the business outcomes they are expected to deliver. The Product Line budget is then split into individual product streams by the Product Line Council, which is then further split into individual feature teams by the Product Council.

• The business outcomes communicate aspects of strategic intent from the enterprise to the product line. Business outcomes are a means of concisely capturing business needs in a measurable way. Business outcomes most often require product functionality as well as supporting business activities (sales, marketing, promotions, delivery chain, etc.). The product teams work with leadership to establish measurable product outcomes tied to those business outcomes, which are then further split into Key Performance Indicators (KPIs) for each Product Feature team, who will then breakdown those features into user stories, establishing a clear line of sight from enterprise strategy to user stories.

Adaptive Funding of Products and Product Portfolios: From Annual to Quarterly Cycle

Organizing work by Products and Product Portfolios is a good starting point to accelerate the delivery of value to one’s customers. However, that enough won’t suffice if the work is still funded through projects on an annual basis.

An annual investment process simply can’t keep up with the pace of change. Under an annual planning approach, entire funding is allocated at the start of the fiscal year. Significant effort is spent upfront to create a detailed business case required to win the funding approval. Changes in stakeholder priorities or market demand often render a lot of early requirements captured in the business case as obsolete, creating a lot of waste and requiring significant rework.

Thus, to achieve their digital ambitions, enterprises must work with business and Finance partners to move beyond traditional project-centric funding models and adopt a product-centric funding model that enables rolling-wave planning, accelerated delivery of value, and validated learning to make much more informed decisions.  Moving from funding project scope to funding teams is a seminal part of product centric funding.

(Re)allocation of Funds across Product Portfolios

Initial annual funding allocations to individual product portfolios are based on un-validated hypothesis of benefits, which must be tested over the course of the year against changing priorities and proven value. The Portfolio Management Board meets on a recurring basis (Quarterly plus any market triggered event) to assess the allocation at the product-line level and reallocating funds as necessary to reflect changes to strategic enterprise priorities.

(Re)allocation of Funds within a Product Portfolio

The Product Line Council has the autonomy and the empowerment to reprioritize and reallocate funds across all products within the product line.  Each product team within a product line are allocated funds on a quarterly basis based on proven value (unless it’s the first quarter where funding is based on projected benefits). The business value is measured by hitting a set of KPIs tied to the business outcomes such as increasing revenues, reducing costs, and improving customer satisfaction. This level of decentralization in decision making is possible when an organization implements a consistent, standardized and predictable cadence to support governance, offering frequent opportunities for key stakeholders to provide input on the roadmap.

Impediments to adopt Product-based Funding Model

The shift from a project-based funding model to a product-based funding model requires a major cultural and mindset change, as different stakeholders will have different reservations about the new approach. Some of the challenges to adopt a product-based funding model include:

Business & Finance partners reluctant to cede control of budgets

Some CFOs and business leaders are reluctant to cede control of budgets. In response, they must be made to understand that the reality is that they are gaining a lot more control by not allocating the entire funding based on the un-validated hypothesis of projected benefits and with no benefits tracking in place most cases. Also, by offering them visibility into product portfolio performance on quarterly basis with the option to pivot or preserve funding strategy based on proven value and/or change in priorities, we can significantly reduce the risk of financial loss.

Product Managers lacking finance expertise to manage product budgets

Identifying Product Managers with sufficient expertise to manage large budgets is often challenging and requires significant effort and commitment from the organization to build the financial competencies.

Resistance to funding not” fully detailed” requirements or outcomes

Business partners feel a comfort factor with a detailed business case based on projected benefits, even if it is based on a lot of assumptions and uncertainty upfront. To get business partners fully on board, product leaders need to craft a pitch that provides tangible examples of how adaptive funding model leads to better business outcomes.

Requires structural changes to support product-centric organization

Most companies we work with are organized around functions. Organizational structure change is required to adopt a product-centric operation model. Organizations are reluctant to Org design changes as it can be very difficult and expensive to implement.

Parting Thoughts

We have endeavored to shed some light on a very complex topic, balancing the amount of context we can provide in a blog entry.  If you have any questions please do use the comments section below.

Joshua Barnes, CDAC | CDAI

Jeev Chugh, CDAP | CDAI

A common question that we get from customers who are new to Disciplined Agile (DA) is how do you aggregate, or "roll up", metrics from agile teams into a portfolio dashboard?  A more interesting question is how do you do this when the teams are working in different ways?  Remember, DA teams choose their way of working (WoW) because Context Counts and Choice is Good.  Even more interesting is the question “How do you aggregate team metrics when you still have some traditional teams as well as some agile/lean teams?”  In this blog we answer these questions one at a time, in order.

Note: We’re going to talk in terms of a single portfolio in this article, but the strategies we describe can apply at the program (a large team of teams) too, and then the program-level metrics are further rolled up to higher levels.

How Do You Aggregate Agile Team Metrics Into a Portfolio Dashboard?

Pretty much the same way you aggregate metrics from traditional teams.  There tends to be several potential challenges to doing this, challenges which non-agile teams also face:

1. You can only aggregate metrics with similar units. You do need to be careful with some measures, such as team velocity, because the units vary across teams.  It is possible to enforce a common way to measure velocity across teams, but this tends to be more effort than it’s worth in practice. Sometimes there are metrics which you think you should be able to roll up but you discover (hopefully) that you really shouldn’t.  One example of this is number of defects by severity.  You can roll this metric up when the severity of a defect is determined in a consistent manner across teams, but this isn’t always the case in practice.
2. Sometimes the math gets a bit complex.  Aggregating metrics isn’t always based on simple addition.  Many times you will need to weight metrics based in terms of time, size, financial impact or combinations thereof.  Interestingly, although some metrics can’t be rolled up because they are measured in different units, you can often roll up the trends of those metrics.  For example, acceleration is the change in velocity of a team.  Given an appropriate weighting formula you can roll up an average acceleration figure across teams.
3. Some people believe you can only aggregate the same metric. Basically, when a common metric is captured across teams (for example Net Promoter Score (NPS) or cyclomatic complexity) then you can easily (albeit with some “complex” math in some cases) roll them up to a program or portfolio level.  In the Govern Team process goal we refer to this strategy as consistent metrics, an option of the Provide Transparency decision point. This strategy works well when teams actually collect the same metrics, but in when teams choose their WoW this isn’t always the case.

How Do You Aggregate Agile Team Metrics Into a Portfolio Dashboard When the Teams Choose Their WoW, and it’s Different For Each Team?

When a team is allowed to choose it’s way of working (WoW), or “own their own process,” the team will often choose to measure itself in a manner that is appropriate to it’s WoW. This makes a lot of sense because to improve your WoW you will want to experiment with techniques, measure their effectiveness for your team within your current context, and then adopt the techniques that work best for you.  So teams will need to have metrics in place that provide them with insight into how well they are working, and because each team is unique the set of metrics they collect will vary by team.  For example, in Figure 1 below we see that the Data Warehouse (DW) team has decided to collect a different sent of metrics to measure stakeholder satisfaction than the Mobile Development team.  The DW team needs to determine which reports are being run by their end users, and more importantly they need to identify new reports that provide valuable information to end users – this is why they have measures for Reports run (to measure usage) and NPS (to measure satisfaction).  The Mobile team on the other hand needs to attract and retain users, so they measure things like session length and time in app to determine usage, and user retention and NPS to measure satisfaction.

Figure 1. Applying consistent metrics categories across disparate teams (click on it for a larger version).

Furthermore, the nature of the problem that a team faces will also motivate them to choose metrics that are appropriate for them. In Figure 1 we see that each team has a different set of quality metrics: the DW team measures data quality, the mobile team measures code quality, and the package implementation team measures user acceptance test (UAT) results. Although production incidents and automated test coverage are measured by all three teams, the remaining metrics are unique.

The point is that instead of following the consistent metrics practice across teams by insisting that each team collects the same collection of metrics, it is better to ask for consistent metric categories across teams. So instead of saying “thou shalt collect metrics X, Y, and Z” we instead say “Thou shalt collect metrics that explore Category A, Category B, and Category C.” So, as you can see in Figure 1, each team is asked to collect quality metrics, time to market metrics, and stakeholder satisfaction metrics but it is left up to them what metrics they will choose to collect. The important point is that they need to collect sufficient metrics in each category to provide insight into how well the team addresses it. This enables the teams to be flexible in their approach and collect metrics that are meaningful for them, while providing the governance people within our organization the information that they need to guide the teams effectively.

So how do you aggregate the metrics when they’re not consistent across teams?  Each team is responsible for taking the metrics that they collect in each category and calculating a score for that category.  It is likely that a team will need to work with the governance body to develop this calculation.  For example, in Figure 2 we see that the each team has a unique dashboard for their team metrics, yet at the portfolio level the metrics are rolled up into a stoplight status scorecard strategy for each category (Green = Good, Yellow = Questionable, Red = Problem). Calculating a stoplight value is one approach, you could get more sophisticated and calculate a numerical score if you like.  This is something the governance body would need to decide upon and then work with teams to implement.

Figure 2. Rolling up metrics categories (click on it for a larger version).

From the looks of the Portfolio dashboard in Figure 2 there is a heat map indicating the overall status of the team (using green, yellow, and red again) and the size of the effort (indicated by the size of the circle). Anyone looking at the portfolio dashboard should be able to click on one of the circles or team stoplights and be taken to the dashboard for that specific team. The status value for the heatmap would be calculated consistently for each team based on the category statuses for that team – this is a calculation that the governance body would need to develop and then implement.  The size of the effort would likely come from a financial reporting system or perhaps your people management systems.

How Do You Aggregate Team Metrics When Some Teams Are Still Traditional?

With a consistent categories approach it doesn’t really matter what paradigm the team is following.  You simply allow them to collect whatever metrics are appropriate for their situation within each category and require them to develop the calculation to roll the metrics up accordingly.  If they can’t come up with a reasonable calculation then the worst case would be for the Team Lead (or Project Manager in the case of a traditional team) to manually indicate/enter the status value for each category.

Parting Thoughts

For the consistent categories strategy to work the governance people need to be able to look at the dashboard for a team, which will have a unique collection of widgets on it, and be able to understand what the dashboard indicates. This will require some knowledge and sophistication from our governance people, which isn’t unreasonable to ask for in our opinion. Effective leaders know that metrics only provide insight but that they shouldn’t manage by the numbers. Instead they should follow the lean concept of “gemba” and go see what is happening in the team, collaborating with them to help the team understand and overcome any challenges they may face.

Related Links

• The Governance Process Blade
• The Measure Outcomes process goal
• The Organize Metrics process goal

IT Portfolio Management addresses how an IT organization goes about identifying, prioritizing, organizing, and governing their various IT endeavors.  Disciplined Agile Portfolio Management seeks to do this in a lightweight and streamlined manner that maximizes the creation of business value in a long-term sustainable manner. IT endeavors typically include solution delivery initiatives/projects, stable product development teams, business experiments (along the lines of a lean startup strategy), and the operation of existing IT-based solutions.

Being agile, having an agile mindset, is foundational to working in an agile manner. The Disciplined Agile Manifesto and the principles of lean software development provide an important start at this mindset. In this blog we explore similar agile philosophies that are specific to successful portfolio management. These philosophies are:

1. Keep it simple. Keep your portfolio management activities as streamlined and lightweight as can be. Your goal should be to focus on making good decisions and providing guidance to people, not on maintaining extensive documentation or reviewing documentation. You still may choose to maintain artifacts such as a portfolio roadmap and portfolio budget, but those too should be as lightweight and concise as possible.
2. Focus on value over cost. Shifting your mindset from “what is this going to cost?” to “what value will this generate?” is critical to your success because it helps you to focus making better IT investments. You want to invest in IT endeavors that enhance your organization’s ability to produce value for your customers. This in turn provides the profits required for further investment.
3. Reduce the cost of delay. One of the strategies for maximizing stakeholder value is to invest in developing functionality that will provide value to the organization soonest.   For example, if you delay developing functionality that will generate annual revenue of $10 million for six months you have an effective cost of delay of $5 million because you missed out on half a year of revenue.   Disciplined agile portfolio managers consider the cost of developing a solution, the cost of delay that results from putting off said development, and the revenue generated (or cost savings) when calculating the overall value of a solution.
4. Invest in streamlining the creation of value. Not only do we want to produce value for our customers, we also want to be good at doing so. The implication is that we sometimes need to invest in ourselves through process or environment improvements.
5. Prefer stable teams over project teams. Although portfolio management is often believed to be the oversight of project teams, it really is more about the coordination and oversight of teams in general. In Disciplined Agile we recognize that an initiative is seldom finished at the end of a “project”. There are usually subsequent changes required over time requiring future releases of the solution. The agile community has discovered that long-lived stable teams, whose membership evolves over time, have significant advantages over short-lived project teams. A significant productivity improvement occurs when IT organizations shift away from the project mindset of bringing people to the work and instead decide to bring work to the people (the stable teams).
6. Align teams to value streams. These stable teams should be aligned long-term to value streams or lines of business (LOBs). High performing agile teams reliably deliver value frequently to their business stakeholders. As a result the business learns to trust the teams aligned to their areas. This positive feedback cycle maximizes the effectiveness of your agile teams. Additionally, over time they learn more about the business adding to their effectiveness.
7. Enable diversity. Every person, every team, and every organization is unique. Every team faces a unique situation that evolves over time. The implication is that teams must be allowed to organize themselves and to tailor their process to meet the context of the situation that they face. This is why the Disciplined Agile (DA) toolkit focuses on providing, and comparing and contrasting, a wealth of process choices. The implication for portfolio managers is that they need to be flexible in their approach. They will work differently with each team because each team works differently, yet they must still provide good guidance to these teams and monitor the effectiveness of each team appropriately.
8. Trust but verify. Effective governance is based on enabling and then trusting your teams to do the right thing. However, effective teams monitor themselves through the use of automated dashboard technology and close collaboration, and the metrics that teams collect should be made visible to senior management and other stakeholders so that they may monitor what is happening.
9. Govern by risk not by artifacts. Traditional governance often focuses on the review of common artifacts such as requirement documents, architecture models, and test results. Because it is relatively easy for teams to create the documentation that you want to see, in practice there is very little governance value in reviewing these artifacts. Agile governance instead focuses on addressing common risks such as ensuring there is an agree to vision for what the team should accomplish, that the architectural strategy has been proven to be viable early in the lifecycle, and that the team has produced sufficient business value for their stakeholders.
10. Rolling wave over annual planning. Annual planning often begins in earnest mid-year which means that prioritized initiatives may not be actually delivered for up to 18 months in the following year. This is not business agility. Make your planning a continuous “rolling wave” activity year round with more detail devoted to planning initiatives no longer than 6 months out. Initiatives planned beyond 6 months should be described at a very high level.
11. Prefer small initiatives over large initiatives. It is a proven fact that the larger the initiative the greater the chance of failure. Smaller initiatives are easier to plan and are lower risk to execute. Keep your initiatives small to allow for more frequent delivery of value with less investment in work in progress (WIP).
12. Invest in quality. Ensuring that IT delivery teams produce new business value for your organization is clearly important. But so is ensuring that you will still be able to continue doing so a few years from now. To ensure the long-term sustainability of your IT teams you must allow them to make investments in quality. These investments include building high quality assets in the first place but also fixing low quality assets, what agilists refer to as paying down technical debt, as well.
13. Optimize the whole. Disciplined agilists are enterprise aware. We choose to optimize the whole instead of locally optimizing a single activity. The implication is that you cannot consider portfolio management on its own but instead must consider it in the context of the other parts of your organization that it affects. A strategy that may make things easier to manage your portfolio, such as having a single way to fund IT delivery teams, may make it easier for your portfolio management efforts but could inflict undue costs and bureaucracy on the teams that you’re funding. For example, does it really make sense for a team asking for $50,000 in funding to go through the same level of rigor as a team asking for $5,000,000? Likely not. Context counts.

Our experience is that the philosophies describe above enable portfolio managers to be more effective in practice. We hope you have found this blog of value and we welcome your feedback.

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

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.

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.

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.

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.

As you can see, rolling wave strategies are an integral part of the Disciplined Agile (DA) toolkit. 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.