The Success Factors of Running Scrum: A Qualitative Perspective
Rich C. Lee
SystemTechnology Group, IBM, Chinese Taipei.
DOI: 10.4236/jsea.2012.56043   PDF    HTML   XML   10,035 Downloads   16,483 Views   Citations

Abstract

Scrum—Agile programming—is getting more attention in Software Engineering practices. Many software projects began with small and were not certain about the requirements until projects have completed; this makes Scrum more appropriate than other development methodologies. This paper reintroduced Scrum from qualitative perspective by applying ethnography and in-depth interview to two different types of project teams to articulate what the success factors are for running Scrum framework. It clearly demonstrated how qualitative research could help in disclosing the essence of facts during the Scrum adaptation in depth. It also articulated how these successful factors mutually affect to one another from System Dynamics perspective and to give further recommendations to Scrum teams and those who tend to apply Scrum development methodology.

Share and Cite:

R. C. Lee, "The Success Factors of Running Scrum: A Qualitative Perspective," Journal of Software Engineering and Applications, Vol. 5 No. 6, 2012, pp. 367-374. doi: 10.4236/jsea.2012.56043.

1. Introduction

Software development is a process of communication [1]. There are many approaches [2] helping the development to produce qualified software to stakeholders. Many software projects began with small and were not certain about the requirements until projects have completed. The requirements are sensitive and volatile to environment changed. Stakeholders did not have a clear picture of what software features were in the early stage of development. Therefore Agile Programming approach was called since early-planned approaches cannot answer well to the nature of software development—the software changes and evolves all the time. Each software development project has its uniqueness and varies to others. The variance may root from the nature of the requirements, the capability of development team, the difference of development approaches, and other organizational culturewise factors.

Scrum is an innovative approach to getting work done. Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework illustrated on Figure 1 is deceptively simple.

There are several key roles in Scrum framework: 1) Stakeholders: the mission owners, possess the idea about why to build, what to build, and how processes should be; 2) Product owner: the product development owner, closely working with stakeholders, creates a prioritized wish list-stories—called a Product Backlog; 3) Scrum Master: the facilitator, closely working with product owner, makes sure the stories in the product backlog will successfully delivered as workable sub-products; 4) Scrum Team: the developers, closely working with Scrum Master, deliver workable sub-products according to the product backlog.

Scrum Master with the team invites the product owner to debrief the stories in product backlog. Scrum Master leads a Sprint Planning with the team to disassemble the story into tasks, a Sprint Backlog. It is a Scrum team effort to decide how to implement and who should do the tasks. Daily-Scrum is a group meeting to discuss the progress of task implementation and technical issues. Scrum Master keeps the team focused on its goal. At the end of the sprint, the process of development, the work should be potentially shippable, as in ready to hand to stakeholders. The sprint ends with a sprint review and retrospective. As the next sprint begins, the team chooses another chunk of the product backlog and begins working again. The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. Which of these milestones marks the end of the work is entirely specific to the project. No matter which impetus stops work, Scrum ensures that the most

Figure 1. Scrum framework. Courtesy from “the Scrum primer” [3].

valuable work has been completed when the project ends.

The success of Scrum framework requires mature capabilities such as technical and communication. Project teams are formed to achieve the strategic objectives of the organization, such as increasing market share, launching a next generation product, improving quality, enhancing customer relationships and for other purposes. Previous research on project management stressed the technical dimension of the project, such as project scheduling, resource leveling, risk mitigation and project control. However, the human side of the project, such as finding the optimal combination of team member’s personality has been ignored. Unfortunately, project members play extremely important roles in achieving the project objectives and it is believed project members must be assigned based on the project needs not only technically, but also mentally. In other words, it is critical to discover if the structure of the project team can accomplish project objectives before the project begins. After adjusting the team members to meet the project requirements, project performance can be significantly improved; and if adjustment is made to the best possible balance condition, the team performance can even be upgraded to the highest level [4].

Software projects are different to one and another. It is not easy to generalize theories and to deliver tangible lesson-learn to the practitioners. The practitioners are looking for answers to improve their software development under similar culture and scenarios. To generate useful knowledge, it requires retrospection on what had not considered and what had done well from empirical cases in depth [5]. Qualitative research is a type of scientific research. In general terms, scientific research consists of an investigation that: 1) seeks answers to a question; 2) systematically uses a predefined set of procedures to answer the question; 3) collects evidence; 4) produces findings that were not determined in advance;4) produces findings that are applicable beyond the immediate boundaries of the study.

To understand the project performance applying Scrum framework in depth, particular in resource capability arbitration among multiple Scrum teams, qualitative research can disclose the complexity of project activities and interaction among team members. This research was designed and trying to answer the following questions:

• What are the critical factors of success team communication in running Scrum?

• How Scrum Master alleviates the challenge when team members lack of skills to complete the assigned task?

• Should Scrum Masters exchange resources for specific skill required tasks?

• What are the criterions of resource exchange among Scrum teams?

2. Research Design

Qualitative research is especially effective in obtaining culturally specific information about the values, opinions, behaviors, and social contexts of particular populations. The strength of qualitative research is its ability to provide complex textual descriptions of how people experience a given research issue. It provides information about the “human” side of an issue—that is, the often contradictory behaviors, beliefs, opinions, emotions, and relationships of individuals. Qualitative methods are also effective in identifying intangible factors, such as social norms, socioeconomic status, gender roles, ethnicity, and religion, whose role in the research issue may not be readily apparent. When used along with quantitative methods, qualitative research can help us to interpret and better understand the complex reality of a given situation and the implications of quantitative data. Although findings from qualitative data can often be extended to people with characteristics similar to those in the study population, gaining a rich and complex understanding of a specific social context or phenomenon typically takes precedence over eliciting data that can be generalized to other geographical areas or populations [6].

Figure 2 illustrated the research process. This research process takes advantage of two powerful methods in deep disclosing phenomenon, qualitative research and system dynamics. In system dynamics, a causally-closed system is one in which the causes creating the behavior of interest lie within the system. A causally-closed system still is open in the sense that it can receive material, energy, random disturbances, and test inputs from outside the boundary [7]. This research relies on qualitative research to form the conceptual model—system dynamics model—for further phenomenon articulation. Most of all, by using the system dynamics tool, the researcher can give conditional parameters to see what the model behaves later to form the recommendations r policy to move the outcome towards more positive direction.

The research process begins with interesting phenomenon observed, reviewing the literature to see if previous studies could explain the phenomenon or not, a more clearer picture of research questions are formed, choosing appropriate research subjects and explain why and how the research will be conducted, undertaking a series of qualitative activities, confirming the theoretical foundation of observed artifacts via further literature review, forming theoretical models to answer the research questions, developing causal-loop analytical model, simulating various scenarios for research implication and recommendations to practitioners.

3. Data Gathering

3.1. Theoretical Background for Data Gathering

Scrum teams are self-organized, are facilitated by rich communication and a collaborative environment and are usually considered effective for colocated projects with a small team size [8]. Office layout often determines the effectiveness of team communications, it plays a powerful role in shaping a diverse range of psychological and behavioral outcomes, including individual work motivation, job satisfaction, and patterns of interactions [9]. The effective leadership of self-managing teams requires strong interpersonal and group process skills as well as external skills of information seeking and giving—plus advocacy and negotiation [10]—which is the cornerstone of makes Scrum process success. Agile Development Framework such as Scrum, requires a daily face to face communication with customers and co-workers to understand and fulfill their requirements [11]. Collaboration tools can play significant role in facilitating the team intensive communication, they are used to mitigate the communication cost. Individual leadership can help Scrum team making development decisions swiftly during the Scrum processes [12]. Although making decision swiftly does not imply the quality of outcome, but holding up issue certainly will be more devastated than need-toreadjusted decision, because Scrum process is all about embrace changes.

3.2. Data Gathering Context

Table 1 illustrated how and what information should be gathered from the informants to disclose the research questions. There were four categories of data, namely environment, communication, project, and retrospection. The major research tools were observation and interview. Collecting the data from multiple perspectives were to clarify whether these contexts having influences to the success of Scrum. The retrospection in Scrum is to create the “inspect and adapt” cycle for how a team works together and alters their practices to improve how they work by constantly asking three questions: 1) what do we need to continue doing; 2) what didn’t work; 3) what do we need to start doing [13]. It is not feasible to compare the software development performance across teams. The complexity of the projects was not identical, and the cap-

Conflicts of Interest

The authors declare no conflicts of interest.

References

[1] A. Gopal, T. Mukhopadhyay and M. S. Krishnan, “The Role of Software Processes and Communication in Offshore Software Development,” Communications of the ACM, Vol. 45, No. 4, 2002, pp. 193-200. doi:10.1145/505248.506008
[2] M. Aoyama, “New Age of Software Development: How Component-Based Software Engineering Changes the Way of Software Development,” 1998 International Workshop on CBSE, Kyoto, 25-26 April 1998, pp. 124-128.
[3] http://assets.scrumtraininginstitute.com/downloads/1/scrumprimer121.pdf
[4] J. Y. Yeh, C. C. Wei, C. S. Wei and D. F. Lei, “The Impact of Team Personality Balance on Project Performance,” African Journal of Business Management, Vol. 6, No. 4, 2012, pp. 1674-1684.
[5] G. Cugola and C. Ghezzi, “Software Processes: A Retrospective and a Path to the Future,” Software Process: Improvement and Practice, Vol. 4, No. 3, 1998, pp. 101-123. doi:10.1002/(SICI)1099-1670(199809)4:3<101::AID-SPIP103>3.0.CO;2-K
[6] http://www.fhi360.org/en/RH/Pubs/booksReports/QRM_datacoll.htm
[7] J. W. Forrester, “System Dynamics, Systems Thinking, and Soft OR,” System Dynamics Review, Vol. 10, No. 2-3, 1994, pp. 245-256. doi:10.1002/sdr.4260100211
[8] P. Abrahamsson, O. Salo, J. Ronkainen and J. Warsta, “Agile Software Development Methods: Review and Analysis,” VTT Publications, Espoo, 2002.
[9] M. C. Davis, D. J. Leach and C. W. Clegg, “The Physical Environment of the Office: Contemporary and Emerging Issues,” International Review of Industrial and Organizational Psychology, Vol. 26, 2011, pp. 193-237.
[10] V. U. Druskat and J. V. Wheeler, “Managing from the Boundary: The Effective Leadership of Self-Managing Work Teams,” Academy of Management Journal, Vol. 46, No. 4, 2003, p. 435. doi:10.2307/30040637
[11] Y. L. Chen, “Analysis of the Agile Deployment,” Master’s Thesis, University of Gothenburg, Gothenburg, 2010.
[12] N. B. Moe, T. Dingsoyr and T. Dyba, “Overcoming Barriers to Self-Management in Software Teams,” Software, Vol. 26, No. 6, 2009, pp. 20-26. doi:10.1109/MS.2009.182
[13] C. Keith, “An Agile Retrospective,” Game Developer Conference, February 2008.
[14] A. Cockburn, “Crystal Clear: A Human-Powered Methodology for Small Teams,” Addison-Wesley, Boston, 2005.
[15] M. Ikonen, P. Kettunen, N. Oza and P. Abrahamsson, “Exploring the Sources of Waste in Kanban Software Development Projects,” 36th Euromicro Conference on Software Engineering and Advanced Applications, Lille, 1-3 September 2010, pp. 376-381.
[16] L. D. Rola, “Kanban for Small Software Projects,” Project Background Report, The University of Manchester, Manchester, 2011.
[17] A. E. Roger, F. N. Marcel and A. C. Lopez, “Business Process Requirement Engineering,” International Journal on Computer Science and Engineering, Vol. 2, No. 9, 2010, pp. 2890-2899.
[18] M. R. Haas, “Knowledge Gathering, Team Capabilities, and Project Performance in Challenging Work Environments,” Management Science, Vol. 52, No. 8, 2006, pp. 1170-1184. doi:10.1287/mnsc.1060.0530
[19] E. Fossey, C. Harvey, F. McDermott and L. Davidson, “Understanding and Evaluating Qualitative Research,” Australian & New Zealand Journal of Psychiatry, Vol. 36, No. 6, 2002, pp. 717-732. doi:10.1046/j.1440-1614.2002.01100.x
[20] M. Luz, D. Gazineu and M. Teofilo, “Challenges on Adopting Scrum for Distributed Teams in Home Office Environments,” World Academy of Science, Engineering and Technology, No. 59, 2009, pp. 308-311.
[21] J. Highsmith and A. Cockburn, “Agile Software Development: The Business of Innovation,” Computer, Vol. 34, No. 9, 2001, pp. 120-127. doi:10.1109/2.947100
[22] G. Lee and W. Xia, “Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data on Software Development Agility,” MIS Quarterly, Vol. 34, No. 1, 2010, pp. 87-114.
[23] J. D. Sterman, “System Dynamics Modeling,” California Management Review, Vol. 43, No. 4, 2001, pp. 8-25.
[24] J. Grenning, “Planning Poker or How to avoid Analysis Paralysis while Release Planning,” Hawthorn Woods: Renaissance Software Consulting, Vol. 3, 2002.
[25] P. Runeson and M. Host, “Guidelines for Conducting and Reporting Case Study Research in Software Engineering,” Empirical Software Engineering, Vol. 14, No. 2, 2009, pp. 131-164. doi:10.1007/s10664-008-9102-8

Copyright © 2024 by authors and Scientific Research Publishing Inc.

Creative Commons License

This work and the related PDF file are licensed under a Creative Commons Attribution 4.0 International License.