Category Archives: Planning

Rolling Wave Planning in Disciplined Agile

Wave

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.

Rolling Wave Planning for Technology Roadmaps

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 article explores how to apply rolling wave planning in a pragmatic manner to technology roadmaps.

An important aspect of your enterprise architecture efforts is to provide architectural guidance, both business and technical guidance, to your organization. One of the key artifacts that enterprise architects will create is a technology roadmap that, as the name suggests, provides guidance as to the proper application of technologies within your organization. This roadmap will often supplement any “as is” and “to be” models that the enterprise architects create.

Technology roadmaps are often evolved following a rolling wave planning approach. Figure 1 depicts an example of a technology roadmap, the goal of which is to  give technical direction to solution delivery teams so as to provide safety rails around technical experimentation.

Figure 1. A technology roadmap in September 2016.

Rolling wave technology roadmap

 

Notice how this roadmap addresses several categories of technical issues:

  1. Planned upgrades. Development teams need to know what aspects of your infrastructure will be evolving and when. Upgrades that are soon to occur have been assigned dates as these changes are very likely going to impact several development teams.
  2. Experiments. From an agile point of view the most interesting thing is the list of experiments that the enterprise architects are overseeing. These experiments usually occur within one or more of the development teams underway in this company. In this case the EAs are coordinating and guiding the experiments, ensuring that the teams focus on experiments that reflect the overall direction of the organization. In some cases you may choose to have an explicit proof of concept (PoC) project to validate a new technology, a common approach for major infrastructure components or expensive packages. Either way, by planning for explicit experimentation you bring greater discipline to your learning and architectural evolution efforts.
  3. Reusable infrastructure. This company has a reuse engineering effort underway where common architectural components, in this case microservices, are built and then made available to development teams. Once again, the closer to being released the reusable components are the more likely it is to have a target date for their release.
  4. Retirements. An aspect of technology roadmaps that are often forgotten are the plan to retire existing systems and infrastructure components. An important part of paying down technical debt within organizations is the consolidation of your IT infrastructure – reducing the number of technologies that you’re using, removing redundant systems, and so on. Such retirement efforts can take months and even years. We see in Figure 1 that SQLServer is currently being retired from service, development teams are migrating to approved database technologies, and that it is slated to be completed by February 5th. In this case the enterprise license for SQLServer ends in April 2017 so they’re hoping to be completely off of it two months before that.

 

What Should the Planning Horizon Be?

Technology roadmapping tends to have between a six month and three year planning horizon depending on what is being planned for. For example, experiments are typically planned out a few months in advance as they are often driven by the needs of development teams. Major upgrades are typically planned on a horizon of six months to a year as this reflects the rate of change of many technologies. Retirements might typically planned for years in advance, particularly when the retirement could impact multiple systems.

 

How to Capture Technology Roadmaps

Technology roadmaps are typically captured in text format as you see in Figure 1 above, although a timeline format (as we say with product roadmaps) are often used for executive presentations.

This sort of planning is only one of several things that your enterprise architecture team will do of course. In addition to actively guiding development teams and working with senior stakeholders, the enterprise architects are also maintaining current and to-be models and are hopefully producing code examples for how to work with new architectural components.

Rolling Wave Planning for Product Roadmaps

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 article explores how to apply rolling wave planning in a pragmatic manner to product roadmaps.

An important aspect of product management is to develop and evolve an overall business vision, an important part of which is your organization’s product roadmap. This is sometimes called a “multiple product roadmap” or “product offerings roadmap” although more commonly just a “product roadmap.” This roadmap indicates upcoming product releases (or application releases for non-product companies), potential product ideas, and the retirement of any products. The goal is to manage customer expectations regarding your product portfolio.

An example of a product roadmap for a fictitious company is depicted in Figure 1 below. For product planning this company’s very near term (green) is a three month, rolling period. In this case we’re seeing the roadmap as of September 2016. For the very near-term the expected release dates of each product are indicated. This company has chosen to also do this for some, but not all, of the products being release din the near term (yellow) – In some cases it isn’t yet clear exactly when a release will occur so the company doesn’t want to set unrealistic expectations by giving an exact date yet. In the case of Katana 12.1 they are committing to a date whereas with Webshooter 1 they are committing to sometime during quarter 2 (April through June). The other product releases do not have published dates yet.

Figure 1. A product roadmap (text approach) from September 2016.

Product roadmap - text-based version

It’s interesting to note that for upcoming (red) they are choosing to just indicate new products they hope to release during that period but not releases of existing products. This is because this period is nine months or more into the future so promising exact dates to people becomes a questionable proposition, far better to indicate ranges for now. For the distant future (gray) the product roadmap shows potential ideas for new products but these are only vague “wish list” items at best right now, not all of which will be invested in.

Figure 2 depicts a timeline version of a product roadmap. It focuses on currently planned product releases and so it does not depict the future product ideas that we saw in Figure 5.   These product ideas would be captured elsewhere, perhaps as a list on a whiteboard some where.

Figure 2. A timeline version of a product roadmap.

Product roadmap - Timeline version

What Should the Planning Horizon Be?

Product roadmaps tend to have a multi-year planning horizon. Figure 1 showed about two years of planning whereas Figure 2 a bit more than a year. There are several key considerations to take into account when determining your planning horizon. First is how often can your teams release? You typically want to be able to indicate several releases of your major products/solutions on your roadmap, which you can see in both examples. Second, how often do your customers want releases?   Third, how far in advance do your customers need to plan? This is a reflection of the sales cycle for your products, the longer the sales cycle the longer between releases of your product (usually) and the longer the timeframe covered by your roadmap.

 

How to Capture Product Roadmaps

There are two basic strategies for depicting product roadmaps:

  1. Text lists. Figure 1 is an example of this format. The advantages are that this format is compact and easy to create with simple tooling. The main disadvantages are that it doesn’t show relationship between releases well nor is it very attractive visually.
  2. Timeline diagrams. See Figure 2 for an example. The advantages of this approach are that it is visually appealing, which is particularly important when you are showing the roadmap to customers; it depicts timing relationships well; this format is supported by several product management tools; and you can even show dependencies between product releases, in a similar manner as you would do so on a Gantt chart (we didn’t do this in Figure 6). The primary disadvantage is that this format requires more sophisticated tooling to create.

Your product roadmap is an important part of your organization’s overall business vision. Another part of that vision is your business roadmap, the topic of a future blog.

Rolling Wave Release Planning for Agile Delivery Teams

Wave

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.

In Figure 1 you see how a Disciplined Agile Delivery (DAD) team takes a rolling wave approach to release planning. This is a stable team that releases their product into production twice a year. The team has been in place for almost three years and as a result they no longer need to go through an Inception phase. The Construction phase is typically scheduled for twelve iterations. Their Transition phase still takes one week. Although they’ve automated their test and deployment scripts a long time ago they still need time for internationalization – in this case they need to finalize and acceptance test any translated work.

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

Rolling wave release planning overview

 

Figure 2 overviews the level of detail that the team currently has captured in their requirements artifacts and in effect how they would show up in any sort of team work plan. The team is currently in the first construction iteration for the current release, implementing 5 user stories. There are thirteen additional user stories that have been explored in detail by the product owner which at the team’s current velocity is about one month of work. There are an additional thirty user stories identified but not yet explored, and several epics. In the middle of this current iteration the product owner is likely to run one or more look-ahead planning/modeling sessions (called backlog grooming or backlog refinement in Scrum). The goal of this effort will be to detail a few of the near term (yellow) stories to pull them into the very near term (green) category and maybe to even start breaking down an epic or two into more details stories. This effectively pulls work along in the plan. The team’s iteration/sprint planning session at the beginning of each iteration pulls work into the team at that point.

Figure 2. Solution release planning at construction iteration #1.

Rolling wave release planning iteration 1

An interesting implication of this approach is at the beginning of the iteration it isn’t clear exactly what the team will deliver. As you can see in Figure 2 only about one-and-a-half months of work has been explored in detail (eighteen stories in total), an additional two months of work (thirty stories) has been identified at a high level and the rest at a very high level. In addition, the stakeholder’s priorities could shift and different stories and epics could be prioritized higher in the team’s work item stack (backlog) later on in construction.

Now let’s work through what things look like at the beginning of iteration #8.   As you can see in Figure 3 the team is currently working on six stories and has eleven more that have been detailed out for the next month or so. There are thirty-two stories identified for the near term (yellow) category. Interestingly, Construction ends in about two months (remember, the releases are six months long with this team). At this point in time it’s fairly clear what the team will deliver, albeit with some room for change given that there is still to months of construction left.

Figure 3. Solution release planning at construction iteration #8.

Rolling wave release planning iteration 8

 

What Should the Planning Horizon Be?

In this example the planning horizon is fairly long because the team’s release cycle is fairly long at six months.   They chose to maintain about three months of details and kept everything else at a high level and that worked for them. We recently worked with a team at an e-commerce firm following the continuous delivery lifecycle where the distant future (grey) was anything more than two months away. As a result they had detailed requirements for the next two to three weeks (green), about the same number of stories that hadn’t been worked through yet for near term work (yellow), and then a collection of epics after that. The point is that you need to set your planning horizons according to the situation that you face. Context counts.

 

Capturing a Release Plan

A deliver team can choose to capture their release plan in several different ways, and could even combine strategies for doing so. Their options include:

  1. Maintain the plan manually. Many teams will capture their requirements manually, using paper to capture the stories, acceptance criteria, and any supporting artifacts. For the current iteration the team manages their work on a whiteboard with sticky notes or corkboard with index cards. Future work is often tacked onto a corkboard or maintained in file folders or similar containers. The advantages of this approach are that the plan is easy to evolve and work with (you’re moving paper around). The disadvantages are that reporting also becomes manual (perhaps you’re asked to estimate your expected delivery date or cost using burn up or burn down charts), it doesn’t easily support geographic distribution, and that this strategy may be anathema to your governance people if they’re not experienced yet with agile development.
  2. Use an agile management tool. Many teams choose to use agile management tools such as Atlassian Jira, VersionOne, Microsoft TFS, or Rally to name a few. These tools have the advantage that they support geographically distributed teams, they often also address any plan documentation needs for teams working in regulatory situations, they are often less threatening to your governance people, and they can even be integrated into any corporate reporting technologies your company has in place (such as Microsoft Project Server for example). The disadvantages are that they are often harder to use than manual strategies (regardless of the vendors’ marketing claims), agile management tools can still be threatening to traditional-leaning governance people because of they support a more agile way of working, and of course the need to pay for and learn them.
  3. Create a Gantt chart. Your rolling wave plan can also be captured using Gantt charts (yes, Gantt charts can be used in an agile manner if you choose). The article Agile Project Planning Tips works through how a Gantt chart evolves with a rolling wave planning approach. The advantages are that Gantt charts are a familiar way to communicate your schedule to others and that your existing management tools likely support them already. The disadvantages are that Gantt charts can still be a bit clunky from an agile point of view and that many project management tools make it too easy to capture details that often prove to be of little value in practice.

A potential point of confusion is what to call this sort of plan. Up until now we’ve been using the term release plan. However, as you can see in both Figure 2 and Figure 3 the plan extends to more than a single release of this product. This is really a “multiple-release plan” or better known as a product plan (not to be mistaken with a product roadmap, something that your product management efforts will often produce). More on this in the next blog posting in this series.

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.

How to Choose an Agile Release Cadence

Metronome

One of the things that a delivery team needs to do, often in collaboration with product management, is choose the release cadence of their product. This is an important aspect of, you guessed it, release planning.  Your release cadence defines how often you release your solution both internally and externally into production (or the marketplace). The issue is how to determine how often the product should be released into production. In this blog we explore:

  1. Where are you deploying to?
  2. What affects release cadence?
  3. What release cadence choices do you have?
  4. What do we recommend?

 

Where Are You Deploying?

There are several target environments that you might choose to deploy to. These environments include:

  1. Demo environment(s). Many teams maintain a demo environment for their solution so that their stakeholders can see what has been developed to date at their leisure. Demo environments support transparency with your stakeholders, reduce the number of “one-off” requests by stakeholders for demos (because they can simply see the solution for themselves), and of course they provide a stable environment in which your teams can run demos.
  2. Testing environment(s). Many teams have their own testing environments, or they work with independent test teams with their own testing environments, or both. You should strive to test as often and early as possible, an implication being that want to deploy into your test environment(s) as often as you possibly can.
  3. Production/marketplace. Some teams will release their solutions into their production environments (or to someone else’s cloud) where end users will use the systems. In the case of commercial software companies they will release their solutions into the marketplace where they are then sold to customers. Throughout this blog whenever we use the term production we also mean the marketplace.

For the sake of terminology, deploying into demo or testing environments are often referred to as internal releases and into production as an external release.

 

What Affects Release Cadence?

There are several factors that affect the choice of release cadence:

  1. Stakeholder needs. How often do your stakeholders, and in particular your end users, want your solution to be released? This can be a difficult issue because very often your stakeholders might not be able to perceive what is appropriate for them. We’ve seen stakeholders ask for quarterly releases, be delighted when then get monthly releases, and then start asking for weekly releases once they realize the potential of modern agile strategies.
  2. Stakeholder capability to accept change. We like to think that more often is better, and in the vast majority of situations it is. As difficult to believe as this may seem, at the far extreme we’ve also seen some systems where the natural release cadence is once every three or four years because that’s the rate at which stakeholders are able to accept change. In this case the product was a transaction processing (TP) system infrastructure product, but we’ve heard similar stories about major database management systems (DBMSs) products too. Granted, a release cadence this long is very rare but it does happen in a small number of situations. Far more common is the mistaken belief by IT professionals that their stakeholders are unwilling or unable to accept shorter release cycles. We’ve seen numerous organizations where the IT people tell us that their stakeholders can’t handle anything more regular than a quarterly or bi-annual release, yet these same stakeholders regularly use commercial software that is updated several times a week.
  3. Your organizational culture. Some organizations, particularly those with an existing traditional release management team, often have release cultures that lean towards larger and less frequent releases. These organizations often have significant investments in legacy systems and insufficient investments in automated regression tests/checks. As a result releasing solutions into production tend to be seen as a risky endeavour. At the other extreme we’ve seen companies with more of a continuous delivery mindset that have a “release as swiftly and often as you can” culture. These organizations have typically invested heavily in code quality, automated regression testing, and automated deployment thus making deployment a simple and virtually risk-free effort.
  4. The team’s ability to deliver. Of course a primary determinant of your release cadence will be how often you’re able to actually produce a potentially consumable solution. This is affected by the skills of your team members, your ability to collaborate, your ability to vertically slice functionality into small features, and your delivery infrastructure.
  5. Your delivery infrastructure. How easy it is to release a potentially consumable solution into production is determined in part by your technical environment. This includes the extent of your automated regression tests, your automated deployment scripts, and your capability to monitor production. In general, the greater the level of automation the more often you can release.
  6. Your solution architecture. Is your solution architected to be released incrementally? Is it possible to enable/disable functionality at a granular level (perhaps via feature toggles or a similar technique)?
  7. The cost/risk to release.   Cost and risk tend to go hand-in-hand when it comes to releasing solutions into production. This is because the more manual your release/deployment processes the more expensive they become and the more likely there are to be problems somewhere in the process. Conversely, the more you automate the overall deployment effort the cheaper it is to deploy and the less risky it becomes as you’re more likely to run into, and then automate a solution to, deployment problems. The less expensive and less risky it is to release your solution the more viable it becomes to release more often.
  8. Release cadence of other teams. Like it or not your team is likely dependent on the work of other teams. For example you may need web services being built by another team, and you can’t fully release your solution until those web services are available in production.  We’ve written detailed articles about how to manage dependencies between agile/lean and traditional teamsdependencies between agile teams, and dependencies between agile and lean teams.

 

Release Cadence Choices

Table 1 lists many common release cadences, from more than annual to several times a day. It also lists the potential tradeoffs of each approach and indicates when you may want to adopt each one.

Table 1. Comparing external release cadence options.

Strategy Potential Advantages Potential Disadvantages When to Apply
Many times a day Enables very short time to market

Enables teams to adapt quickly to changing stakeholder needs

Enables granular release of functionality

Requires extensive continuous integration (CI) and continuous deployment (CD) automation

Requires high discipline to maintain quality

Your solution architecture must support toggling of features to enable deployment of larger functions as a collection of smaller features

Effective for high-use systems, particularly those used by external customers in highly-competitive environments
Daily Same as above

Provides a regular (daily) release cadence that is predictable

Same as above Same as above
Weekly Provides a regular (weekly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Same as above Effective for high-use solutions, particularly e-commerce or BI/reporting systems

Appropriate for teams following the Lean lifecycle

Monthly Provides a regular (monthly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Requires extensive continuous integration (CI) and continuous deployment (CD) automation

Requires high discipline to maintain quality

Effective for medium-priority solutions

Appropriate for teams following the Agile/Basic lifecycle with one-week iterations or the Lean lifecycle

Quarterly Provides a regular (quarterly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Enables simpler requirements management practices (compared with longer release cadences) due to lower impact of a feature moving to the next release

This is a major milestone for teams moving towards an “advanced” lean-agile strategy as it motivates greater discipline.

Requires continuous integration (CI)

Requires automated deployment strategies

Effective for medium-priority solutions

Appropriate for teams following the Agile/Basic lifecycle with one or two week iterations

Variable Works well with a project mindset (although that’s questionable in and of itself) Teams need to be able to judge when their work reaches the minimally marketable release (MMR) stage and the business value added exceeds cost of transition. This decision point is captured in the DAD project lifecycles by the “sufficient functionality” milestone

Politics can hamper this decision point. You should put an upper limit on the acceptable time between release

Project teams

Stable teams assigned large “projects”

Bi-annual Good starting point for teams new to agile who are currently working on traditional projects with longer release cadences because it motivates adoption of disciplined strategies Can be difficult for stakeholders who are used to less frequent releases The team may need significant agile coaching as they will run into many of the “but we’re different and that agile stuff can’t possibly work here” type of problems
Annual Provides a regular (annual) release cadence that is predictable

 

Very risky, the team is likely to miss their date

Requires internal releases to obtain feedback

The deployment has likely become high risk because you do it so infrequently (self fulfilling problem)

Appropriate for low priority systems or for high-risk deployments (note that the deployments may have become high-risk because you do them so infrequently)
More than annual See annual

 

See annual

This is common for infrastructure systems, such as a database or transaction managers, that have many other systems highly dependent upon them

 

Our Recommendations

When it comes to releasing your solution, we have several recommendations for you to consider:

  1. Automate, automate, automate. The more you have automated, the lower the cost of deployment and the lower the risk. This enables you to release more often with confidence.
  2. Release internally very often. This is your opportunity to get good at releasing your solution, at squeezing out the cost and the risk.
  3. Release externally as often as possible. The faster and more often you can release into production the more competitive your organization will be.
  4. Always look for ways to release more often. Impressed with your ability to release once a month? Aim for bi-weekly. You’ve now releasing bi-weekly? What’s stopping you from releasing weekly? Weekly releases? Meh! Release daily! Your team is releasing daily grandpa? How about automatically releasing many times a day every time you have a working build?

 

Further Reading