Considering various strategies for addressing your goals
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 hope that you find that this approach to covering DAD gives you practical, actionable guidance for adapting agile to your organization.