Agile development: Issues and avenues requiring a substantial enhancement of the business perspective in large projects Oualid Ktata, Ghislain Lévesque University of Québec at Montréal 201, avenue du Président-Kennedy Montréal, Québec, Canada
[email protected],
[email protected] ABSTRACT
General Terms
Large-scale projects, are often delivering low value software to businesses due to stakeholders’ misunderstanding. Evolutionary software development represents an alternative to plan-driven development in order to tackle today’s turbulent environments. In agile development, a type of evolutionary development, the product owner (P.O.) who is the customer representative— real accountable role— is ill-equipped to identify and prioritize the stakeholders’ most success-critical expectations and potential sources of business value. Furthermore, the tools he can use have their own scalability issues that question their underlying principles. Moreover, without a substantial involvement to take into account all stakeholders, software providers are more likely acting as commodity-utility providers than real business partners. In today’s business context, there is a clear need for a valuedriven development which embraces changes along with higher visibility and understanding of business transformations.
Management, Measurement and Economics.
Keywords Agile development, goal oriented approaches, software valuation, decision making, requirements engineering, project management, Scrum and business modeling.
1. INTRODUCTION The most significant challenges facing 21st-century organizations will be their ability to adapt to rapid and unpredictable change in more rapid and appropriate ways than their competitors [4]. In today’s world, the evolution of the organization’s business environment greatly challenges current software development practices. Software is always hard to make and will be so for a long time because of human creativeness involved in it. Furthermore, the human cognitive model cripples the requirements’ elicitation process. In fact, humans use distortion, deletion and generalization to express their thoughts [2]. As a matter of fact, potential conflicts among the main success-critical stakeholders (users, acquirers, maintainers and developers) means that there are so many potential win-lose situations that a project can get into. ‘A win-lose situation usually turns into a lose-lose situation’ [4], [16]. Successful development then means finding win-win situations compromises to avoid leaving some stakeholders with unsatisfied needs.
The current problems of software crisis could be condensed in a twofold business perspective dilemma: Doing the right product and providing efficient guidance to the development project. Approaches based on goals have been successfully used in Requirements Engineering (RE) and IT governance to address issues similar to the current software crisis. Commonalities in motivations behind the use of goals in both domains can open new avenues for improving the business perspective in Scrum. A goal-value oriented approach is then proposed as a candidate approach to balance the stakeholders’ needs and expectations for large-scale agile developments and ensure focus on delivering high value functionalities.
Companies need assurance that they pay for software that corresponds to their real needs even if they are not capable to define them correctly. Increasingly, companies are switching to enterprise solutions, as their vendors claim that it will satisfy their current and future needs thanks to their scalability and adaptability. This particularly challenges the software development companies as they can’t offer the right software if the customer himself doesn’t know what he really wants.
Categories and Subject Descriptors K.6.3 [Management of computing and information systems]: Software Management– Software development, Software process.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. C3S2E-09 2009, May 19-21, Montreal [QC, CANADA] Editor: B C. DESAI, Copyright ©2009 ACM 978-1-60558-4010/09/05 $5.00
This paper focuses on motivations behind a substantial enhancement of the scrum’s business perspective. At first, it presents today’s business context and challenges facing new large-scale developments. Secondly, it explains how traditional approaches have strong limitations for addressing those challenges. Thirdly, agile methods are presented as a viable alternative to face the current software crisis in large projects. However, they also suffer from limitations due to scalability
59
issues and weaknesses in their business perspective. The business perspective dilemma fall in two categories: (1) misunderstanding of critical-success stakeholders expectations which is considered a requirement management issue. (2) The incapacity of the customer representative to make appropriate decisions which is considered a project governance issue. Fourthly, the successful use of goals in addressing similar issues is presented as an avenue to use them as a central concept in tackling the twofold business perspective. Finally, few suggestions that need further validation later on are proposed to show potential uses of goals in the intended extension.
Conflicting stakeholders’ expectations: The higher the number of stakeholders, the larger the number of expectations is to be for the intended software. Identifying the success-criticalstakeholders seems to be an easy task. However, many tasks may hide some difficulties like identifying their real expectations for the software, dealing with conflicting ones from colleagues, analyzing second and sometimes third level effects, outflanking their cognitive barriers, and finally negotiating some compromises. This is to stress the importance and criticality of the elicitation process in any software development that is more mandatory in a highly volatile business environment like today’s world. Privileging only some stakeholders’ perspectives over others or ignoring some others less advocated has the effect to end up with many win-lose situations that will result more than expected in lose-lose situations.
2. Potential issues in today’s large-scale development Large projects were very often developed using rigorous development processes since it was believed that only through intensive analysis, design and documentation that the intended software can be delivered. However, today’s business context is challenging this approach to develop large-scale software systems. Here are some large-scale software development issues to examine from a business viewpoint.
These stakeholders’ value propositions are likely to conflict with each other, even for the main stakeholders in a software-intensive system. A value-neutral, one-size-uniformly-fits-all solution does not hold anymore and dependability should be valued instead. The wicked nature of software valuation hampers the decision making process and consequently, badly influence the governance of the development projects.
2.1 Volatility of the business context Business change is deemed vital to an organization survival and evolution in order to adapt to its environment. Today’s turbulent business environment is compelling software development providers to face several challenges regarding their ability to react appropriately to their customers needs. In such a volatile business context, software development has to face this new reality by trying to handle uncertainty and rapid change in business environment and has to reengineer its methods. These aspects need more attention than ever before because software has become the dominant source of competitive differentiation in organizations’ products and services. Here some of the main concerns for this reengineering are explored.
2.1.3 The wicked nature of software valuation Jeff Patton defines the nature of business value as follow [17]: Business value is not always tangible: The business value could be perceived by the organization as an increase in revenue or reduction in cost or simply an improvement of service. For now, the business value depends on the observer perception of it. In an organization, for example, different stakeholders from different departments can perceive some opportunity for software depending on their knowledge of it and the added value they are looking for behind its adoption. Thus, there is a need for tools to make business value more tangible and limit subjectivity issues. Sources of value prioritization: as business value is subjective, different stakeholders can perceive different things as valuable from their own perspective. Without a common understanding of business valuation in front of the strategy pursued, it’s hard to find consensus on prioritizing sources of value.
2.1.1 Uncertainty and rapid change If rapid change is predictable, architecture can accommodate it most of the time, by encapsulating the code. Hence, side effects of the changes are limited to one module. However, many sources of change are frequent and unpredictable. When users are asked to specify in advance how they would like to interact with a new application, they often provide the IKIWISI (I’ll Know It When I See It) response [4]. Being too slow to accommodate this uncertainty and rapid change leads inevitably to obsolete software and customer dissatisfaction.
Value evaluation: In order to be evaluated, the business value added from the adoption of a piece of software could be perceived not only when the software is delivered but mainly, when it has been used for a while and that business impact can be evaluated objectively. That is, the inconvenient truth: software must be used to deliver value. That is why each portion of software delivered to get feedback from business should be more than a portion showing only working software elements. Instead, it should be a response waited for by an end user that can show its potential source of value and empower him. Each increment of software delivered should encompass its own value for its user.
2.1.2 Obsolescence When deployed, many software solutions are already obsolete merely because they do not fit to the new business reality of the host organization. Two major factors are causing this obsolescence:
2.2 Limitations on traditional software development
The development time: If development time is shorter than the environment change time, the delivered system is likely to satisfy its customer. On the contrary, the delivered system becomes obsolete, before it is finished [1]. In stable environment there is no need for quick delivery because the business environment is stable. However, in dynamic environments the need for quick delivery is required to accompany business change.
IT projects rarely fail for just one reason. Most of the time, it is a combination of important issues associated to the incapacity of an organization to react rapidly and efficiently to those issues. Unfortunately, there is no silver bullet intended to address them all at the same time. Empowering a development team with tools
60
and automated techniques to ensure quality either in a product perspective or a process perspective has relatively little impact on the overall success of a software project. In fact, seven of the twelve most common factors for project failure lie on the relationship between the businesses and the software development team: ‘unrealistic or unarticulated project goals; poor reporting of the project’s status; unmanaged risks; poor communication among customers developers and users; poor project management; stakeholder politics; and commercial pressures’ [5].
A volatile context would require that business cases be updated regularly during the project lifecycle. Good risk management practice would require that, at different phases of the project lifecycle, the business case be reviewed to be sure that justifications are still valid and that the delivered solution are still matching the current business needs. As a business case is hard to maintain and there is more than often a loss of interest, it tends then to become obsolete.
From a business standpoint, some of the main limitations observed as afflicting software development in a volatile environment are: Software engineering (SE) basic assumptions, lack of adaptive flexibility of business cases and the rigid form of contract negotiations.
2.2.3 Contract negotiations The bad stories of software development (Chaos report 1994) have reinforced the tendency for fixed-price and fixed-scope contracting. But the Internet applications period at the end of the nineties has shown the new business reality of rapid change and instability [3]. In fact, it is particularly hard for software development teams to be creative and adaptive to change in a context of fixed-price contract. The accelerated pace of change in today’s business world do not leave too much choice to adopt new approaches for developing software and hence adopting new contract negotiations.
2.2.1 SE basic assumptions Traditional software development assumptions are challenged by today’s business context. Denning states that current software engineering is based on four key assumptions that we discuss here:
Better contract structures such as “shared destiny” models are preferred; getting these refined and widely accepted will be capital to software success [4], [8], [24]. Agile methods are following this trend by adopting a more flexible contract negotiation [23], [24], more in accordance with its basic principles.
(1) Dependable large systems can only be attained through rigorous application of the engineering design process (requirements, specifications, prototypes, testing, and acceptance): This view is now challenged by the obsolescence of software intensive systems due to a combination of factors like the development time and the business context’s instability. Furthermore, eliminating change early in the process means being unresponsive to business conditions [11]. However, if the instability is not an issue, this assumption can still hold on.
3. Agile software development response For a decade now, agile software development has recruited adepts in the software community and it is becoming a real alternative to traditional software development. First, an overview of the agile main principles and values are recalled. Next, the agile business perspective is described and finally, the scalability issue of agile methods in large-scale projects is explored.
(2) The key design objective is an architecture that meets specifications derived from knowable and collectable requirements: ‘There is no complete statement of requirements because no one person, or even small group, can have a complete knowledge of the whole system at the beginning of a project or can fully anticipate how the community’s requirements will evolve’ [9].
3.1.1 Agile development: principles, values and practices Agile development has outlived the software crisis ‘by legalizing what was forbidden’ by traditional plan-driven development approaches. Instead of avoiding change it defines itself as a response to it. Instead of trying to understand users’ needs as soon as possible, it is preferred to combine feature planning and prioritization with progressive iterative cycles. Instead of overoptimizing, ‘the just enough’ principle is enacted. Instead of involving customer through documentation, face-to-face collaboration is promoted. Instead of analyzing risk and uncertainty thoroughly, tackling it empirically by prototyping is the rule.
(3) The implementation can be completed before the environment changes very much: This assumption does not hold anymore in dynamic business environments. However, it still holds on for stable systems such as air plane software-intensive systems.
2.2.2 Business cases limitations Business cases providing return on investments (ROI) have been used for decades to convince the customer to invest in IT developments [20]. Business cases are mainly used at the start-up of the project to ensure long term commitment from the customer. But the probability of major changes or business instability during the course of a project has to be equally evaluated, which is rarely the case. Management by numbers is a great thing, but overreliance on numbers from ROI analysis may lead to problems [25]. It is fundamental to be aware that ROI is a mean to a bigger cause: improving productivity, reliability and business value. Similarly, too much reliance on financial figures takes the focus away from performance objectives rooted in teamwork, innovation, and success. Focusing on numbers will inevitably lead to failure, because the business context in which those numbers are being measured is constantly changing.
Agile methods encompass two main perspectives: the technical and the business perspective. By business perspective it is meant stakeholders’ standpoint. Both perspectives are tightly involved in the development process. Scrum, a well-known agile method for software project management will be used for the rest of this paper, as an example to illustrate agile methods. Scrum identifies three distinct roles: (1) Product owner: it is the development leader; a unique accountable role in the hands of the customer for the success of the project. (2) Development team: A self-organized and cross-functional group of developers. (3) Scrum Master: a facilitator responsible for the team adherence to the scrum process.
61
today’s challenges. ‘All the evidence shows that evolutionary processes can work for systems, large and small, and that risk seeking and mastering is the fastest route to fitness’ [9], [23]. On the other hand, scaling agile methods to large projects is something really challenging now. Before adopting such approaches, scalability issues should be solved adequately from technical and business standpoints.
Agile methods reinvent software development by encapsulating the development effort in the development team self-organization principle. In fact, requirements engineering, project management (planning, estimating), coding and testing are now performed by a self-organized team with no hierarchical constraints. The code is collectively owned and maintained. User stories are collectively identified and estimated. The just enough principle reduces any unnecessary effort towards over-optimization. Code refactoring is the key practice to keep the code clean. Continuous delivery of working software shows development progress. Tacit knowledge transfer is the main vehicle of communication. Whereas preplanned development seeks to avoid risks, evolutionary development harnesses nature and confronts risks.
3.1.3 Agile limitations in large-scale projects In scrum, agile development is possible through the adoption of ‘scrum of scrums’ approach. Figure 2 shows how organizing teams using this approach. Nevertheless, agile principles are called into question since they were initially set to accommodate small-medium projects.
3.1.2 Agile business perspective Currently, agile methods align development to business value by making business people and developers working together on a daily basis. The technical perspective of doing the product right is no longer a first-plan issue for agile methods. In fact, high level developers, continuous and automated testing, empirical development, collective ownership of the code, face-to-face collaboration and quick delivery are producing products of high quality. Nevertheless, agile development is considered chaotic [8], [22]. Only skilled and motivated individuals can guarantee successful results. That is, ‘great scrums need great product owners’ [14]. Conversely, today’s concern has switched to business issues such as: What is the right product? How to identify sources of value? Why building the software? How to reduce waste (unused features)? How to improve decision making? How to track value progress? How to guide the project efficiently to make dependable software? Even with an intensive-customer involvement, agile methods still struggle to avoid results such those illustrated in figure 2 on actual use of requested features. This phenomenon is best known as ‘the software bloat’ where applications are loaded with features that have questionable business value (figure 1). Answering to the previous questions will ensure responsive software, delay obsolescence, reduce waste, increase added value, and achieve real business goals.
Figure 2: Scaling approach for the scrum framework In figure 2, highlighted colors in lower levels indicate a representative in each team. The second level shows a team composed of all representatives from the level below and governed by a super-representative. The third level presents the governance committee that encompasses the three superrepresentatives. Here are some impediments expected when fulfilling agile principles in large projects as identified by Turk [26]: •
Limited support for distributed developments.
•
Limited support for sub-contracting.
•
Limited support for development involving large teams.
•
Limited support for developing safety-critical software.
•
Limited support for developing large, complex software.
Main reasons for such limitations could be summarized in two main categories tightly related to the applicability of agile practices in large-scale development: Co-location and Face-to-face collaboration issues (Requirement engineering problems): In a small scale project with a great product owner, this assumption could hold. In large projects, the product owner needs more reliable collaboration with its business sources to get better understanding and visibility on success-critical stakeholders needs. Then, he has to transfer and share that vision with many development teams. Extensive use of communication tools is currently used to simulate co-location but fully intended results cannot always been achieved. Furthermore, using more documentation to centralize knowledge is counter-
Figure 1 : Features use presented by Standish Group at the XP 2002 conference This evolutionary approach has been accepted widely in smallmedium projects for non-critical software systems. It has also been recognized [4], [9], [16] as the best approach to attack
62
opportunities to higher management. (4) Help him avoid chaotic software development due to scalability issues and miscommunication.
productive and unfeasible in agile terms as the project is continuously evolving. In other words, tacit knowledge limits scalability. New ways for playing the role of the product owner have to be explored. Weaknesses in the decision making process (governance problems): In large projects, conflicting stakeholders’ definitions of success make identification, valuation and prioritization of features very tedious. Dependency is very hard to achieve without further assistance. Clearly, rapid change makes it harder. Scrum makes the customer, by the mean of the product owner role, highly involved in the development process, assuming that he seizes enough power and knowledge to make decisions and guide the project. Even though, agile methods advocate they do the right software, they should admit that the product owner has trouble in prioritizing items in the product backlog. Most of the time, he is unable to stop the project and the team continue to produce software until the product backlog is empty. This situation leads inevitably to unused and/or inconsumable functions as illustrated in figure 1. Consequently, the agile team is acting more as a utility/commodity provider.
Figure 3 : B-Scrum: the business extension of the scrum framework To summarize, the new challenges facing agile development can be described by a twofold business perspective: •
4. Areas of improvements
Identifying
the
right
product:
Which
require
the
identification and prioritization of the right requirements
Clearly, there is an urgent need for quick and continuous delivery of valuable software before the business environment changes. Evolutionary development approaches are well fitted to such turbulent environment. Conducting large projects using an evolutionary development approach is more than scaling teams by using scrums of scrums as claimed by agile adepts. It is all about ensuring effective knowledge sharing and making the right decisions.
with regards to all stakeholders involved in the project. •
Project governance towards business value maximization: This require a deep understanding of business value and a continual guidance towards its maximization. It entails taking the right decisions based on reliable sources of information.
At the outset, it is believed that identifying success-critical stakeholders, analyzing and prioritizing their needs require a steering committee not a person. In small or medium projects, capturing requirements using tacit knowledge transfer is feasible. However in large ones, more attention should be paid at making sure that all teams share the same vision of the software. In fact, high management can support the product owner in leading the software development effort by providing him with appropriate tools or expertise to support the decision making process and software valuation. Such assistance, unlike the product owner is almost unavailable for day-to-day basis in an ideal agile environment.
Avenues on improving these two aspects of the scrum business perspective could be found in the use of goals in the Requirement Engineering (RE) processes and valuation of each delivery IT project governance fields.
5. Potential benefits behind the use of goals ‘Goals generally describe objectives which a system should achieve through cooperation of actors in the intended software and in the environment’ [17]. Goals may refer to functional or non-functional properties of a product and range from high level concerns to finer-grained ones. Goal-setting ideally involves establishing specific, measurable and time-targeted objectives. That is, goals should be SMART (Specific, Measurable, Achievable, Relevant, and Time-Specific) [13]. In specific sectors such healthcare or finance, many add ER to make SMARTER, where the E=Extendable R=Recorded. Work on the theory of goal-setting suggests that the use of goals can serve as an effective tool for making progress by ensuring that participants have a clear awareness of what they must do towards achieving a specific goal [10]. Goals have been used widely in software engineering and IT management for a variety of reasons. Next sub-sections will focus on their benefits in these respective fields.
An extension to the scrum process that increases stakeholders’ contribution to the development effort is needed (the extension could be called B-Scrum where the B stands for Business). The steering committee should share and maintain a common artifact that provides enough visibility on business expectations and sources of value during the evolution of a project. Hence, such valuation and decisions should come from the stakeholders’ side and should be fed by working software specialists as shown in figure 3. Such an extension is intended to empower the product owner with more visibility surrounding his involvement in the development process. In fact, there are many reasons for such an extension: (1) Help him understand the underpinning reasons behind the stakeholders’ expectations and solving any conflict situations. (2) Help him track the value progress and make decisions that reflect stakeholders’ interests with regard to the evolving business context. (3) Help him identify and report real business
5.1 GORE Goals have been used intensively in requirement engineering and the approach is best known as GORE (Goal-oriented Requirement Engineering). It has been utilized as a central concept in some RE frameworks as well as a supporting tool in others. Goals and hierarchy of goals are often used in early phases of a project. In
63
requirements) framework used non-functional requirements as goals to guide the design process [6].
these phases, goals are used to bring answers to how the intended system should meet organizational goals and why the system is needed and how the stakeholders’ interests may be addressed [32].
Dealing adequately with requirements is the first objective of the intended enhancement of the agile framework. Clearly, as described above, GORE showed real benefits in addressing this first set of issues. The second objective to seek now is about conducting the agile development project more efficiently. Decision making and software valuation are the key issues to overcome. The steering committee that make major project funding and governance decisions are often not familiar with iterative methodologies in software development [18]. However, their involvement in it is very similar to the one in IT service creation. IT management is a field tightly related to software development and from a business perspective a lot of similarities could be found.
In GORE, goals helped to address these issues [28]: •
Achieve requirements completeness: ‘Goals provide a precise criterion for sufficient completeness’ [30],[28]. Thereby, a specification can be labeled complete after consideration of a set of previously fixed goals.
•
Avoid irrelevant requirements: Also, goals provide a criterion for requirements pertinence. In fact, requirements that are not related to at least one goal are considered irrelevant [30],[28].
•
Explain requirements to stakeholders: It has been widely recognized that goals provide the rationale for requirements. Requirements in the system to-be are closely related to stakeholders’ goals that need to be achieved. Traceability provides a useful tool to link high-level organizational goals to low level system to-be functionalities [28], [31].
•
Increase readability of complex requirements documents through goal refinement [28].
•
Explore alternatives: using a top-down refinement, alternative solutions and sub-goals can be explored more easily and decision making can be improved [28], [29].
•
Manage conflicting situations: Differences in perception from stakeholders can be handled successfully using goals. It has been recognized that goals provide the roots for detecting and eventually solving conflicts among requirements [21].
•
•
•
•
5.2 IT Project governance IT governance is a relatively active field in trying to align IT goals with business goals. In fact, goals have been involved in IT governance through a well known framework: COBIT (Control Objectives for Information and related Technology) and more recently in Val IT, an extension to COBIT that focus on IT values. COBIT is based on established frameworks, such as the Software Engineering Institute’s Capability Maturity Model, ISO 9000, ITIL and ISO 17799. COBIT is a control and management framework rather than a process framework. Thereby, COBIT focuses on what an enterprise needs to do, not how it needs to do it. Hence, target audience for COBIT is senior business management, senior IT management and auditors [19]. The key roles of project governance can be summarized as follows according to the ISACA [12]:
Distinguish between stable and volatile information: Requirements are considered a way to satisfy one or more goals. High level goals are more likely to stay stable. While sub-goals and requirements can change as the system to-be evolves. Hence, stable requirements are captured and are clearly distinguished from volatile ones [1]. As observed by [28], different system versions often share the same high level goals. The current system and the system to-be correspond to alternative refinements of common goals. Identify system requirements: In a top-down refinement approach, goals drive the requirement elaboration process [15], [29]. In KAOS methodology, goals were used as a central concept for requirement acquisition [7]. Stakeholders’ requirements were very often revealed through the elaboration of the goal hierarchy. Relate requirements to organizational and business context: Recently, when systems are seen to provide solutions to businesses and organizational problems, the relationship between the system and its organizational environment are being expressed in goal-based relationship [33]. Derive design: It has been proved that goals can be used successfully in deriving and refining architectures [29] and for annotating design patterns [6]. Furthermore, goals have been used as an important mechanism for connecting requirements to design. The NFR (non-functional
64
•
Establish the basis for project governance, approval and measurement —including defining roles and accountabilities, policies and standards and associated processes.
•
Evaluate project proposals to select those that are the best investment of funds and scarce resources and are within the firm’s capability and capacity to deliver.
•
Define the ‘desired business outcomes’ (end states), benefits and value — the business measures of success and overall value proposition.
•
Control the scope, contingency funds, overall project value and so on
•
Monitor the project’s progress, stakeholder’s commitment, results achieved and the leading indicators of failure
•
Measure the outputs, outcomes, benefits and value — against both the plan and measurable expectations
•
Act to ‘steer’ the project into the organization, remove obstacles, manage the critical success factors and remediate project or benefit-realization shortfalls
•
Develop the organization’s project delivery capability — continually building and enhancing its ability to deliver more complex and challenging projects in less time and for less cost while generating the maximum value.
Practically, COBIT enables management to answer aforementioned IT governance issues that are also raised by steering committee in a software development project. Goals used as a central concept to leverage the governance in projects. Unfortunately, in the name of agility, similar issues not addressed adequately in agile projects.
valuable business goals first and then think about potential IT solutions. Prioritizing same level items is far easier than prioritizing the whole product backlog as in the linear form.
the the are IT are
(5) It is believed that business valued-goals can more effectively drive the development effort as a value-driven development approach [12]. In fact, features satisfying most valuable goals are more likely to be developed first. Then, if enough value is achieved at satisfying one goal, then a decision could be made to satisfy the next goal. Consequently, this could significantly decrease the number of features having a low contribution and help achieve the most valuable ones.
6. A goal and value oriented approach as a potential avenue The wicked nature of business value and the empirical nature of the agile development process make it hard to adopt the current large-scale version of agile methods as is. Firstly, the business standpoint should be enhanced with better coverage on real success-critical stakeholders’ needs along with an agile way to deal with them. Secondly, decision making for project governance purpose should be based on business value rather than the intuition of a single person. Thus, it is concluded that, involving the customer in day-to-day development activities would only cope with the top of the iceberg and need a substantial enhancement.
7. Conclusions and future work Large-scale projects are failing at an alarming rate. These projects could not deliver the functions needed [9]. Misunderstanding stakeholders’ needs is amongst the main issues that cause software to deliver minimal added-value levels. Large software-intensive projects are challenged by the new business reality of today’s organizations. Traditional software engineering assumptions do not hold on anymore. Thus, evolutionary software development will eventually prevail over plan-driven development to tackle today’s business issues.
As explained in the previous section, goals refined in a hierarchical structure were used successfully in solving similar issues to those raised by the current business perspective dilemma in large-scale projects. Consequently, avenues of improvement can be found in these two fields, namely: GORE and IT governance. Thus we recommend the use of goals to tackle the twofold business perspective in agile projects and shape the new proposed extension.
Currently, the product owner, real accountable role in Scrum, is normally familiar with his business domain but he is ill-equipped to assess correctly the real business value of every feature and cope with every stakeholder’s expectations. As a consequence, too often, the agile project ends when the product backlog is empty which leads inevitably to unused or rarely used features due to their irrelevance to business. Scalability issues increase the level of difficulty since agile methods lie on face-to-face communication to transfer knowledge.
The objective of using goals and value to enhance the scrum framework goes far beyond the simple representation of stakeholders’ business needs. At this level of progress, some assumptions on how to use goals to achieve such improvement are presented. These statements are to be validated in future research works:
Using a goal-value oriented approach as a vehicle of communication, elicitation and management provides avenues in adopting agile methods for large projects with unstable environments by improving the requirements and governance aspects of the business perspective. Similar issues identified in this work were addressed successfully in GORE and IT governance by using goals as a central concept. These proofs support the beliefs that the use of a goal and value oriented approach would enhance the business perspective. The present paper focuses on motivations behind the enhancement of the scrum’s business perspective. It shows potential benefits in adopting a goal oriented approach to tackle current issues. Future research works will be dedicated to establishing the foundation of an extension of Scrum based on goals, validate it and present its real benefits and limitations.
(1) Stakeholders can express their expectations in terms of goals (a language they are more familiar with). Conflicting goals can then be identified and handled in a holistic view. Languages, such as GRL, can be used to reduce the level of ambiguity [27]. (2) Linking low level requirements such as user stories and features (technical perspective) to medium level or tactic goals and strategic goals (business perspective) becomes a necessity for large projects. This would permit to set a hierarchical product backlog in contrast with the current linear product backlog. We believe that the new form of the product backlog could bring better visibility to the project and covers both of its perspectives, business and technique. Linking high level goals with low level requirements provides an alternative way to share knowledge across teams in a more agile and maintainable way than software documentation can do due to the inherent technical details.
8. ACKNOWLEDGMENTS Our thanks to Hakan Erdogmus, François Beauregard and Maurice Bergeron for their valuable contributions.
(3) Redirecting the measure of success of a project from working software to achieving business goals is a better candidate to represent the overall success of a project. Furthermore, by the use of goals map traceability, it is believe that the development team can show progress not only in terms of working software but also in terms of goal’s satisfaction that represents potential sources of business value.
9. REFERENCES [1] Anton, A.I, McCracken, W.M., ‘Goal decomposition and scenario analysis in business process Reengineering’, Proc. CAISE’94, Springer-Verlag,1994 [2] Bandler R., Get the Life You Want: The Secrets to Quick and Lasting Life Change with Neuro-Linguistic Programming, hcibooks, 2008
(4) Prioritizing goals relatively at each level, using simple techniques like 100$ [1], allows stakeholders to identify the most
65
[3] Baskerville,R.,‘Is Internet-speed Software Development different?’, IEEE Software 2003.
[19] Project governance, http://en.wikipedia.org/wiki/ Project_governance,[Online], [sited on January 2009]
[4] Bohem, B., ‘Making a difference in the software century’, IEEE computer society, 2008
[20] Reifer, D., ‘Making the software Business case: improvement by the numbers’, SEI series , 2001
[5] Charette,R., ‘Why software fails?’, IEEE spectrum, [online], [sited December 26, 2008]
[21] Robinson, W.N, ‘Integrating multiple specifications using domain goals’, Proc. IWSSD-5, 5th Intl.Workshop on software specification and design, IEEE 1989
[6] Chung, L., Nixon, B., Yu, E., ‘Non functional requirements in software engineering’, Klwer academic, Boston, 2000.
[22] Shore, J., ‘The art of agile development’, O’reilly, 2008
[7] Dardenne,A., Van Lamsweerde and S.Fickas, ‘ GoalDirected Requirements Acquisition’, science Computer programming, 1993.
[23] Schuh P., ‘Integrating Agile Development in the Real World’, Charles River Media , 2005 [24] Schwaber, K., The enterprise and SCRUM, Microsoft Press, 2007
[8] DeCarlo, D., ‘Extreme project Management: Using Leadership, Principles and tools to deliver Value in the face of volatility’, Jossey-bass Wiley , 2004
[25] Sikka, V., ‘Maximizing ROI on software development’, AUERBACH, 2005
[9] Denning, P., ‘The profession of IT: Evolutionary System Development’, Communications of the ACM, December 2008.
[26] Turk, D., France,R., Rumpe, B., ‘Limitations of agile software processes’, [27] Van Lamsweerde, A., ‘Goal-oriented requirements Engineering: A roundtrip from research to practice’, 12th IEEE International requirements Engineering Conference, Kyoto, September 2004
[10] Goal-setting theory, http://en.wikipedia.org/wiki/GoalSetting_Theory, [Online] [sited on January 2009] [11] Highsmith,J.,CockburnA., ‘Agile software development: The business of innovation’, IEEE software, 2001
[28] Van Lamsweerde, A., ‘Goal-oriented requirements Engineering: A Guided tour’, 5th IEEE International Symposium on requirements Engineering, toronto, August 2001
[12] ISACA,http://www.isaca.org/Content/NavigationMenu/Mem bers_and_Leaders/COBIT6/Obtain_COBIT/CobiT4.1_Broch ure.pdf ,[Online] [sited on January 2009]
[29] Van Lamsweerde, A., ‘Requirements engineering in the year 00: a research perspective’, ICSE 2000,22nd International conference on software engineering, ACM Press, 2000
[13] ITIL v3, http://www.itil-officialsite.com/home/home.asp, [Online] [sited on January 2009] [14] Judy, K.H., ‘Great scrums need great Product owners: Unbounded collaboration and collective Product Ownership’, Proceedings of the 41st Hawaii International Conference on system sciences, 2008
[30] Yue, K., ‘What Does It mean to say that a specification is complete?’, Proc.IWSSD-4, Fourth International Workshop on software Specification and Design, Monterey, 1987.
[15] Kaindel, H., ‘A design process based on a model combining scenarios with goals and functions’, IEEE Trans. On Systems, Man and cybernetic, 2000
[31] Yu ESK., ‘Modeling Organizations for information systems Requirements Engineering’, Proc. RE’93-1st International symposium on requirements Engineering, IEEE, 1993.
[16] Kessler, C., ‘Outside-in Software Development: A Practical Approach to Building Successful Stakeholder-based Product’, IBM press 2008
[32] Yu, E., ‘Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering’, IEEE, 1997 [33] Yu,E., Mylopolous,J., ‘Why goal-oriented requirements Engineering’, Proceedings of the 4th International Workshop on Requirements Engineering: Foundations of Software Quality, 1998
[17] Liu, L., and E. Yu, ‘Designing information systems in social context: a goal and scenario modeling approach’, Elsevier Ltd, 2003 [18] Lines,M., ‘Effective governance practices for iterative software development projects’, Rational Edge, 2005
66
