Why Adopt a Hybrid Agile Approach?

If you are curious about hybrid agile, it may be helpful to examine a few instances where you might want to consider a hybrid approach. The first is hybrid agile as a stepping stone to true agile. The second is hybrid agile in environments that demand additional rigor or controls. 

Hybrid Agile Approach

  1. Hybrid – A Stepping Stone to Agile
  2. Environments Requiring Additional Rigor or Controls
  3. A Reason for Hybrid Agile

Hybrid – A Stepping Stone to Agile

Making the shift from a traditional waterfall approach to agile can be a large adjustment for some organizations. One school of thought is to just commit to it.  Adopt agile approaches whole scale and abandon your old way of working in a burn-the-boats style of never going back. This is simple to explain and easier to achieve when there is top down support for the adoption of agile.

However, when the desire to adopt agile is bottom-up or department based it may not be possible to fully abandon the old way of working. Some interface points to other departments might need to be maintained. Also, reporting or governance frameworks outside our sphere of influence may still be needed. In these cases, a Hybrid Agile or “Agile + Traditional Stuff” might be required. 

Many organizations have been successful in adopting agile approaches in an iterative and incremental fashion. In fact, Kanban suggests “start with what you do now.”  Then, “agree to pursue incremental, evolutionary change” that “respects the current process, roles, responsibilities & titles”. Begin by using the core properties of Kanban.  This includes visualizing the workflow, limiting the work in progress, managing flow and improving collaboratively. 

Using this approach, during the transition period from traditional methods to Kanban or agile methods, organizations use a hybrid approach as a stepping stone to their end state. 

Environments Requiring Additional Rigor or Controls

Some highly regulated environments like pharmaceutical or aerospace demand additional rigor and validation before allowing products to market. This is a good thing, it reduces the likelihood of shoddy or poorly tested services causing injury or death. 

These safety critical projects typically need to demonstrate traceability from requirements through completed designs and then successful testing. The idea being this audit trail of documentation helps ensure due diligence and proper care has been taken in the design, build and testing portions of the lifecycle to assure quality. 

By default, Agile approaches take a lightweight approach towards documentation. They prefer face-to-face communication where possible over documentation.  This approach gets questions answered quicker and conveys more information such as enthusiasm, confusion or conflict. 

When describing documentation on agile projects, the maxim “just enough, just in time, and sometimes just because” is sometimes used. It summarizes the guidelines to employ the minimum amount of documentation, when required (to avoid waste due to changes).  In fact, sometimes it is easier to provide the documentation than argue about it.

The challenge for safety critical projects is that “just enough” can be a heck of a lot. Plus, once produced, we cannot continue changing things and enhancing the solution because that would trigger a new round of testing and documentation. So, to avoid these issues, teams in safety critical environments often wrap the core agile development process in a more traditional wrapper. 

The start and end points of their projects are traditional. It provides the rigorous vendor selection, planning activities and the documentation needed for acceptance and approval for use. However, in the middle they use agile approaches to iterate quickly on building their product or service. It provides the benefits of early feedback, risk reduction and learning as they go. During execution they also wrap the process with additional governance and supporting activities.Agile Approaches in Highly Regulated Environments

This is an example of hybrid agile in the form of encapsulation. The agile component is encapsulated in a wrapper of more traditional operation. If you operate in a highly regulated environment it allows the benefits of agile to be used while still satisfying regulatory controls. There is a price for adding the extra processes, but those activities would have to be done in that safety critical environment anyway. 

A Reason for Hybrid Agile

There are many reasons why a pure agile approach may not be right for your organization, right now. Hybrid approaches need not be diluted versions of agile or crutch solutions if designed properly. Instead, they offer a strategy and roadmap for continued evolution. They may also satisfy market requirements better than their pure agile counterparts.  If you want to learn more, consider a Hybrid Agile eLearning course  or a virtual instructor led Hybird Agile course from RMC and earn PDU credit. 

Cate Curry
Latest posts by Cate Curry (see all)