Agile Method, Scrum, and Software Product Line Engineering: History
View Latest Version
Please note this is an old version of this entry, which may differ significantly from the current revision.
Contributor:
Wen-Tin Lee
,
Chih-Hsien Chen

Agile methods and software product line engineering (SPLE) are widely recognized as practical approaches for delivering high-quality software, adapting to evolving stakeholder needs, and tackling complex problems. Agile means fast, light, and dynamic. Agile methods are more effective and faster when responding to changes than traditional software development methods. Software reuse involves creating new software from existing software products that improve product quality by combining reliable and quality software components.

  • agile methods
  • Scrum
  • software product line engineering

1. Introduction

Software development methods aim to increase the development team’s productivity, shorten the time to market, reduce development costs, and improve customer satisfaction. To achieve the above goals, agile software development, also known as agile development, has gradually aroused public discussion since the 1990s. It advocates adaptive planning and evolutionary development, shares the same software process values, and encourages rapid and flexible responses to changes through early delivery and continuous improvement [1]. Agile development emphasizes moderate planning, human-oriented cooperation, face-to-face communication, self-organization and management, and rapid development [2]. Software organizations adopt large-scale agile practices [3][4][5][6] to replicate the success of agile methods on team projects at the organizational level.
Although the agile software development method can tolerate changes in requirements and can effectively and quickly solve problems, increase output, and shorten the entire development timeline, it also has some shortcomings which may lead to project failures. For example, requirement identification and initial planning is the first challenge of Scrum [7]. Another challenge of Scrum is the lack of attention to design. Scrum pays less attention to requirement engineering in the analysis and design phase. In addition, its lack of traceability of documents and files and configuration management may affect product quality or lead to project failure. Software product line engineering (SPLE) [8][9][10][11] uses product-line methods to produce products for customers with different needs. Software product-line engineering aims to develop software products at a minimal cost [8][12] and improve software quality by increasing the reuse of existing software components [13].

2. Agile Method, Scrum, and Software Product Line Engineering

2.1. Agile Method and Scrum

Agile means fast, light, and dynamic. Agile methods are more effective and faster when responding to changes than traditional software development methods [14][15][16]. They emphasize individual interactions between processes and tools, self-organizing teams, continuous release of new software features, and customer collaboration [17]. Agile methods maintain rigorous engineering processes and adopt best practices while helping stakeholders work with software developers to build, deploy, and maintain complex software [18]. They emphasize adapting to changes rather than predicting [19]. The focal aspects of agile methods are simplicity and speed [15]. Agile software development methods generally have the following characteristics: incremental: small software releases with rapid cycles; cooperative: customers, developers, and relevant stakeholders work and communicate together closely; straightforward: the method itself is easy to adopt and well documented; and adaptive: the ability to deal with changes.
According to the Agile Status Survey [20], Scrum was reported as the most widely practiced agile methodology. At least 72% of respondents currently practice the Scrum method or a hybrid approach containing Scrum. Scrum was first introduced by Takeuchi and Nonaka [21] in the context of product development. The term Scrum is borrowed from the rugby game, which means that only by maintaining an overall forward method, like passing the rugby ball within the team, can it cope with the challenges of the current complex market [22]. The Scrum framework proposed by Jeff Sutherland and Ken Schwaber [23] is an agile method that can deal with changes by developing and reviewing software increments iteratively. Unlike the waterfall model, which breaks down project activities into different phases, Scrum focuses on developing a set of high-value features incrementally and iteratively through each Sprint to obtain customer feedback faster [24].
The Scrum team is a small cross-functional, self-organizing team that uses iterative and incremental processes for the project or product development. Team members are responsible for creating and adapting the overall process within this structure. The management representative of the team is the Scrum Master. The primary responsibility of the Scrum Master is to eliminate obstacles to the team and ensure that Scrum practices are followed. Product Backlog is the priority list of all requirements or user stories to be implemented in the project; the Product Owner has the right to determine the priority of the user story [19]. Grooming is managing product backlog with prioritized requirements and estimating the amount of work to complete the requirements [25].
Sprint is a time-boxed development period based on product goal and complexity, usually 1–4 weeks. The Scrum team builds and tests product increments with new features that can be released in each Sprint. Sprint begins with a Sprint planning meeting where the product owners, Scrum Master, and Scrum team members determine what needs to develop. The Scrum team then uses Sprint goals in internal meetings to obtain a list of requirements in the Sprint backlog. A successful Sprint depends on whether Sprint goals and the requirements in the Sprint backlog are achieved and satisfied.
During the Sprint, the Scrum master holds a 15 min “Daily Scrum” or “Daily Standup Meeting” with the Scrum team to review project progress. Each team member will answer three questions [23]: 1. What has been done since the last meeting? 2. What will be done before the next meeting? 3. What are the obstacles in the process?
Each Sprint provides an incremental version of a potentially deliverable product. The team produces software that is coded, tested, and usable at the end of each Sprint. The Scrum team will hold a Sprint review meeting to show their results during the Sprint. Next, the Scrum team evaluates its work and processes in a Sprint retrospective meeting to prioritize improving the team’s processes before the next Sprint [26].
Agile software development methods also have some challenges. For example, the challenges of Scrum are how to identify requirements, how to conduct preliminary planning, and the lack of focus on design [27]. Scrum pays less attention to requirement engineering in the analysis and design phase [28]. In addition, it has poor traceability in document archives, incomplete version control, and configuration management, all of which may be potential factors that lead to project failure and even affect subsequent system maintenance and requirements changes.

2.2. Software Product Line Engineering

Software reuse involves creating new software from existing software products that improve product quality by combining reliable and quality software components. A software product line (SPL) is a set of software-intensive systems that share features or functions generated from a group of pre-defined and reusable shared core assets [10][29]. Software product line engineering (SPLE) [8][9][10][11] uses product line methods to produce products for customers with different needs. A product line is created by combining commonalities to efficiently produce products by integrating or reusing shared core assets to meet customer needs. Large-scale customization is transparent in software product line engineering, customers can obtain unique products through their specific needs, and their common needs will be evaluated before production starts [29].
Software product line engineering aims to develop software products by reusing existing software components [13]. Different techniques and methods [30][31][32][33][34][35] can be used to develop various software products in multiple domains. Several studies [36][37][38][39][40] explore how to integrate agile methods and software product line engineering. There are two complementary development processes in software product line engineering: the domain engineering process and application engineering process. The domain engineering process defines and realizes the commonality and variability characteristics of the product line. Its purpose is to develop the shared core software assets and a common and reusable product line platform to promote the systematic and consistent reuse of all finished products and components. The application engineering process binds the product line’s variability according to specific applications’ needs. It builds a single application product or a series of product applications by reusing shared core software assets, products, or product components from domain engineering [41]. The domain engineering process comprises five sub-processes: product management, domain requirement engineering, domain design, domain realization, and domain quality assurance [8][36]. Developers identify domain variability models and implement and test reusable domain artifacts in a product line platform. The application engineering process comprises four sub-processes: application requirement engineering, application design, application realization, and application testing. Developers design application variability models and build application artifacts according to customers’ needs.

This entry is adapted from the peer-reviewed paper 10.3390/electronics12153291

References

  1. Sutherland, J. Scrum: The Art of Doing Twice the Work in Half the Time; Crown Business: New York, NY, USA, 2014.
  2. Williams, L. Agile Software Development Methodologies and Practices. Adv. Comput. 2010, 80, 1–44.
  3. Almeida, F.; Espinheira, E. Adoption of Large-Scale Scrum Practices through the Use of Management 3.0. Informatics 2022, 9, 20.
  4. Edison, H.; Wang, X.; Conboy, K. Comparing Methods for Large-Scale Agile Software Development: A Systematic Literature Review. IEEE Trans. Softw. Eng. 2022, 48, 2709–2731.
  5. Spagnoletti, P.; Kazemargi, N.; Prencipe, A. Agile Practices and Organizational Agility in Software Ecosystems. IEEE Trans. Eng. Manag. 2022, 69, 3604–3617.
  6. Wessel, R.M.v.; Kroon, P.; Vries, H.J.d. Scaling Agile Company-Wide: The Organizational Challenge of Combining Agile-Scaling Frameworks and Enterprise Architecture in Service Companies. IEEE Trans. Eng. Manag. 2022, 69, 3489–3502.
  7. Sherif, E.; Helmy, W.; Galal-Edeen, G.H. Proposed Framework to Manage Non-Functional Requirements in Agile. IEEE Access 2023, 11, 53995–54005.
  8. Pohl, K.; Böckle, G.; van Der Linden, F.J. Software Product Line Engineering: Foundations, Principles and Techniques; Springer Science & Business Media: Berlin/Heidelberg, Germany, 2005.
  9. Böckle, G.; Pohl, K.; van der Linden, F. A framework for software product line engineering. In Software Product Line Engineering; Springer: Berlin/Heidelberg, Germany, 2005; pp. 19–38.
  10. Weiss, D.M.; Lai, C.T.R. Software Product-Line Engineering: A Family-Based Software Development Process; Addison-Wesley Reading: Boston, MA, USA, 1999; Volume 12.
  11. Northrop, L.; Clements, P.; Bachmann, F.; Bergey, J.; Chastek, G.; Cohen, S.; Donohoe, P.; Jones, L.; Krut, R.; Little, R. A Framework for Software Product Line Practice, Version 5.0; Software Engineering Institute|Carnegie Mellon University: Pittsburgh, PA, USA, 2012.
  12. Moon, M.; Yeom, K.; Chae, H.S. An approach to developing domain requirements as a core asset based on commonality and variability analysis in a product line. IEEE Trans. Softw. Eng. 2005, 31, 551–569.
  13. Pine, B.J.; Pine, J.; Pine, B.J.I. Mass Customization: The New Frontier in Business Competition; Harvard Business Press: Brighton, MA, USA, 1993.
  14. Highsmith, J.; Cockburn, A. Agile software development: The business of innovation. Computer 2001, 34, 120–127.
  15. Anderson, D.J. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results; Prentice Hall: Upper Saddle River, NJ, USA, 2003.
  16. Hoda, R.; Salleh, N.; Grundy, J.; Tee, H.M. Systematic literature reviews in agile software development: A tertiary study. Inf. Softw. Technol. 2017, 85, 60–70.
  17. Martin, J. Application Development without Programmers; Prentice Hall PTR: Hoboken, NJ, USA, 1982.
  18. Hoda, R.; Salleh, N.; Grundy, J. The Rise and Evolution of Agile Software Development. IEEE Softw. 2018, 35, 58–63.
  19. Cockburn, A. Agile Software Development; Addison-Wesley Longman: Boston, MA, USA, 2002; pp. 1–221.
  20. VersionOne, C. 12th Annual State of Agile Report; CollabNet VersionOne. Com: Alpharetta, GA, USA, 2018.
  21. Takeuchi, H.; Nonaka, I. The new new product development game. Harv. Bus. Rev. 1986, 64, 137–146.
  22. Schwaber, K.; Beedle, M. Agile Software Development with SCRUM; Prentice Hall: Upper Saddle River, NJ, USA, 2002; Volume 1.
  23. Schwaber, K.; Sutherland, J. The Scrum GuideTM. The Definitive Guide to Scrum: The Rules of the Game. 2020. Available online: https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf (accessed on 1 February 2023).
  24. Blankenship, J.; Bussa, M.; Millett, S. Managing Agile Projects with Scrum. In Pro Agile .NET Development with Scrum; Apress: Berkeley, CA, USA, 2011.
  25. Rubin, K.S. Essential Scrum: A Practical Guide to the Most Popular Agile Process; Addison-Wesley: Boston, MA, USA, 2012.
  26. Larsen, D.; Derby, E. Agile Retrospectives; Pragmatic Bookshelf: Raleigh, NC, USA, 2006.
  27. Harvie, D.P.; Agah, A. Targeted scrum: Applying mission command to agile software development. IEEE Trans. Softw. Eng. 2016, 42, 476–489.
  28. Wisocky, R.K. Effective Project Management: Traditional, Adaptive, Extreme; Wiley: Indianapolis, IN, USA, 2007.
  29. Clements, P.; Northrop, L. Software Product Lines: Practices and Patterns; Addison-Wesley Professional: Boston, MA, USA, 2001.
  30. Khan, S.A.; Alenezi, M.; Agrawal, A.; Kumar, R.; Khan, R.A. Evaluating Performance of Software Durability through an Integrated Fuzzy-Based Symmetrical Method of ANP and TOPSIS. Symmetry 2020, 12, 493.
  31. Dospinescu, O.; Perca, M. Technological Integration for Increasing The Contextual Level of Information; Editura Universitatii Alexandru Ioan Cuza Iasi: Iasi, Romania, 2011.
  32. Ling, Y.; An, T.; Yap, L.W.; Zhu, B.; Gong, S.; Cheng, W. Disruptive, Soft, Wearable Sensors. Adv. Mater. 2020, 32, 1904664.
  33. Aguado, A.; Lopez, V.; Lopez, D.; Peev, M.; Poppe, A.; Pastor, A.; Folgueira, J.; Martin, V. The Engineering of Software-Defined Quantum Key Distribution Networks. IEEE Commun. Mag. 2019, 57, 20–26.
  34. Buraga, S.C.; Amariei, D.; Dospinescu, O. An OWL-Based Specification of Database Management Systems. Comput. Mater. Contin. 2022, 70, 5537–5550.
  35. Lee, W.-T.; Ma, S.-P. Process modeling and analysis of service-oriented architecture–based wireless sensor network applications using multiple-domain matrix. Int. J. Distrib. Sens. Netw. 2016, 12, 1550147716676556.
  36. Santos, A., Jr.; de Lucena, V.F., Jr. ScrumPL-Software Product Line Engineering with Scrum. In Proceedings of the Fifth International Conference on Evaluation of Novel Approaches to Software Engineering, Athens, Greece, 22–24 July 2010; pp. 239–244.
  37. Tian, K.; Cooper, K. Agile and software product line methods: Are they so different. In Proceedings of the 1st International Workshop on Agile Product Line Engineering, Baltimore, MD, USA, 21 August 2006.
  38. Díaz, J.; Pérez, J.; Alarcón, P.P.; Garbajosa, J. Agile product line engineering—A systematic literature review. Softw. Pract. Exp. 2011, 41, 921–941.
  39. Haidar, H.; Kolp, M.; Wautelet, Y. Agile Product Line Engineering: The AgiFPL Method. In Proceedings of the 12th International Conference on Software and Data Technologies, Madrid, Spain, 24–26 July 2017; pp. 275–285.
  40. Noor, M.A.; Rabiser, R.; Grünbacher, P. Agile product line planning: A collaborative approach and a case study. J. Syst. Softw. 2008, 81, 868–882.
  41. Metzger, A.; Pohl, K. Software product line engineering and variability management: Achievements and challenges. In Future of Software Engineering Proceedings (FOSE 2014); Association for Computing Machinery: New York, NY, USA, 2014; pp. 70–84.
More
© Text is available under the terms and conditions of the Creative Commons Attribution (CC BY) license; additional terms may apply. By using this site, you agree to the Terms and Conditions and Privacy Policy.
This entry is offline, you can click here to edit this entry!
Video Production Service
Feedback