2.5 The Enterprise-Wide Context
2.5.3 Disciplined Agile Delivery (DAD)
collaboration comprises of an integration of Dev and Ops functions from design through to the development process up until production and support for the system. This collaborative strategy blurs the traditional distinction between development, quality assurance and operations. It also has implication from an organisational culture perspective because it requires the various stakeholders to work in an interactive manner to facilitate the building, testing and release of software in a quick and reliable manner.
The DevOps strategy as outlined in Mueller (2016) requires that once a development team declares that a specific version of a system is ready to be deployed, the assumption is made that any further development will be suspended while the application is deployed into production. At this juncture, the application is subjected to ‘live’ testing and intensive scrutiny whilst in the ‘live’ environment.
The DevOps practice requires that developers are allocated the task of observing the progress and analysing systems errors so that remedial action can be taken. In this way an iterative relationship is maintained between the developers of the system and the operators of the system. This iterative arrangement enables quicker releases and the implementation of quicker changes that may be required by the operators who enjoy the benefit of having immediate access to the developers.
and Lines proposed a modified version of Scrum in 2012. The modified version of Scrum is referred to as the Disciplined Agile Delivery (DAD) approach (see Ambler and Lines (2012)). DAD is an extension of agile methodology (Scrum in particular) where the focus is on ensuring that the solution provided by agile teams is successful at an enterprise level. In order to achieve this, Ambler and Lines leveraged the best practices from Scrum, XP and the Unified Process to propose a methodology that shifts the focus to application delivery, operation and support from an enterprise/organisational context. The preceding narrative is echoed in the comment by Ambler and Lines (2012, p. 9) that:
Core agile methods such as Scrum and XP are typically project focused, whereas DAD explicitly strives to both leverage and enhance the organizational ecosystem in which a team operates.
Essentially, the DAD methodology re-aligns the focus from producing software to providing an IT solution that resonates with business, technical and the cultural constraints in which that solution operates. An overview of the DAD methodology is provided in Figure 2.13.
Figure 2.13: The Disciplined Agile Delivery (DAD) lifecycle model (Ambler &
Lines, 2012, p. 12)
The underlying philosophy of the DAD methodology is to provide sufficient guidance, but not to be overly prescriptive. The Inception phase as illustrated in Figure 2.13 may be seen as an ‘envisioning’ phase where the system’s evolution is mapped out to the developers as well as the stakeholders. A significant activity in the Inception phase is to set up a development environment that facilitates quick
Inception
(One or more short iterations that entail requirements, modelling, release planning and
acquiring stakeholder consensus)
Construction (Identify highest priority work
items; Many short iterations (Scrum based) to service iteration backlog in order to
produce a potentially consumable solution aftereach iteration; demonstrate solution
to stakeholders; obtain feedback)
Transition
(Release solution into production; operate and support solution whilst in production mode enabling evolution into final product)
and easy release of the application into production. Also, an initial plan of the application release schedule is drawn up together with an architectural/design model that provides a logical view of the application so that there is an alignment between the objectives of the application and the business/organisational objectives. The activities that have been listed are regarded as goals of the Inception phase and there no prescribed way of achieving these goals. The rationale for this approach is that the development teams are at liberty to customise the development processes in order to address the context of the situation in which the application is being developed
The goals of the Construction phase are to produce a ‘demonstrably consumable solution’ that addresses stakeholder’s requirements and has an
‘organisational fit’. This is achieved by employing techniques such as continuous integration, developer regression testing and test-first development. The actual development is executed by implementing all of the ceremonies intrinsic to the Scrum methodology. The main point of departure from traditional Scrum is that the focus is on ensuring that the solution is compatible with the existing architectural framework that underpins the organisation’s IT infrastructure.
According to Ambler and Lines (2013), the lack of enterprise-wide focus is one of the reasons that popular agile methodologies such as Scrum were not fully successful. In an article titled “Going Beyond Scrum”, Ambler and Lines make the point that agile teams do not work in isolation and application solutions produced by Scrum teams should be regression tested so that it is compatible with existing organisational processes, is compatible with the data infrastructure and compliant with security and usability constraints that have been established as an organisational norm (referred to as the organisational ecosystem by Ambler and Lines). In order to develop solutions that have an ‘enterprise-wide’ awareness, Ambler and Lines make several suggestions that collectively form the essence of the DAD framework that they propose as an extension/supplement to Scrum methodology. The underlying strategy of DAD is to arguably ensure that the Scrum team works closely with enterprise professionals. The reference to enterprise professionals is where the organisational linkage is established.
According to Ambler and Lines (2013), ‘enterprise professionals’ is a reference to personnel in the organisation who ensure that business processing protocols are maintained and upheld by new and emerging IT systems. These include IT based personnel who oversee aspects such as IT governance database design and administration, IT security and user interface design and quality control and testing. The close collaboration with enterprise professionals and operations staff is representative of a DevOps philosophy that has been “…baked right into DAD”
(Ambler & Lines, 2013, p. 11).
The goal of the Transition Phase of DAD is to ensure that the system’s stakeholders have worked with the new application and are delighted by its’
performance and conformance within the organisational ecosystem. Ambler and Lines make a claim that the DAD framework ensures that the Transition Phase is a smooth one. This is in contrast to the current, traditional agile situation where transition and deployment of newly developed systems is where the major bottleneck to agile application delivery is experienced (Ambler & Lines, 2016). The smooth passage for the Transition Phase is facilitated and enhanced at the Construction Phase where there is greater stakeholder involvement from a training and consultation perspective. This strategy has a strong resonance with the DevOps approach.