Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
In writing the book on DAD, Scott and I focused on a describing a pragmatic approach to being agile. An alternative approach could have been to describe “how to do agile” planning, modeling, requirements, etc. which could have come off as dogmatic and prescriptive. Or we could have shown all the agile practices described elsewhere, and said “you choose”. Other methods that have tried to provide guidance to every possible situation have in the past proven to be overwhelming and difficult to adapt.
Instead, based on what really happens in enterprises that adopt agile we chose to describe different strategies to achieve your solution goals and where different, sometimes non-agile practices might make sense. Sometimes there are situations that require us to use strategies that are not particularly agile. How do we adapt to be as agile as we can to achieve our goals while dealing with enterprise realities such as compliance and vendor management?
We do have opinions about which strategy is most effective in certain situations and we realize that your approach might need to be different depending on your circumstances. While we do suggest a path to maximizing your agility capability, DAD provides a flexible framework to adopt agile practices accordingly. In this way we feel that our book is different than the other agile books out there that may paint an idealistic picture that is not realistic for your organization or project. As an example, here is an excerpt from the upcoming book where we describe various strategies for choosing a your release cadences:
—
Table 10-5. Comparing production release cadences.
| Strategy | Potential Advantages | Potential Disadvantages | Considerations |
| More than annual | Appropriate for low priority systems or for high-risk deployments (e.g. embedded software) | Very risky
Requires internal releases to obtain some feedback |
This is common for infrastructure systems, such as a database or transaction managers, that have many other systems highly dependent upon them |
| Annual | Appropriate for low-to-medium priority systems or medium-to-high risk deployments | Requires internal releases | Don’t include the year in the name of the release, for example ProductX 2014, if the ongoing release cadence is going to change. |
| Bi-annual | Good starting point for agile teams because it motivates adoption of disciplined strategies | Can be difficult for stakeholders who are used to less frequent releases | |
| Quarterly | Enables simpler requirements management practices due to lower impact of a feature moving to the next release | Requires disciplined continuous integration (CI) strategies | CI refers to the practice of regularly, at least daily, building/compiling and regression testing your solution. CI is described in Chapter 15.This is a major milestone for teams moving towards an “advanced” lean-agile strategy as it motivates greater discipline. |
| Monthly | Enables teams to respond to quickly changing environments. | Requires disciplined continuous deployment (CD) strategies | CD is CI plus automated deployment of working builds to non-development environments/sandboxes |
| Weekly | Enables quicker response to stakeholders | – | Effective for high-use systems, particularly e-commerce or BI/reporting systems |
| Daily | Enables teams to adapt very quickly | Requires extensive deployment automationRequires high discipline to maintain quality | |
| Variable | 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. | Stakeholders, or their representatives, need to be a good judge of MMR.Politics can hamper this decision point. | You should put an upper limit on the acceptable time between releasesThis decision point is captured in the DAD lifecycle by the “sufficient functionality” milestoneThe less expensive the transition effort the easier it is to make this decision |
We recommend aiming for a release cadence of no more than six months, with a goal of getting it down to three months or shorter. We recognize that organizations new to agile may find the concept of releasing every six months difficult at first, particularly when length release processes during the Transition phase still exist. Strive to keep your Inception phase to two weeks or less, which can be hard if key stakeholders are unavailable or your organization still has lengthy milestone review processes. During Construction, we recommend aiming for iterations of two weeks for co-located teams and of no more than four weeks DAD teams working at scale. We also recommend that construction iteration lengths remain the same, although if you’re a team new to agile that you should consider longer iterations at first and then as you gain experience with agile techniques and learn to collaborate effectively that you shorten your iterations over time. We prefer having an internal release at the end of each iteration, although once you’ve fully adopted the practice of continuous deployment (CD) we recommend making your builds available to others whenever they’re successful. Finally, strive to keep the Transition phase to be less than or equal to the length of a single Construction iteration, ideally shorter.
—–
We hope that you find that this approach to covering DAD gives you practical, actionable guidance for adapting agile to your organization.
Posted
by Mark Lines
on: February 04, 2012 01:58 PM |
Permalink