2.5 The Enterprise-Wide Context
2.5.6 The Scaled Agile Framework (SAFe)
DAD and DevOps are representative of methodologies that address the weakness of agile methodology to scale to an organisational level. These initiatives are further extended by SAFe where the objective is to provide guidance on the
and Dingsoyr (2008) point out, the implementation of agile methodology in larger organisations is challenging from a co-ordination and cultural perspective. Co- ordination becomes an issue when there is a greater number of stakeholders involved and multiple teams work on a single project. There is also the dimension of organisational culture where there is a natural resistance to change from a behavioural perspective. In larger organisations, this situation tends to get exacerbated and successful agile adoption requires a change in the entire organisational culture (Chandra Misra et al., 2010).
In an attempt to address the issue of agile scalability from an enterprise- wide perspective Leffingwell (2007) introduced the methodology of SAFe that is underpinned by 4 different frameworks each configured to handle specific organisation environments. An overview of the SAFe frameworks (see Scaled_Agile (2017)) is provided for reference.
Essential SAFe – Consists of a new structure named the Agile Release Train (ART) that functions at the lower software development level (called the SAFe Team level) and at a higher business and infrastructure level (called the SAFe Program level).
At the team level, SAFe provides guidance on the coding part of system development. At the program level, SAFe provides guidance on the operations activities that enable business value. The core
“ingredient” to the Essential SAFe is the ART that comprises of a cross functional team that delivers the development and operations value streams;
Portfolio SAFe – An enterprise-wide plan that makes use of value streams (a term used to describe an enterprise-wide strategy to develop products, services or software systems) that provide value to the customer. The Portfolio SAFe is aligned to the organisational imperative to identify strategies that enable product differentiation in the marketplace and to ensure competitive advantage. Leffingwell (2010, p. 43) refers to these strategies as “a set of investment themes”. These investment themes are achieved in the form of
“epics” which is a term used as a high level descriptor of customer need and translates to a software development initiative. These epics are maintained in a portfolio backlog. One of the key role players is the Enterprise Architect, a person (or group of persons) who manages the portfolio backlog and works across programs (from the Essential SAFe) to provide technical direction that can arguably ensure that the outcomes for the portfolio are optimally achieved.
The portfolio SAFe is a scaled up, business version of Agile Software Development Methodology;
Large Solution SAFe – used for developing complex enterprise wide solutions; typically used for government and military systems and require multiple ARTs;
Full SAFe–a SAFe configuration that is the most comprehensive version of the framework and provides support for organisations that build and maintain large, integrated solutions and require extensive collaboration across the organisation to include stakeholders that function at the SAFe Team, Program, Large Solution and Portfolio levels of the framework.
SAFe seen as the “Big Picture” Approach
SAFe provides a framework to guide the software process from a team and organisational perspective thereby reducing the divide between the business imperative and software development at the agile team level (Vaidya, 2014).
Leffingwell (2010) calls this the “big picture” (pp. 32-33) approach to software development that has the objectives of providing an enabling environment for the achievement of business value as well as ensuring that there is sufficient collaboration between the various “pods of agile teams” (p. 35) that traditionally function in a disparate manner. This holistic approach to software development where agile development is contextualised from an organisational perspective and not just a software development team perspective, is highly endorsed by Fitzgerald and Stol (2015) as well as (Vaidya, 2014). Fitzgerald and Stol (2017) suggest that
and operations. The collaborative environment espoused by SAFe also reduces the
“architectural decay” or “technical debt” (p. 9) incurred by many agile teams when there is no effort made to faciltate compliance of the evolving system with organsational architectural/infrastructure requirements. The imperative to ensure that deliberations regarding the scalability of software development methodology is given high priority is also highlighted by Boehm (2011) who provides a scalable version of the Spiral methodology for software development that is named the Incremental Commitment Spiral Model (ICSM). The main difference between the ICSM and the original Spiral model is the inclusion of and Operations and Production phase. The ICMS has a similar orientation to the Essential SAFe.
The Alignment of SAFe to Agility Principles
Theoretically, the SAFe framework embraces agile principles to provide an all-encompassing solution to the problem of the lack of scalability of agile methodology to an organisational level. Dikert et al. (2016) do however caution about the lack of academic research to verify the long term viability of comprehensive frameworks for software development such as SAFe. The main concern expressed is that the adoption of organisational-wide frameworks require a major change in the organisational norms when it comes to software development.
Agile, SAFe and Organisational Culture
One of the challenges faced in the transition to basic agile development was the issue of organisational culture. The adoption of agile methodology requires a shift in the organisational culture that is not easily achieved. A further imposition of agile methodology at the organisational and operational level (as espoused by SAFe) makes this transition a lot more difficult to achieve (Fitzgerald & Stol, 2017) resulting in only a lightweight adoption of SAFe at the Essential SAFe level (Vaidya, 2014). As Dikert et al. (2016) point out, a formal intervention to achieve agile scalability will require comprehensive staff training and support from senior management. The greatest obstacle to enable a framework such as SAFe is the ‘top down’ management style that will have to prevail to ensure that there is sufficient
cooperation at all levels of the organisation to enhance the adoption of such a framework. During the transition from an ‘old way of working’ to the new framework, any problem encountered has the potential to be magnified because of people’s general resistance to change and preferring to revert “…to the ways they know” (Dikert et al., 2016, p. 97).
Organisation-Wide Agility
A further issue that compromises the attainment of organisation-wide agility is that of communication and coordination. In a multi-case study by Eklund et al. (2014) that spanned the banking, telecommunications and insurance sectors, it was found that scaling agile teams to an organisational level was not easily achieved. One of the main reasons for this phenomenon was the lack of coordination between Scrum teams that were co-dependent17 resulting in a disjointed development effort. In order to alleviate this situation there was a need to appoint an oversight manager who is able to coordinate the activities between the various teams. Conceptually this adds another layer of management control thereby exacerbating the complexity of the development process and also compromising the agile principle of ‘simplicity’, prompting Thomas (2015), one of the co-authors of the Agile Manifesto to suggest that SAFe is not agile.
The discourse on software development methodology and the scalability of the methodology to an organisational level converges to a viewpoint that the organisational culture and social factors are pivotal enablers in the adoption of a software development methodology. The intertwining of software development methodology with the social realm necessitates an incursion into the essence of organisational culture. This ‘digression’ is perceived as crucial so that any empirical study to understand the adoption of software development methodology is cognisant of the influence of organsational culture (Sheffield & Lemétayer, 2013).