practices in a large software development organization. The case study research ... current state of the case study software company, a number of instruments .... We wish to thank the Australian Research Council for financial support. This is ...
Construction of an Agile Software Product-Enhancement Process by Using an Agile Software Solution Framework (ASSF) and Situational Method Engineering Asif Qumer, Brian Henderson-Sellers University of Technology, Sydney, PO Box 123, Broadway, NSW 2007, Australia Abstract Introducing a change in any software development organization is challenging; as this paper demonstrates by means of a case study for the adoption of agile practices in a large software development organization. The case study research findings indicate that a situational method engineering approach together with an agile software solution framework (ASSF) can be used to create a feasible and usable hybrid software development method by combining agile practices and formal practices for a particular situation in large software development organizations.
1. Introduction Agile is a proven light-weight, people-focused, iterative and incremental strategy for the development of small to medium-scale software projects [1]. Although Anderson [4-5] suggests that a better return on investment can be achieved by decreasing operating expenses and increasing throughput by using an agile approach, the applicability of agile processes for large-scale projects has not been reliably established. Here, we examine whether a situational method engineering (SME) approach [10] together with our newly developed agile software solution framework (ASSF) [18] can be usefully applied to create and utilize a repository of agile-focused method fragments – as advocated in an SME approach. We do this in the context of case study research based on a large-scale industry application development by constructing practical hybrid agile practices (agile together with formal process fragments) and processes with sufficient discipline and rationality for the development of large and complex applications. This paper presents one of the case studies for the demonstration of agile applicability in a very formal and large software development organization. The paper is organized as follows: in Section 2 we give a very brief overview of the Agile Software Solutions Framework. Sections 3 and 4 then outline the case study and a discussion of the empirical results.
2. The Agile Software Solution Framework We have developed a method-independent agile framework (ASSF) [18] that includes a (Java-based) agile toolkit [17] to facilitate the construction of practical hybrid agile practices (agile together with formal process fragments) and processes with sufficient discipline and rationality for the development of large and complex applications. The ASSF consists of six main parts: agile method, agile toolkit, agile knowledge, agile governance, business value and agile (business-agile alignment bridge), and business. Agile method represents the different but related core aspects of an agile method/ methodology: agility, abstraction, people, process, product and tools (agile workspace); which can be combined by using a situational method engineering approach for the construction of agile situation-specific methods to achieve the desired business value. The purpose of the ASSF is to guide the behaviours of selforganizing and empowered agile teams with a cohesive set of shared information in large and complex project development environments.
3. The case study of agile transition The transition to agile or adoption of an agile approach in a large software development organization is acknowledged as a growing trend [20]. However, such a transition is not an easy task and one that may pose problems if a full transition is attempted in one step. The software organization studied here is a large product-line company, with more than 300 employees, providing product development, support and maintenance services to their customers while following a very formal software development approach. A step-by-step or project-byproject approach may be considered reasonable for a successful gradual agile transition or adoption. To accomplish this, and for the purpose of assessment of the current state of the case study software company, a number of instruments were used, such as agile workshops, interviews and focus group to uncover and handle the contextual issues and challenges. We also consulted and analysed a number of reports, case studies regarding the scalability and adoption of agile practice [2-
31st Annual International Computer Software and Applications Conference(COMPSAC 2007) © 2007 Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 19, 2009 at 21:39 from IEEE Xplore. Restrictions apply.
Agile Workspace Product
Abstraction
Agility
Process (APEP)
Agile Team
Communication-cooperation protocol development
Product client selection
Product-enhancement features, business- value identification
Product-enhancement features model development
Product-enhancement model testing and feedback
Product-Enhancement Features Generation
Product Features Backlog Product Planning
Increment 1
Increment 2
Increment n
Architecture and Design
Architecture and Design
Architecture and Design
Coding and Testing
Coding and Testing
Coding and Testing
Product Development
3, 6-8, 11-15, 19-20] to carry out this case study. Therefore, the company’s first step was to engineer a process (called by them Agile Product-Enhancement Process or APEP) rather than a whole methodology to demonstrate the applicability of both method engineering (from a situation-specific agile process construction perspective) and agile in a large organization. The company is mainly responsible for the ongoing maintenance of their well-developed product line, sold to large hardware vendor companies, which involves both the development of new software product features and fixing bugs in the software products already developed. During this case study, it was found that the company could not develop new features of their products (with the current pace of the maintenance process) in an appropriate timeframe by using a traditional software development method. This became increasingly difficult with their current approach to software development and, although the bug fixing mechanism of the company was working well, they decided they had to seek a product enhancement process that would enable them to quickly identify and develop new product features to keep them competitive. A product-enhancement process demands an innovative, dynamic and flexible approach for the development of new features of the products – this requires a much more agile approach to software development than they had previously used. However, the software company was not ready to fully use an agile software development method on the largescale because a sudden change all at once was seen as risky and problematic (as noted above). Therefore, the company first engineered (by using an SME approach) an agile product-enhancement process (a mix of agile and formal practices) to quickly develop the new features of the software products while the bug fixing process remained traditional (Figure 1). To do this, they inspected the contents of the repository (method fragments) in collaboration with the senior author. They chose a minimum set identified in the context of the specific situation set by the project in question. This set of fragments was then configured into a process model appropriate to the skills of the development team and the constraints of the target project, according to SME principles and practice, and then applied in real time by the development team (enactment). The agile workspace guiding model had been defined to specify the tools and development environment for the execution of APEP. The agility model [16] had been used to define the degree of agility of APEP. The APEP is a mix of agile and traditional incremental software development practices [9]. The APEP includes three main phases: product-enhancement features generation (agile approach), product development (traditional incremental approach) and post-mortem; and ten main practices: (1) communication-cooperation
Integration and Client Acceptance Testing, and Release
APEP Post-Mortem Figure 1. Agile Product-Enhancement Process protocol development, (2) product client(s) selection, (3) product-enhancement features and business value identification (4) product-enhancement features model development, (5) product-enhancement model testing and feedback, (6) product (enhancement) features backlog (7) product planning, monitoring and control, (8) product architecture and design, (9) implementation, testing and release and (10) APEP post-mortem. The productenhancement features generation phase contains agile
31st Annual International Computer Software and Applications Conference(COMPSAC 2007) © 2007 Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 19, 2009 at 21:39 from IEEE Xplore. Restrictions apply.
practices for iterative generation of the productenhancement features list (product backlog) and executable product-enhancement features model in small increments in a communication-oriented and cooperative, and people-focused environment. Once the desired number of features had been identified, in the product development phase, a formal incremental approach for development is followed for the detailed description of identified features in the requirements specification document, architecture and design, implementation, testing and release of the enhanced-product with its new features. Finally, the post-mortem phase is executed after the end of each iteration, phase and process for the purpose of future learning and decision making; an SME approach here enables the introduction of changes in the APEP in order to implement the decisions and to reflect the lessons learned. The software company has accepted the APEP and is using it for product enhancement including any necessary changes, as required.
4. Discussion and analysis The success of the agile transition substantially depends on the leading role of the CIO and executive management, who should take responsibility for eliminating the impediments to effective development and delivery of business value through an agile approach. The construction of an appropriate agile process was itself a challenge but the most important challenge was the development and encouragement of an agile culture and mindset within the organization. We had laid the groundwork for an agile process compatible with a formal approach by defining a set of hybrid agile practices by using the ASSF and SME. The case study company understood the potential advantages of agile for their organization. This transition also helped them to train the team of developers for future agile ventures and this team could serve as a change agent for the future and further adoption of agile. Furthermore, it had been proved that agile practices would allow the organization to develop or invent new features for their products in a formal and large development environment where a complex product could be developed by using an agile approach. From the perspective of the company clients and product acceptance in the market, the stakeholders of the product realized the importance of being involved throughout the product development. The case study organization’s development teams learned that, being collectively responsible for product features generation and product scope enhancement, they could work creatively while communicating and cooperating with each other to meet the budget to satisfy their most important business needs. The other developers within the organization also showed their interest in the agile approach and realized that agile practices can work within large and complex technical development arrangements. The case study organization
felt well-placed and found itself to be in a very comfortable position for the adoption of agile practices within the organization at a large scale in the future. The results of this case study clearly evidence two things: firstly, the applicability of situational method engineering to agile and, secondly, the appropriateness of agile practices for large and complex projects. Agile and traditional phases had been combined in the constructed process (APEP) for the case study organization. In the agile phase (first phase) of APEP, the empowered agile team made their decisions for delivering the business value (new features). They learned to identify the changes and reflect those changes quickly by helping themselves using a face-to-face communication and feedback approach. At the same time, they were encouraged to organise and manage themselves but were held accountable and responsible for the required deliverables (new features and executable model). They found documenting the newly identified features in the features executable model to be very productive. The product manager worked as a facilitator rather than as a manager and led the team by facilitating and governing them not only as a manager. However, the responsibilities were shifted more on to the developers in this phase. The transition from a traditional approach and mindset takes time and the product manager helped the developers at all levels and led them to make a successful transition. The product manager and self- motivated developers found the agile adoption exciting and rewarding. In the second phase of the APEP, the traditional development team took the newly identified features and executable product-enhancement features model as an input for the detailed implementation and product release, within the guidelines of the formal development environment and recognised the quality of the deliverable of the agile team. They found that working with the executable model is much easier than with requirement on paper only. The developed model served them as a visionguiding model for the later development. In this case study, it was also found how successfully an agile team communicated the developed artifacts to a non-agile team in the form of an executable model. The final phase of APEP (post mortem), which was not strictly a last phase, is an umbrella activity that is done all the time during the product-enhancement process life cycle for effective learning and decision making for the purpose of continuous process improvement and optimized business value delivery. The case study company is using APEP and has already made several changes in the initial version of the APEP by introducing few more agile practices in the formal phase of the APEP. They have introduced fixed duration iterations within each increment, two levels of planning (release planning and iteration planning) and a test-first (the design of the test-case) approach. However, the formal phase of the APEP is documentation-driven
31st Annual International Computer Software and Applications Conference(COMPSAC 2007) © 2007 Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 19, 2009 at 21:39 from IEEE Xplore. Restrictions apply.
and change has not been welcomed overall so that a formal change control mechanism is used to avoid the change, i.e. the developers are not allowed to make their decisions and a formal change management mechanism is used. However, the developers may give input to the decisions. In future, the company is willing to establish a communication-corporation and a less document-oriented environment at a large scale, which will enable them to focus on the quick delivery of the working software rather on documentation.
5. Conclusion The case study research findings indicate that a situational method engineering approach together with an agile software solution framework (ASSF) can be used to create a feasible and usable hybrid software development method by combining agile practices and formal practices for a particular situation in large software development organizations. With the application of a newly engineered agile product enhancement process (APEP), the company managed to increase both the speed of the development of new features and the predictability of the software product features. This offered an opportunity for a case study of the introduction of both agility and situational method engineering into one specific software development company, the results of which are the focus of this paper.
Acknowledgements We wish to thank the Australian Research Council for financial support. This is contribution number 07/04 of the Centre for Object Technology Applications and Research. We also wish to thank the people of the case study software development organization who helped us in the construction and application of the APEP.
References [1] AgileManifesto, Manifesto for Agile Software Development, 2001. [2] S.W. Ambler, “Scaling Agile Development Via Architecture”, Agile Journal, 2006. [3] D.J. Anderson, “Stretching Agile to Fit CMMI Level 3: The Story of creating MSF for CMMI® Process Improvement at Microsoft Corporation” Agile Conference, Denver, 2005. [4] Anderson, D.J., Agile Management for Software Engineering - Applying the Theory of Constraint for Business Results, Upper Saddle River, NJ: Prentice Hall, 2003. [5] Anderson, D.J., Agile Management for Software Engineering, ed. P. Coad., Pearson Education Inc., 2004. [6] L. Barnett, “Learning From Others: Best Practices For Large-Scale Agile Development”, Agile Journal, 2006.
[7] A. Elssamadisy, “Getting Beyond "It Depends!" Being Specific But Not Prescriptive About Agile Practice Adoption”, Agile Journal, 2006. [8] I. Gat and R. Martens, “CASE STUDY: How BMC Is Scaling Agile Development”, Agile Journal, 2006. [9] Jalote P., An Integrated Approach to Software Engineering, 2nd edition, Springer-Verlag, New York, 1997. [10] Kumar, K. and R.J. Welke, Methodology Engineering: a Proposal for Situation-Specific Methodology Construction, Challenges and Strategies for Research in Systems Development, John Wiley & Sons: Chichester, UK, 1992, pp. 257-269 [11] Leffingwell, D. and D. Muirhead, Tactical Management of Agile Development: Achieving Competitive Advantage, Rally Software Development Corporation, 2004. [12] McMunn, D. and J. Nielsen, Showcasing Agile Development: A Powerful Tool for “Crossing the Chasm”, Digital Focus, 2005. [13] L. Meadows, and S. Hanly, “Agile Coaching in British Telecom”, Agile Journal, 2006. [14] J. Nielsen and D. McMunn, “The Agile Journey: Adopting XP in a Large Financial Services Organization”, in XP 2005, Springer-Verlag Berlin Heidelberg, 2005. [15] R. Pettit, “Scaling Up: An Approach to Organizational Agile Adoption”, Agile Journal, 2006. [16] A. Qumer, and B. Henderson-Sellers, “Measuring Agility and Adoptability of Agile Methods: A 4Dimensional Analytical Tool”, Procs. IADIS International Conference Applied Computing, IADIS Press, 503-507, 2006. [17] A. Qumer and B. Henderson-Sellers, 2007, “An Agile Toolkit to Support Agent-oriented and Serviceoriented Computing Mechanisms”, Procs. PROFES 2007 [18] A. Qumer and B. Henderson-Sellers, 2007, “An Agile Software Solution Framework: Support for Multiabstraction Mechanisms”, submitted for publication [19] Smits, H., 5 Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up, Rally Software Development Corporation, 2006. [20] Sliger, M., A Project Manager’s Survival Guide to Going Agile, Rally Software Development Corporation, 2006.
31st Annual International Computer Software and Applications Conference(COMPSAC 2007) © 2007 Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 19, 2009 at 21:39 from IEEE Xplore. Restrictions apply.
