Strengths and Best Practices
Agile-Scrum’s strengths include adaptability, flexibility, improved team structures, and an ability to incorporate changing requirements, leading to improved quality, and Business-IT collaboration (Inayat et al 2014). Chandrasekara (2017) and other case researchers (Chandra 2015, Ashisdeep et al 2016), in exploratory SLRs (systematic literature reviews), found that management benefits included process improvements, early error identification, reduced risk of project failure, and improved team work.
Platform choice is also relevant with Butt (2016) for example, in an extensive-descriptive SLR concluding that Agile best suited the needs of Cloud deployments (vs Waterfall), given Agile’s iterative flexibility. Jorgensen (2018) in a survey of 101 Norwegian firms discovered that Agile-Scrum was better managed on medium and larger-sized projects than within smaller projects when processes were changed to match iterative delivery. This contrasts with Uludag et al (2018) using a SLR along with critical surveys of large projects, including offshore-onshore delivery models, who describe Agile as being manageable for smaller projects, but presented management issues on Enterprise projects. Table 1 below, outlines key factors of management success in deploying Agile.
Key Success Factors
Academic and secular case studies indicate that ‘success factors’ are firm specific (Vallon et al, 2018). For example, Microsoft which has 4000 developers grouped in Agile teams of 10-12, with each team ‘owning’ a product; will implement Agile and DevOps differently, then Google which has a similar size of developers organised and using Agile somewhat differently (Denning, 2018).
Table 1: KSFs
| Category | Comments |
| Management Support | Visible support including financial Active Change management (Denning, 2018) |
| Commitment | Long-term outlook Cultural change management Proper budgeting for Agile projects (usually a portfolio for ‘innovation’ is created, funded) (Marnewick & Langerman, 2018) |
| Adapt | Agile properly understood Team is the locus of delivery, not project management Standard processes, framework implemented (Jorgensen, 2018) |
| Training | Silos and bureaucracy being changed Old processes changed (Denning, 2018) |
| Requirements | Requirements gathering improved Documentation and patterns used User stories & other Scrum artefacts (Le, Dang, Nguyen, 2018) |
| Team | Teams are cross functional Using automation Incremental delivery Locus of power not with PMs (Hoda & Murugesan 2016) |
| Communication Transparency | Successes communicated Purpose of agile constantly reinforced SMEs run delivery, documentation and delivery, not project management (Moran, 2015) |
| SMART (specific, measured, appropriate, relevant, time-bound) | Small incremental deployments, fast-failure, SMART means that the project is clear and meaningful Project is not vague, or open to interpretations (Niazi, et al. 2016, O’Sheedy, 2012, Read, 2018) |
It is the author’s opinion based on real Agile projects, that SMART projects have more of a chance of success, including having a business owner on the Agile team, than vague projects which lack a business owner. Project Management do not manage Agile teams and have no power within the Agile-Scrum process or a SMART process.
Commitment
The above categories are not ordered by importance, but by their mention in the case study reviews. For example, the proper management of Agile-Scrum and a real commitment to changing the culture, organization and delivery methods are therefore vital to get right. Chikhale and Mansouri in a detailed case study of Agile-Scrum within Apple Inc., cited management governance as the key determinant of enterprise Agile success.
GDAD (geographically distributed agile development)
Stettina & Schoemaker (2018) in surveys of 10 large European firms using Agile on larger projects, found that Agile can scale geographically and horizontally within VLEs, if there is a management framework to connect the Agile project with the domain process flow, business logic and business strategy. Rademacher et al (2018) proposed using Agile Enterprise management models based on Evans (2003) and Brugge et al (2004), for Enterprise and distributed (offshore) delivery. Similarly, Ashraf et al (2018) in an exploratory interpretavist SLR study found that scaling was accomplished through an Enterprise Scrum management framework such as SAFe. Maturity models are also applied to assess organisational-managerial fitness to both use and scale Scrum (Marnewick & Langerman, 2018).
Real world case studies are clear that the more distributed an Agile team is, the less likely that the Agile project will succeed. Co-location is a key success factor with Agile-Scrum.
In the context of requirements and design, enterprise distributed Agile-Scrum projects have issues with communication and clarity of requirements (Alqudah & Rozilawati 2016). Organisationally, Bjornsson (2018) in a critical study of a large enterprise with 12 Scrum teams, found that Agile could only scale with distributed teams, if management enforced frequent communications within, and between project teams. Karvonen et al (2018) in an in-depth critical review of a large enterprise using Agile extensively, found that management of communications including requirements elucidation and fulfillment, leading to a transformed culture, as vital. Establishing common technical and business languages within communication flows and between members of teams, was also deemed important to allow scalability (Le & Nguyen, 2018; Hansson & Zhao, 2014).
Requirements Engineering
Real World case examples also indicate that managing enterprise technical issues are also prevalent and include business requirements not being properly reflected in coding solutions. This is particularly relevant when many offshore teams are the primary development teams yet fail to fully understand domain logic and business requirements (Cooper et al 2017). Management frameworks to translate business requirements into code was identified as important by Steinegger et al (2017), in a detailed review of 6 case studies in building large Web Applications. Mekni et al (2018) propose a model starting with managing end user requirements to map the top-level design with coding detail. Chapman (2017) in a case study of Altran UK and its Enterprise projects, identified that management of Agile should focus first on functional requirements, and later non-functional requirements to aid mapping business requirements into proper coding through iterative cycles (eg. High availability).
PM Frameworks
Project management frameworks linked with domain design was deemed important in Scrum usability and scalability in a SLR by Crisan et al (2015). This is consistent with Anwer et al’s (2017) exploratory SLR and case study analysis, which compared the management of feature driven Agile methods and concluded that firms should combine these with non-Agile management practices to allow scalability. Bass (2015) in a critical survey-based review of 8 firms with very large offshore projects using Agile, concluded that scaling the Business Owner role (called the Product Owner in Scrum), across projects within a domain as important to have a consistent implementation of Agile (Bass, 2015).
The author does not recommend mixing and matching Agile-Scrum with traditional frameworks. This leads to confusion and a lack of clarity and focus. If the intent of the firm is to ‘transform’ IT and align IT with the business, then the firm needs to commit itself to Agile-Scrum, understand what that means, and modify if necessary, the Agile-Scrum approach to fit the cultural, and perhaps the organizational norms of the firm.
==END