0

AGILE: Large scale Vs Small Scale projects

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.

ayesha

Leave a Reply

Your email address will not be published. Required fields are marked *