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


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.

Process Tailoring Workshops Help Increase Agile Team Productivity


I recently wrote a detailed article about process tailoring workshops.  In a process tailoring workshop a coach or team lead walks the team through important aspects of the delivery process and the team discusses how they’re going to work together. This typically includes choosing a lifecycle, walking through the process goals one at a time and addressing the decision points of each one, and discussing roles and responsibilities.

There are several reasons why you want to tailor your team’s process:

  1. Every team is unique and faces a unique situation.
  2. You want to have a common vision as to how you’re going to work together.
  3. You want to streamline how you work together.
  4. You may actually need to document your process.

The article covers the following topics in detail:

  1. Why process tailoring?
  2. When do you run process tailoring workshops?
  3. The risks associated with process tailoring workshops
  4. Planning a process tailoring workshop
  5. What should you tailor?
  6. Running a process tailoring workshop
  7. Documenting the results

I hope you find it useful.


Agile Teams and The Breakfast Club

The Breakfast Club

One of the iconic movies of the 1980s was The Breakfast Club, which told the story of five very different teenagers who were forced to come into school one Saturday to serve detention.  Recently I’ve been working at a large insurance company helping them to adopt the Disciplined Agile (DA) framework.  One of people whom I’m working with has a Breakfast Club poster on the wall near her work area and it got me thinking about some of the dynamics that I’ve seen watching agile teams form and eventually gel.  Here are my thoughts.

At the start of the movie the kids didn’t really like each other, they were very different from one another, they certainly didn’t want to be there, and they were each coming to the group with their own point of view and background.  Sadly, I’ve seen more than one software project team that was put together like this.  As the movie progressed they began to really talk with one another and their stories started to emerge.  They started to work together, hijinks ensued, and they bonded as a group.  As part of their punishment they were each asked to write an essay describing what they learned from their detention.  Instead they wrote a single letter, which follows, that they submitted as a team.

“Dear Mr. Vernon:

We accept the fact that we had to sacrifice a whole Saturday in detention for whatever it was we did wrong, but we think you’re crazy to make us write an essay telling you who we think we are. You see us as you want to see us… In the simplest terms and the most convenient definitions. But what we found out is that each one of us is a brain… …and an athlete… …and a basket case… …a princess… …and a criminal.

Does that answer your question? Sincerely yours, the Breakfast Club."

So how does this relate to agile teams?

  1. You often build teams from specialists.  Although we ideally recommend that you build teams from multi-disciplinary, T-skilled generalizing specialists, the reality is that many organizations are staffed with specialized people.  We like to say that you go to war with the army that you’ve got, or in other words you need to make do with what you have.  If all you have are specialized staff then that’s the people you have to form teams.  The good news is that you can help people to evolve from being specialists into generalizing specialists via building a cross-functional whole team, enabling and promote non-solo collaborative work within the team, and by training and coaching people.
  2. It takes time for a team to gel.  In the movie the “team” gelled in a single day, but it’s rarely that fast in practice.  It often takes weeks, and sometimes months, for a team to really get to the point where they’re working together effectively (yet another reason to move towards stable solution delivery teams).
  3. Co-location shortens the time it takes to gel.  When we’re co-located, everyone works together in the same room, it is much easier and much more likely that we will collaborate with one another.  Not only does this increased interaction help us to get the work done it also helps us to gel as a team faster.
  4. We’re not as different from each other as we think.  One of the lessons that the kids learned in the movie is that each one of them had a bit of an athlete, a brain, a criminal, and so on in them.  Similarly, we’re not just programmers, or architects, or analysts but instead we all have some of those skills in us and we can certainly get better at the skills that we are weak on.
  5. We are still different.  Every single person is a unique individual.  This implies that we must be flexible in the way that we collaborate with one another, that people simply aren’t “cogs in the corporate machine.”  We should also respect the fact that we each bring something of value to the team, a revelation that the kids in the movie stumbled upon when they had to work together to not get caught by Mr. Vernon (there were a few hijinks in the movie).
  6. Working together as a team produces better results than a group of individuals.  As Alistair Cockburn likes to say, software development is a team sport.  In the movie the kids all got caught doing something on their own, hence the punishment of a Saturday in detention, yet together they managed to have a fair bit of fun as a team.  Similarly, you may be the best programmer in the world, but it behooves you to work with people who can help you to understand the requirements, design the solution, validate the solution, and so on.
  7. We can all learn from each other.  Everyone has value to bring to the team and everyone has areas where they are weak on that could be improved.  By working closely together we can learn from each other and get better both as individuals and as a team.

The Breakfast Club is a great movie.  If you haven’t seen it, or haven’t seen it lately, then I highly suggest watching it again.

Updating the Disciplined Agile Manifesto


We have recently posted an update to The Disciplined Agile Manifesto.  In particular, we simplified the wording of the three principles (reduce technical debt, visualize workflow, multi-modal organizations) that we added to extend the original Manifesto for Agile Software Development.  We describe the updates to each of the three principles, and our thinking behind them, below.


Reduce Technical Debt

Original: #13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.

Update: #13. Leverage and evolve the assets within your enterprise, collaborating with the people responsible for those assets to do so.

The primary change here is the use of the term enterprise instead of organizational ecosystem. Over the years we had several people point out that they weren’t comfortable with that term or that they found it overly complex.


Visualize Workflow

Original: #14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.

Update: #14. Visualize work to produce a smooth delivery flow and keep work-in-progress (WIP) to a minimum.

This principle was reworded to make it more action oriented and to clearly point out the term WIP.


Multi-Modal Organizations

Original: #15. The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams.

Update: #15. Evolve the enterprise to support agile, non-agile, and hybrid teams.

As you can see we simplified this principle greatly, using enterprise instead of organizational ecosystem as above and going straight to the point of supporting multiple ways of working.

The Disciplined Agile Poster v2.1

DAD Poster People 7-4

On Wednesday, September 21 2016 we ran a webinar overviewing the latest version of the DA poster. A recording of the webinar can be viewed online from the DAC Webinars page and a PDF of the slide deck is posted on Slideshare entitled The Disciplined Agile IT Department.

During the webinar we received several questions, many of which we answered, although we did run out of time and did not get to all of them. As usual, we’ve written a blog posting to answer these questions. We’ve organized the questions into the following topics:

  1. The poster and terminology
  2. Organizational issues
  3. Adoption of DA
  4. Learning more
  5. Miscellaneous


1. The Poster and Terminology

1.1 What’s the significance of the concentric circles in shades like white, blue yellow? How do we look at those groupings?

Those are groupings on the poster. There are headings, they sort of look like ribbons, indicating the scope of each one: Delivery, Disciplined DevOps, IT.

1.2 What’s the best way to read or traverse the diagram (for beginners)? left–>right, top–>bottom, inside–>outside … ?

It’s a workflow diagram that is cyclic, so in a way it doesn’t matter. However, it does make sense to start in the top left corner if you like.

1.3 What was the thought behind the “process blade”?

We have a detailed article about the term process blade here.


2. Organizational Issues

2.1 What range of IT dept sizes is DA best suited for? Is there a sweet spot?

We’re seeing Disciplined Agile being adopted by IT departments as small as 40 people and as large as 20,000+. The issue really isn’t the size of the IT department but rather how well it is able to support the rest of your organization,

2.2 What is a role played by Chief AO and Chief PO in terms of Solution Delivery? Where can we put DAD Roles in the DA poster?

If you visit the DA home page there is the poster on there. There is also a button in the bottom left corner leading to a beta version of the diagram with the roles on it.  The IT-level roles are overviewed at Disciplined Agile Roles at Scale.

2.3 Where would someone like say a “Peoplesoft Administrator” fit into the new (beta) DA 2.x picture. I’ve seen loads of similar people/roles in a Agile Transformation initiatives at a Bank and hence the ask.

This sounds like a specialized version of an Operations Engineer to me. Also, sounds like more of a position than a role.


3. Adoption of DA

3.1 Do you have any examples of organizations in Canada (besides IBM) that are using DA or DAD framework?

There are many organizations using Disciplined Agile although this is not a complete list nor is it broken down by country. If your organization is using DAD, and you would like to get on this list, please reach out to us.

3.2 Any recommendation for terminologies/nomenclature in Agile Portfolio Management? sub-task=>story=>Epic=>Initiatives/Product=> Themes??

Use the terminologies and techniques that are right for your organization. There is no standard terminology in agile, nor will there ever be. Furthermore, every organization is unique so one process size does not fit all. You need to tailor your approach to address the situation that you face.


4. Learning More

4.1 Will there be a new book re IT and DevOps additions? When?

Yes, we have a book underway right now. Having said that, we always publish to the web first. We have published a lot here on the Disciplined Agile site, including a detailed article on Disciplined DevOps.

4.2 Is a new version of the big book coming up? Any updates to the Certification or tracks wrt. DA 2.x?

At the present moment we do not intend to publish an update to the big book. We find publishing smaller books, such as Introduction to DAD, to be more effective, and that’s what we’re currently focused on. When we publish the new book we will also be updating the certifications to reflect that, so please stay tuned.

4.3 Your current book says very little about scaling, but with the example of Barclay’s 30K IT Dept, will the new book have more “scaling” content?

We have published a fair bit about scaling online. The page Agility at Scale is a good starting point.  Also, Disciplined Agile Delivery (DAD) provides a foundation from which to scale, so I would argue we’ve written quite a bit, even in the first book.

4.4 Where I can find guidance for process blades? Will new version of book cover it?

We have published detailed information about the process blades at the DA site. A good starting page is Strategic Agility at Scale. Yes, we will be covering this material in the new book.

4.5 Will the download posters be updated to 2.1? Lot nicer to follow and look at 🙂

The poster is available for download, in various formats, from Disciplined Agile Posters.


4.6 This is very new in Europe. What are your plans to expand your DAD coverage there?

We are actively looking for business partners, including both trainers and consulting firms, in Europe, Asia, and Australia. For more information, see our Certified Disciplined Agile Instructor (CDAI) Program and our Certified Disciplined Agile Partner Program.


5. Miscellaneous

5.1 Governance is depicted at lower left (and appears IT centric). Isn’t the reality that each of the artifacts (and there are lots! on this poster) can be subjected to a simple artifact governance? Does DA leverage this?

Governance is built right into all aspects of the DA framework. The IT Governance blade is purposefully IT centric because that is the scope that we chose to address. It is in fact one part of your organization’s overall governance strategy (often referred to as a control strategy, yuck).

5.2 Does DA group recommends any tools for Agile?

We try to avoid recommending tools because it really does depend on your situation. However, we do have a good relationship with Blueprint Technologies and have been working with several of the agile management tool vendors. We do have a page discussing tool support for DAD but it’s not comprehensive.

5.3 Should operations teams run one of the lifecycles like a software delivery team? Should support?

Operations teams and support teams should definitely have a method that they follow to do their work. Given that they often need to respond to help requests, or address production problems, they very likely need to consider adopting a lean lifecycle for that type of work. In particular the Continuous Delivery lifecycle is likely closest to what they need, but this of course depends on the situation.

5.4 Where do you see DA complementing SAFe or vice versa.

In many ways SAFe is an instance of a portion of DA. Where SAFe prescribes an approach DA gives you a range of options and asks you to choose the right approach for the situation that you face.



What is a Process Blade?

Sheathed Katana

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.  Each process blade addresses a specific capability, such as Data Management, Continuous Delivery, or Portfolio Management.


The Disciplined Agile Process Blades

We’ve organized the process blades into three categories, each of which builds on the previous category:

  1. Disciplined Agile Delivery (DAD).  This category supports the four delivery lifecycles – Continuous DeliveryExploratory/Lean StartupLean/Kanban, and Agile/Scrum – as process blades as well as Program Management (the coordination of a large delivery team).
  2. Disciplined DevOps.  This category expands on Disciplined Agile Delivery to add five process blades: Non-Agile/Lean Lifecycles (which are recognized by, but not supported by, the DA framework),  Release Management, Operations, Support, and Data Management.
  3. Disciplined Agile IT. This category expands on Disciplined DevOps to add the following process blades: People ManagementProduct ManagementPortfolio Management, Enterprise ArchitectureReuse EngineeringIT Governance , and Continuous Improvement.


Why Create a New Term?

Given our philosophies around terminology, in particular our preference for existing terminology, it is admittedly strange that we created a new term such as this.  Our thinking was that we wanted to get across the idea that a blade could be updated or even replaced, just like a server blade in your operational infrastructure.  As the situation that a team faces evolves, it should be possible for the team to update their configuration of a process blade, or even replace it entirely, with little or no impact to the teams around them.  Hence, a process blade is the process equivalent of a server blade.

One Company, 800+ Disciplined Agile Teams and Counting

Reached the peak

In September 2016 InfoQ published an interview, Benefits of Agile Transformation at Barclays, with Jonathon Smart and Ian Dugmore of Barclays in the UK.  The interview summarizes the experiences of adopting Disciplined Agile (DA) strategies within Barclays.  Some of the key points made in the interview include:

  • Barclays is a large financial institution with over 130,000 employees that has been in operation for over 325 years
  • Barclays is taking a holistic approach to their agile transformation, it is not just a technology thing, linking up their various “islands of agility” to reduce the impedance mismatch between them
  • Barclays has the equivalent of over 800 agile teams that have adopted DA approaches in progress
  • They considered SAFe, LeSS and DA and settled on DA as it is not a “one-size fits all” approach
  • They needed to change both their funding and measurement strategies
  • Results include: A 300% increase in throughput (note: measured in terms of story delivery); 50% reduction in code complexity; test code coverage increase by 50%; More than half of teams are deploying into production at least monthly; Improved team happiness/morale; Improved business outcomes such as quicker time to market

The source article is definitely a very interesting read.  Scott Ambler + Associates has worked with Barclays from the beginning of their transformation and we work with many other organizations around the world to do the same.