BiModal IT Process?

In today’s IT organisations there is a drive to adopt Agile Development processes; as I've mentioned in other posts and Blogs, this is all very well for the nimble, technology companies who live and breathe software development with little rigor required around their Quality Assurance – not to say that technology companies don’t need rigor, but they may not need the stringent quality gates that, say, a financial services organization would need.

New IT strategies are being theorized about how IT organisations can support the adoption of Agile Development while maintaining the rigorous processes required for Quality Assurance – in the “Enterprise DevOps” context, I also refer to this discipline as “DevQops”, the adoption of Continuous Testing (for Continuous Validation) that sits between Continuous Integration and Continuous Delivery, another barrier for the larger organization that has to enforce rigorous Quality Assurance.

These new theories explore the concepts of “Bi-Modal IT”, meaning that IT organisations should not just consider the business requirements of any given software project, but how this project should be delivered, “Is it going to be Agile or Waterfall?” IT teams are facing this limitation since there seems little to support Agile Development methods alongside ITIL, and other, best practices. The question I hear being asked by my clients more often is, ”How do I apply Agile Development without missing out on the structure and formalities of best practices, such as ITIL?”

Essentially, I believe the objective of Bi-Modal IT is to define two definitive tracks for software change and delivery, either Agile or Waterfall. However, I still believe this fails to address the assurance of quality based on the complexities of today’s IT systems, again, more specifically within the realm of financial services.

If, for example, a project is deemed to be Agile, does this mean that it should by-pass the quality gates set for Waterfall? Of course not. So, how does an organization simultaneously support different methods?

Before attempting to elaborate on a solution, one has to consider the root causes behind why it is believed that Bi-Modal IT is required. Simply put, most clients I work with cannot support both methods simultaneously because they lack maturity and capability around their Software Development processes and tooling. This incapability and immaturity restricts one’s ability to concurrently develop tactical changes (agile) – aesthetics, simple feature changes and low impact Support changes, for example – and more complex system changes that rely on detailed planning, scoping and specifications (prescriptive).

An organisation’s inability to simultaneously manage tactical change and prescriptive change can usually be attributed to the specific tooling and processes adopted by the developers. In recent years, as Agile methods have become popular, the impetus for structured Application Life-cycle Management (ALM) tooling has declined, which is rather ironic when you consider the increased ALM dependencies.

I believe this trend can be recognized by the way in which large-scale development teams have adopted open source, or free, tooling to manage their software development processes, for example; SubVersion, GIT and CVS. Ironically, even though these organisations adopt these source code control tools, they simulate the concept of a life-cycle through error-prone “Branch & Merge” strategies, highlighting the need for an ALM solution is clear yet the approach is obviously flawed.

Source code control tools inherently build in constraints that do not enable the effective management and re-prioritisation of change, and this problem is further compounded when attempting to apply this to both an Agile and a Prescriptive development method simultaneously.

The ideal solution would be to enable software and system changes – both prescribed and agile – to converge into a single process; I call this the “Bi-Modal Convergent Development Life-cycle”, or “Bivergent”.

The Bivergent model enables the fluidity of agile yet supports the rigors of prescriptive; through the implementation of Continuous Integration, Continuous Test and Continuous Delivery automation, large-scale IT organisations can leverage all of the benefits of Agile without losing the benefits of IT governance and best practice.