It is hard to scale Agile for large-scale project probably because Agile methods were originally designed for small and single-team projects (Boehm and Turner, 2005). With the increase in the size of an organization, the difficulty of introducing agile methodology increases (Dybå and Dingsøyr, 2008).
One main distinction between the small and large scale projects is that the latter depends more amongst the projects and the teams. Due to this arises the requirement of formally documenting the analysis and design, which is not the element of agile methods (Lindvall et al., 2004). Additionally, the communication between the development team and other organizational unit is essential, which is not the property of agile methods. For example, the HR unit might put a restriction of strict role specification in the projects (Boehm and Turner, 2005) or the change control board might require constant refactoring (Lindvall et al., 2004). All the organizational units that are affected by adopting agile methods should be aware and referred first and the agile process must be incorporated based on their requirements.
In addition to inter-team coordination, development teams must interact with other organizational units, which are often non-agile in nature. For instance, human resources unit may demand individuals to have strictly specified roles in projects (, or a change control board may inhibit the use of continuous integration or refactoring (Lindvall et al., 2004). All units affected by the agile transformation need to be informed and consulted, and the agile process must be adjusted according to their needs (Lindvall et al., 2004, Boehm and Turner, 2005). Agile methodology also influences the way business functions. Before adapting to agile methods, an organization would also need to have awareness of shifting from life-cycle models to iterative models and this change needs a variation in both the attitude and cultural thinking. Also the emphasis from long term goals would require changing to short term planning as Agile methods focus on productive short term goals. This might need some planning as usually customer relationships are based on long term objective and planning. This change would also require to create awareness amongst the stakeholders Boehm and Turner, 2005.
Dikert et al. (2016) from their research depicted in the table below the methodologies used by the big companies.
Case | Paper(s) | Company | Business area | SWorgsize | Initial state | Agile methods | Trans-from start | Relevance |
C02 | P03 | Amazon.com | Small autonomic teams | Scrum | 2004 | 5 | ||
C03 | P04 | BEKK consulting | IT- and management consulting | 160 | Waterfall | Unified Process | 2003 | 3 |
C04 | P05, P17 | BMC Software | Distributed Systems Management business unit | 300 | Waterfall, traditional, dispersed | Scrum | 2004 | 5, 5 |
C05 | P06, P09 | Yahoo! | Online services | 150 teams | Waterfall (named PDP), gated, city-states | Scrum, Lean | 2005 | 4, 5 |
C06 | P07, P52 | Nokia Siemens Networks | 500 | RAD, Scrum | 2007 | 3, 2 | ||
C07 | P08 | ABC Bank | Banking | 300 | Scrum, UP, XP. Custom delivery | 3 | ||
C08 | P10 | Yahoo! Music | Media player for consumer | Enforced top-down, heavy- weight, BDUF, waterfall | Scrum | 2006 | 4 | |
C09 | P11 | Unisys Cloud Engineering | Waterfall | Scrum | 2010 | 5 | ||
C10 | P12 | BBC, iPlayer | Media | 10 teams | Independent processes, Heavy practices | Scrum | 4 | |
C11 | P13, P15, P16, P28, P33 | Salesforce.com | Online services,SaaS CRM software | 30 teams | Loose waterfall-based process | Scrum, XP, Lean, ADM | 2006 | 2, 2, 5, 2, 2 |
C12 | P14 | MyBoeingFleet.com | Extranet website | CMMI,Macroscope, gate-based | Scrum | 2007 | 3 | |
C13 | P18 | Ericsson Netherlands | Telecommunications | 300 | Scrum, XP, Lean | 2007 | 4 | |
C14 | P19 | Citrix Online | Conferencing and screen sharing software | 44 teams | RUP waterfall | Scrum | 2007 | 1 |
C15 | P20, P21 | Anonymous | Government | 50 | Waterfall | Scrum | 2010 | 3, 3 |
C16 | P22 | Ericsson R&D Finland | Telecommunications | 400 | Traditional, functional, silo-based | Scrum,Kanban, Lean | 2 | |
C17 | P23, P32 | British Telecom | Telecommunications | 14000 | Old fashioned process- driven; Waterfall | Mentioning of Scrum, XP | 2004 | 3, 2 |
C18 | P24 | SoftwarePeople | CMMI level 3 | Scrum | 2006 | 4 | ||
C20 | P26 | Nokia | Telecommunications | Waterfall, some Scrum on team level | Scrum | 2007 | 2 | |
C21 | P27 | Anonymous | Healthcare | 300 | Waterfall | Scrum, XP | 2005 | 3 |
C22 | P29 | Microsoft IT | IT services | 9 teams | Waterfall and PMI methodologies | Scrum | 2006 | 3 |
C23 | P30 | Healthwise | Healthcare, DSS system | 200 | Expanding organization | Scrum, Lean | 2004 | 3 |
C24 | P31 | Borland | 300 | Scrum | 2006 | 4 | ||
C25 | P34 | Siemens Medical Solutions USA | Health services | 300 | Scrum | 4 | ||
C27 | P36 | Anonymous | Financial services | 100 | Traditional, phase-based approach | XP | 2001 | 4 |
C28 | P37, P38 | Gale | Online services | 6 teams | Waterfall, overall unclear | 2009 | 3, 3 | |
C29 | P39 (T1) | Anonymous | Online services | 50 | Waterfall | Scrum | 3 | |
C30 | P39 (T2) | Anonymous | Banking | 9 teams | Scrum | 3 | ||
C31 | P40 | Quintiles Trans- national Corp | Homegrownwaterfall, CMMI, silos | Scrum | 3 | |||
C32 | P41 | Nyx | 270 | Traditional waterfall-style (RUP) | Scrum | 2007 | 4 | |
C33 | P43 | VeriSign Enterprise Security | Information security | 50 | Scrum | 2006 | 4 | |
C34 | P44 | Primavera Systems | Enterprise project portfolio management | 90 | Waterfall | Scrum | 2003 | 3 |
C35 | P45 | SAP AG | Enterprise applications | 18000 | Waterfall-like process | Scrum, Lean | 2006 | 4 |
C36 | P46 | KeyCorp | Financial | 1500 | Waterfall, command-and-control | Scrum | 2005 | 5 |
C37 | P47 | Capital One | Scrum | 2004 | 3 | |||
C38 | P48 | Cisco Voice Technology Group | Telecommunications | 1500 | Waterfall | Scrum | 4 | |
C39 | P49 | QwestCommunications | Telecommunications | 5000 | Rigorous, collaborative in one unit, CMM | XP | 2002 | 5 |
C40 | P50 | Pegasystems | Business process management | 200 | Traditional project management | Scrum | 2009 | 3 |
Table 8. Case studies.
Case | Paper(s) | Company | Business area | SWorgsize | Initial state | Agile methods | Transfromstart | Relevance |
C01 | P01, P02 | Anonymous, HQ in the UK | Telecommunications | 7500 | XP | 2005 | 3 | |
C16 | P42 | Ericsson R&D Finland | Telecommunications | 400 | Traditional, silo-based | Lean, Scrum | 2009 | 2 |
C19 | P25 | Nokia Siemens Networks | Telecommunications | 150 | Plan-driven, waterfall | Practices (XP), Scrum | 2010 | 1 |
C26 | P35 | Anonymous | 50 | Waterfall | XP | 2 | ||
C41 | P51 (C1) | Anonymous | Messaging services | 100 | Scrum | 2008 | 2 | |
C42 | P51 (C2) | Anonymous | Facility management | 300 | Prince2, Waterfall | Scrum | 2004 | 2 |
Dikert et al. (2016) came up with the following challenges that adapting of agile methods bring in.
Challenge type | Primary sources | Case organizations | # of cases |
Change resistance 16 (38%) | |||
General resistance to change | P14, P18, P22, P44, P45 | C12, C13, C16, C34, C35 | 5 (12%) |
Skepticism towards the new way of working | P5, P8, P9, P18, P29, P36, P46 | C4, C5, C7, C13, C22, C27, S36 | 7 (17%) |
Top down mandate creates resistance | P2, P12, P37, P49 | C1, C10, C28, C39 | 4 (10%) |
Management unwilling to change | P2, P3, P6, P49 | C1, C2, C5, C39 | 4 (10%) |
Lack of investment 13 (31%) | |||
Lack of coaching | P1, P6, P23, P45, P47, P49 | C1, C5, C17, C35, C37, C39 | 6 (14%) |
Lack of training | P11, P20, P45 | C9, C15, C35 | 3 (7%) |
Too high workload | P37, P42, P49 | C16, C28, C39 | 3 (7%) |
Old commitments kept | P11, P21 | C9, C15 | 2 (5%) |
Challenges in rearranging physical spaces | P6, P14, P29, P36, P38, P49 | C5, C11, C22, C27, C28, C39 | 6 (14%) |
Agile difficult to implement 20 (48%) | |||
Misunderstanding agile concepts | P6, P26, P37, P38, P42, P44, P45, P48, P49 | C5, C16, C20, C28, C34, C35, C38, C39 | 8 (19%) |
Lack of guidance from literature | P5, P6, P10, P13, P21, P27, P30, P45, P49 | C4, C5, C8, C11, C15, C21, C23, C35, C39 | 9 (21%) |
Agile customized poorly | P9, P29, P44, P46 | C5, C22, C34, C36 | 4 (10%) |
Reverting to the old way of working | P6, P11, P12, P18, P21, P38, P44, P49 | C5, C9, C10, C13, C15, C28, C34, C39 | 8 (19%) |
Excessive enthusiasm | P4, P6, P12, P20 | C3, C5, C10, C15 | 4 (10%) |
Coordination challenges in multi-team environment 13 (31%) | |||
Interfacing between teams difficult | P9, P10, P13, P17, P24, P26 | C4, C5, C8, C11, C18, C20 | 6 (14%) |
Autonomous team model challenging | P7, P13, P29, P51 | C6, C11, C22, C41 | 4 (10%) |
Global distribution challenges | P29, P45, P48 | C22, C35, C38 | 3 (7%) |
Achieving technical consistency | P5, P24, P26, P27, P50 | C4, C18, C20, C21, C40 | 5 (12%) |
Different approaches emerge in a multi-team environment 9 (21%) | |||
Interpretation of agile differs between teams | P8, P9, P38, P43, P48 | C5, C7, C28, C33, C38 | 5 (12%) |
Using old and new approaches side by side | P1, P8, P10, P26, P29 | C1, C7, C8, C20, C22 | 5 (12%) |
Hierarchical management and organizational boundaries 14 (33%) | |||
Middle managers’ role in agile unclear | P2, P11, P27, P30, P38, P49, P52 | C1, C6, C9, C21, C23, C28, C39 | 7 (17%) |
Management in waterfall mode | P3, P6, P35, P38, P45, P46 | C2, C6, C26, C28, C35, C36 | 6 (14%) |
Keeping the old bureaucracy | P20, P48 | C15, C38 | 2 (5%) |
Internal silos kept | P10, P11 | C8, C9 | 2 (5%) |
Requirements engineering challenges 16 (38%) | |||
High-level requirements management largely missing in agile | P24, P31, P39, P45, P51 | C18, C24, C29, C35, C41 | 5 (12%) |
Requirement refinement challenging | P1, P17, P33, P48 | C1, C4, C11, C38 | 4 (10%) |
Creating and estimating user stories hard | P5, P11, P27, P30, P33, P37 | C4, C9, C11, C21, C23, C28 | 6 (14%) |
Gap between long and short term planning | P9, P10, P13, P26, P31, P38 | C5, C8, C11, C20, C24, C28 | 6 (14%) |
Quality assurance challenges 6 (14%) | |||
Accommodating non-functional testing | P17, P28, P31, P48 | C4, C11, C24, C38 | 4 (10%) |
Lack of automated testing | P10, P11, P17 | C4, C8, C9 | 3 (7%) |
Requirements ambiguity affects QA | P5, P48 | C4, C38 | 2 (5%) |
Integrating non-development functions 18 (43%) | |||
Other functions unwilling to change | P1, P2, P5, P9, P10, P17, P18, P28, P31, P38, P42, P45, P46, P48, P50 | C1, C4, C5, C8, C11, C13, C16, C24, C28, C35, C36, C48, C40 | 13 (31%) |
Challenges in adjusting to incremental delivery pace | P6, P9, P10, P15, P17, P28, P46, P48, P50 | C4, C5, C8, C11, C36, C38, C40 | 7 (17%) |
Challenges in adjusting product launch activities | P31, P38 | C24, C28 | 2 (5%) |
Rewarding model not teamwork centric | P3, P6, P38, P40, P42, P49 | C2, C6, C16, C28, C31, C39 | 6 (14%) |
The following table depicts the success factors that have been reported for large-scale agile transformations (Dikert et al., 2016).
Success factors | Primary sources | Case organizations | # of cases |
Management support | 16 (38%) | ||
Ensure management support | P8, P11, P16, P18, P27, P31, P33, P36, P43, P44, P46, P47, P49 | C7, C9, C11, C13, C21, C24, C27, C33, C34, C36, C37, C39 | 12 (29%) |
Make management support visible | P9, P11, P24, P40 | C5, C9, C18, C31 | 4 (12%) |
Educate management on agile | P6, P8, P9, P11, P29, P46, P47 | C5, C7, C9, C22, C36, C37 | 6 (14) |
Commitment to change | 7 (17%) | ||
Communicate that change is non-negotiable | P11, P22, P48, P49 | C9, C16, C38, C39 | 4 (10%) |
Show strong commitment | P8, P10, P11, P43 | C7, C8, C9, C33 | 4 (10%) |
Leadership | 7 (17%) | ||
Recognize the importance of change leaders | P3, P4, P11, P16, P18, P31, P33, P42 | C2, C3, C9, C11, C13, C16, C24 | 7 (17%) |
Engage change leaders without baggage of the past | P11, P16 | C9, C11 | 2 (5%) |
Choosing and customizing the agile approach | 20 (48%) | ||
Customize the agile approach carefully | P8, P10, P11, P29, P31, P40, P41, P43, P45, P49, P51 | C7, C8, C9, C22, C24, C31, C32, C33, C35, C39, C41 | 11 (26%) |
Conform to a single approach | P8, P11, P12, P16, P32, P43 | C7, C9, C10, C11, C17, C33 | 6 (14%) |
Map to old way of working to ease adaptation | P3, P14, P16, P29, P44, P48 | C2, C11, C12, C22, C34, C38 | 6 (14%) |
Keep it simple | P5, P10, P16, P40 | C4, C8, C11, C30 | 4 (10%) |
Piloting | 14 (33%) | ||
Start with a pilot to gain acceptance | P3, P9, P14, P17, P31, P36, P38, P39, P47 | C2, C4, C5, C12, C24, C27, C28, C29, C37 | 9 (21%) |
Gather insights from a pilot | P8, P22, P27, P40, P45 | C7, C16, C21, C31, C35 | 5 (12%) |
Training and coaching | 15 (36%) | ||
Provide training on agile methods | P3, P6, P14, P16, P30, P37, P46 | C2, C5, C11, C12, C23, C28, C36 | 7 (17%) |
Coach teams as they learn by doing | P3, P6, P8, P9, P16, P17, P18, P29, P30, P33, P42, P44, P47, P48 | C2, C4, C5, C7, C11, C13, C16, C22, C23, C34, C37, C38 | 12 (29%) |
Engaging people | 9 (12%) | ||
Start with agile supporters | P6, P29, P34 | C5, C22, C25 | 3 (7%) |
Include persons with previous agile experience | P6, P10, P37 | C5, C8, C28 | 3 (7%) |
Engage everyone in the organization | P4, P6, P16, P22, P31 | C3, C5, C11, C16, C24 | 5 (12%) |
Communication and transparency | 7 (17%) | ||
Communicate the change intensively | P16, P22, P33, P40, P41, P43, P48 | C11, C16, C31, C33, C38 | 5 (12%) |
Make the change transparent | P6, P11, P16, P42, P43 | C5, C9, C11, C16, C33 | 5 (12%) |
Create and communicate positive experiences in the beginning | P6, P32, P29, P40, P42, P46 | C5, C16, C17, C22, C31, C36 | 6 (14%) |
Mindset and Alignment | 17 (40%) | ||
Concentrate on agile values | P1, P16, P42, P46, P48 | C1, C11, C16, C36, C38 | 5 (12%) |
Arrange social events | P11, P23, P27, P32, P40, P41 | C9, C17, C21, C31, C32 | 5 (12%) |
Cherish agile communities | P3, P12, P41, P42, P47 | C2, C10, C16, C32, C37 | 5 (12%) |
Align the organization | P8, P18, P31, P42, P43, P46 | C7, C13, C16, C24, C33, C36 | 6 (14%) |
Team autonomy | 10 (24%) | ||
Allow teams to self-organize | P5, P16, P18, P27, P30, P34, P41, P45 | C4, C11, C13, C21, C23, C25, C32, C35 | 8 (19%) |
Allow grass roots level empowerment | P3, P6, P41 | C2, C5, C32 | 3 (7%) |
Requirements management | 10 (24%) | ||
Recognize the importance of the Product Owner role | P12, P14, P16, P24, P30, P33, P39, P46 | C10, C11, C12, C18, C23, C30, C36 | 7 (17%) |
Invest in learning to refine the requirements | P5, P11, P17, P33, P48 | C4, C9, C11, C38 | 4 (10%) |
“The challenge categories that received the most mentions are agile difficult to implement, integrating non-development functions, change resistance, and requirements engineering challenges. The success factor categories that received the most mentions are choosing and customizing the agile approach, management support, mindset and alignment, and training and coaching”.
References:
Boehm, B. and Turner, R. (2005) ‘Management challenges to implementing agile processes in traditional development organizations’, Softw. IEEE, 22 (5) (2005), pp. 30-39.
Dikert, K., Paasivaara, M. and Lassenius, C. (2016) Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, pp. 87-108. Available at: http://www.sciencedirect.com/science/article/pii/S0164121216300826 (Accessed: 13 September 2017)
Dybå,T. and Dingsøyr, T. (2008) ‘Empirical studies of agile software development: a systematic review’ Inf. Softw. Technol., 50 (9-10), pp. 833-859.
Lindvall, M., Muthig,D. , Dagnino,A. , Wallin,C., Stupperich,M. , D. Kiefer,D., May,J. and Kahkonen, T. (2005) Agile software development in large organizations. Computer, 37 (12), pp. 26-34.