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 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 (see Chapter 18 for a discussion of how to shorten this process).  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.

About these ads