INTRODUCING AGILE SOFTWARE DEVELOPMENT AT SAP AGChange Procedures and Observations in a Global Software Company

Joachim Schnitter and Olaf MackertSAP AG, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

Keywords: Agile project management, Lean development, Scrum, Large-scale Scrum.

Abstract: This paper describes the change process that is taking place at SAP AG to move the software developmentprocesses from a waterfall-like approach to agile methodologies. This change affects about 18,000 developersworking at 12 global locations. The paper outlines the procedure to introduce Scrum as an implementation oflean development, and the model chosen to scale Scrum up to large product development projects. The mostimportant observations are described, and an outlook on future improvement is given.

1 INTRODUCTION

Agile methodologies have proven to offer many bene-fits when developing user-centric software. Earlyfindings about how to optimize product developmentled to iterative processes stressing prototyping andearly feedback (Takeuchi and Nonaka, 1986). Agileproject management methods, e. g. Scrum (Schwaber,2004; Schwaber, 2007), take into account that prod-uct development is essentially a learning process.Long-term planning based on product requirements,which appear rock-solid but are in reality merely edu-cated guesses, is substituted by an iterative approachwhich focuses on early delivery of partial functional-ity. In combination with regular feedback from usersand stakeholders a software development project con-verges into something useful without the exact goalbeing known beforehand. Strict prioritizing of allrequirements ensures that risks remain low. Even aproject that was cancelled because of time and budgetconstraints may nevertheless have delivered a usefulresult if the essential requirements were implementedby the time the project was cancelled.

Scrum is known to work well in teams of up toaround 10 people programming for a customer onthe basis of a project contract. How well can Scrumperform in a global software company with thou-sands of developers in various locations working ona few dozen highly complex software products? Thispaper describes some of the experiences gained dur-ing the change process at SAP AG, the world’sleading producer of enterprise software, transitioningfrom a waterfall-like overall process model to an ag-

ile development model that incorporates the values oflean development and production.

In the following section we will outline the situa-tion at SAP before the introducton of agile develop-ment. The third section describes the activities dur-ing and results of the pilot phase. The fourth sec-tion gives a brief overview of process tailoring beforeintroducing Scrum throughout the development orga-nizations. In the fifth section we describe the stepstaken to introduce lean development. In the sixth sec-tion the model chosen to scale Scrum up to very largedevelopment projects is described. The final sectionsummarizes the results and observations.

2 SAP BEFORE LEANDEVELOPMENT AND SCRUM

SAP, founded in 1972, offers a portfolio of enterpriseapplications around its flagship, the SAP BusinessSuite. Many of these products are aimed at large com-panies, although products for small and medium busi-nesses have been available for some time or are in themaking. With the acquisition of Business Objects SAin 2008 SAP gained access to user-centric analyticsproducts which have since been fully integrated intoSAP’s traditional product line but still are availableseparately.

In its first two decades SAP developed softwarefor and together with its customers. This close co-operation helped focus on business essentials, keeppace with business and technology trends, and even-

132Schnitter J. and Mackert O. (2010).INTRODUCING AGILE SOFTWARE DEVELOPMENT AT SAP AG - Change Procedures and Observations in a Global Software Company.In Proceedings of the Fifth International Conference on Evaluation of Novel Approaches to Software Engineering, pages 132-138DOI: 10.5220/0003000601320138Copyright c© SciTePress

tually led to the fully developed client-server Sys-tem R/3 which supported all critical business func-tions for every major industry. Developers had regularcontact with customers and users in different roles,not only as programmers but also as consultants,trainers, and support engineers. The success of R/3reshaped the market for business applications. Fornewer customers R/3 was no longer a system they hadhelped to develop but a product they wanted to in-stall, configure and run, despite the particularities oftheir business processes. Demand shifted from morebusiness functionality to a higher degree of config-urability, easier lifecycle management, and solutionscovering only parts of the R/3 application suite withmore detail and specificity.

Within a few years SAP’s development organi-zation grew from about 2,000 to over 18,000 devel-opers in various functions. In earlier days develop-ers were expected to be generalists, but by the timegrowth started slowing most developers had becomeexperts on a particular technology or application area.Specialization increased in parallel with division oflabour. By now there were experts working on re-quirements roll-in, other experts working on detailedrequirements specifications, yet others laying out thebasic functions and algorithms, programming, test-ing, and so on. By 2001 it had become clear thatissues with communication among the specializedteams, departments, organizations were becoming amajor cause of reduced product quality on many lev-els. To overcome these problems SAP introduced adevelopment process framework to co-ordinate devel-opment efforts throughout all involved organizations.Involvement and responsibilities were assigned to de-partments according to their primary activities andskills overall leading to a waterfall-like process modelwith handover procedures among the involved parties.This process model was traversed once per year bymost development departments which resulted in newproducts or major product versions each year.

When agile methodologies gained broader publicinterest around 2004 some teams at SAP started toexperiment with Extreme Programming and Scrum.This approach was not feasible for regular product de-velopment teams because they had no longer easy ac-cess to customers and users. Therefore agile projectmanagement practices were first used in prototype de-velopment with strong customer involvement.

3 PILOT PHASE

In 2006 SAP formed a small team to explore agilepractices in depth by educating and supporting devel-

opment teams interested in Scrum. Within two yearsit was possible to run around 120 projects accord-ing to the Scrum methodology. During this time theexpert team gained important insight into applicabil-ity, limiting factors, and resistance within the organi-zation.

Pilot teams were chosen by organizations accord-ing to their own interest. Since some of the earlyteams displayed scepticism due to personal attitude,each project team had to approve its participation inthe pilot program unanimously.

3.1 Education

Scrum education for pilot teams consisted of the fol-lowing elements:

• A two-hour introduction into motivation and prac-tices of Scrum for development managers.

• A six-hour training for the development team,Scrum master, and product owner. This includedan in-depth analysis of project setup, risks, andinterdependencies with other teams.

• A four-hour in-depth training for Scrum mastersand product owners.

Each person in the expert team supported a number ofpilot teams for some months as a Scrum mentor. Thissupport included participation in all sprint planningand review meetings, retrospectives, help with tools,and advocating Scrum before development manage-ment. Additionally mentors tried to track and resolveall issues the teams had either internally or with otherteams, organizations, and management.

After eight months of direct team support theScrum expert team started offering trainings for fu-ture Scrum mentors. Mentor training took one weekand included in-depth Scrum knowledge, team dy-namics, and selected areas of software engineering,e. g. requirements management. A prerequisite forthe mentor training was experience with Scrum ei-ther as a Scrum master or product owner. Trainingincluded Scrum master certification by the Scrum Al-liance. The teaching team consisted of the Scrum ex-pert team, a psychologist, and a practitioner from theScrum Alliance.

After one year there were 25 mentors available.By September 2008 these mentors had supportedabout 120 projects in 10 global development loca-tions.

3.2 Project Management Tools

When the Scrum expert team started its work, fewproject management software systems were available

INTRODUCING AGILE SOFTWARE DEVELOPMENT AT SAP AG - Change Procedures and Observations in a GlobalSoftware Company

133

which supported Scrum. They all lacked sub-projectsupport, hierarchical backlog management, and inter-faces for inclusion into SAP’s toolchain, e. g. to therequirements database, issue tracker, and test manage-ment systems. Therefore SAP decided to extend itsown product for project management, SAP cProjects,to support Scrum projects. This extension project wasalso a showcase for Scrum with direct involvement ofusers because the system was to be used internally. Amember of the Scrum expert team took on the role ofthe product owner.

3.3 Lessons Learned

A wiki was used to manage basic information and ob-servations. For each pilot team the following datawere collected by the Scrum mentors: scope of theproject, duration, product owner, scrum master, de-pendencies with other teams, locality, critical deci-sions and impediments, and other observations. Thesedata were used to select and communicate best prac-tices, create a network of Scrum masters and productowners, and set up a round table of experienced prac-ticioners. In-depth interviews with Scrum masters,product owners, and team members provided valuableinformation and suggestions for improvement.

Scrum gives teams more power to make decisionsconcerning development speed and quality. These as-pects led to wide acceptance among teams. On theother hand many individuals felt that they were beingmonitored exessively as a result of the high degreeof interaction both within the team and with externalindividuals and organizations. The predominant argu-ments against Scrum were:

• Team member: “Scrum forces me to report to theteam every failure and impediment. This puts meunder pressure.”

• Team member: “I work more effectively whenworking alone. Daily Scrum meetings force meto interrupt my work.”

• Team member: “My manager might get a wrongimpression of my work in case someone reportshow slow my work progresses.”

• Development manager: “I have no insight into theteam’s work. Appearently nobody monitors whatis going on.”

• Other teams: “We cannot rely on teams whichdo not deliver according to an agreed-upon sched-ule.”

Most resistence of team members was removed bypointing out that the transparency of activity withinthe team was necessary because it enabled the team

to manage its work independently. In order to be re-leased from management’s scrutinity the team has tomonitor itself. Sceptics from management were in-vited to sprint planning and review meetings. Theywere regularly impressed by the teams’ skills in plan-ning all activities with great detail, focusing on riskmanagement and high product quality.

What could not be mitigated were issues withteams dependent on “unreliable” Scrum teams, atleast if the Scrum teams were isolated in a non-Scrumenvironment. Scrum teams working jointly on a par-ticular software product rarely had complaints aboutunreliable delivery because they were familiar withthe Scrum methodology and figured out how to gettheir requirements added to other teams’ backlogs andwith the right priorities.

Globally distributed teams often successfully ap-plied Scrum although we were able to identify a num-ber of problem areas which increased the reluctanceto set up new distributed project teams:

• Project kick-off meetings with all team membersbrought together in one location were consideredto be essential.

• Neither telephone nor video conferencing systemscould produce the feeling of proximity which wasnecessary to maintain team spirit.

• Oral communication was burdensome because inevery location English was spoken with a local ac-cent.

• Timezone differences of more than three hoursmade it difficult to agree on a common time forthe daily Scrum meeting.

• Multicultural teams typically broke up within twomonths mainly because the role of the Scrum mas-ter is interpreted very differently among Euro-pean, Asian, and American people. A Scrum mas-ter from one culture found it hard to meet the ex-pections of team members from another culture.

Many issues were not directly related to Scrum usagebut became visible in this context. Teams tended torelate problems to Scrum usage, but deeper analysisshowed that these issues had existed in the same teamsbefore or could be observed in non-Scrum teams aswell. This showed the high potential of Scrum to ex-pose problem areas which otherwise would have goneunidentified or had been hidden intentionally.

3.4 Other Issues

Around the same time some problems surfaced whichwere not connected to Scrum usage but needed to beresolved before moving to Scrum on a large scale.

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

134

• Communication among product management,software architects, development teams, and qual-ity assurance was not strong enough to ensurea common understanding of development goals.Product management often was unable to com-municate product requirements to software engi-neers. Languages and notations differed signifi-cantly.

• The role of software architecture (high-level de-sign) was not yet well understood. This ledto increased dependencies among products andcomponents, e. g. because componentization wasweak and code reuse was highly valued. Anotherresult was the lack of conceptual preparation forthe development teams for whom there were toomany obstacles to harmonize on interfaces and ad-here to delivery timelines.

To overcome both problems a team was formed toprovide education on software architecture for devel-opers, software architects, and product management.A simple modeling language was created by com-bining selected Unified Modeling Language (UML)elements with diagram types from the Fundamen-tal Modeling Concepts (FMC) notation (Keller andWendt, 2003; Knopfel et al., 2006). FMC block di-agrams in particular have proven to be an immensehelp to communicate technical concepts to customers,product managers, and developers. In parallel SAPrevised its internal quality standards and added rulesfor component separation and usage.

4 DEVELOPMENT PROCESSREFORM, ROUND ONE

A major revision of the standard development pro-cess took place while the Scrum expert team was stillrunning pilot projects. Early experiences with Scrumcame to the attention of management who ordered areform of the development process framework to in-volve customers and users more directly. The “re-form” team which included the members of the Scrumexpert team defined three process models for differentproduct development types.

Improvement. This process model is used to im-prove existing products and for minor extensions.In the context of business software this can meane. g. adaptions to changed legal requirements ornewer technical standards. An important criteriafor this process model is that the project require-ments include few changes to implemented busi-ness processes, only minor changes to the user in-terface, and that no newer technologies need to be

added.

New Product. This model is chosen for new prod-ucts or major product extensions. It includesScrum as the project management method. Cus-tomer and user involvement is secured by appro-priate contracts, and a minimum number of cus-tomers has to be involved. A calculated businesscase must exist as a basis for a development deci-sion.

Research. This process model is used basically forresearch and prototyping projects. These projectsare mostly free to chose whatever tools and meth-ods they wish.

An important result of this approach was that it in-creased awareness of the need to tailor the processmodel according to certain factors, e. g. software type(infrastructure, UI, business logic etc.), project size,product development or customer-specific develop-ment, architecture constraints (from-scratch productdevelopment, product extensions, major refactoring,and renovation).

5 INTRODUCING LEANDEVELOPMENT

From industry customers who had long-standing ex-perience with lean production and the Toyota produc-tion system (TPS) and from talks and publicationsby Mary and Tom Poppendieck (Poppendieck andPoppendieck, 2005; Poppendieck and Poppendieck,2008) SAP management learnt about the lean devel-opment approach. This knowledge provided the busi-ness background for research into how lean develop-ment could be applied at SAP. It turned out that Scrumis particularily well suited to implementing lean soft-ware development.

• Scrum’s iterative cycles, called sprints, implementtakt, i. e. the cyclic, repetitive work approach.

• Thepull principle of TPS (often discussed in con-junction withKanban) can be found in Scrum intwo places: (i) When planning a sprint the team“pulls” only so many requirements from the prod-uct backlog as can be fulfilled during the nextsprint. Scrum does not allow for asking for morethan the team promises. (ii) Each team memberpicks tasks from the sprint backlog when he orshe sees fit. No manager assigns tasks to a teammember.

• The Genchi Genbutsu(go and see for yourself)principle is reflected by the product owner’s par-ticipation in sprint reviews at regular intervals.

INTRODUCING AGILE SOFTWARE DEVELOPMENT AT SAP AG - Change Procedures and Observations in a GlobalSoftware Company

135

• TheKaizenprinciple of continuous improvementis put into practice by regular retrospectives andthe Scrum master’s role to collect and communi-cate impediments and ideas for improvement tostakeholders.

In every major SAP development area (2000 to 5000developers per area) a lean implementation team wasset up to explore what had to be done to implementlean development processes. One team took over thepilot role by implementing their process model sixmonths earlier thereby gaining experiences to sharewith the other teams. These teams applied Scrum totheir own change management projects.

It is worth to note that the pull principle had beenin use at SAP for software configuration managementfor years. Change (delta) propagation from a devel-opment codeline to a test or consolidation codelinewas usually done by a responsible person pulling thechanges into the target codeline. This process wasimplemented for ABAP (SAP’s proprietary applica-tion programming language) around 1990. For sourcecode in other programming languages implementa-tion took place in 2007.

5.1 Academic Experiments

Before applying Scrum on a large scale some exper-iments were carried out by the Hasso Plattner Insti-tute, Potsdam (HPI). The HPI provides education formaster and bachelor degrees on software systems en-gineering. As part of their practical education stu-dents have to carry out a half-year software develop-ment project with about 50 students. These devel-opment projects were used to experiment with vari-ous approaches to upscaling Scrum, e. g. Scrum ofScrums, hierarchical backlog, hierarchy of productowners. Many insights were gained in these projectswhich proved beneficial to applying Scrum to multi-team projects at SAP (Kowark et al., 2010).

5.2 Education

A one-day “lean awareness” training provided thebackground of the lean development approach. Thistraining described the basic principles of lean produc-tion and development. People who attended the train-ing frequently commented that the knowledge aboutlean production was helpful to understand customerneeds better, but the relationship between lean de-velopment and software development needed clarifi-cation. The authors regard the latter comments as astrong indication of the difficulties of applying strictbusiness principles to the learning process that is aninherent feature of software development.

To scale Scrum up fast to an entire organizationScrum mentors were trained by the existing Scrummentors who had at least 1.5 years experience withScrum in various contexts. This training was similarto the mentor trainings given earlier.

Scrum mentors held training courses for develop-ment teams, product owners, and Scrum masters. Inorder to provide training for all teams in a short time,the time allocated for training was reduced.

5.3 Continuous Improvement

In each development area a team was formed to col-lect and resolve problems the individual teams couldnot resolve themselves. These teams have to dealwith both technical development problems and issuesresulting from the new lean development approach.Therefore no limits are imposed on the types of prob-lems communicated. These continuous improvementteams are also responsible for idea management ineach area and serve as escalation contacts for Scrummasters.

6 SCALING SCRUM TO THEMAX

Scaling agile software development processes is stillsubject to research (Eckstein and Josuttis, 2004; Leff-ingwell, 2007; Ambler, 2009). Several approachesare known to co-ordinate the work of severat Scrumteams working on one product, e.. Scrum of Scrumsor MetaScrum (Sutherland, 2005). The size and com-plexity of SAP’s products makes it necessary to con-sider these techniques. To co-ordinate the work ofmultiple Scrum teams and to communicate the re-quirements via team product backlogs, various ap-proaches were combined. Special product teams wereformed for this purpose. These teams can be regardedas both a permanent Scrum of Scrums and a supervi-sory product owner.

6.1 Product Teams

Product teams introduce a second organizational layerabove the Scrum teams. A product team is responsi-ble for the work of up to 7 development teams. Itconsists of the product owners of those teams and thesame number of team members who are specialistsin particular fields. Depending on the problem areaother experts may be included. This allows for fullengineering coverage of all problem areas expected,well-organized communication among the teams, anddirect communication with the development teams to

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

136

detect and mitigate risks. Typically the following ex-pert roles can be found in product teams:

• Chief product owner (responsible product man-ager),

• Product team Scrum master (facilitator),

• One or two software architects,

• Knowledge management and product documenta-tion,

• User interface designer,

• Stakeholder representative.

These roles may be taken by dedicated people or bydevelopment team members. For a product team tofunction properly, the following prerequisites have tobe met:

• Every member of the product team is also a mem-ber of one of the related Scrum teams.

• The product team has full responsibility for re-quirements scope, quality, and delivery of theproduct. Each product team has a budget includ-ing external and travel costs.

• No product team member is a line manager of an-other team member.

• All product team members are collocated.

The tasks of the product team include:

• Product and budget management,

• Definition of the skill profiles, size, and numbersof Scrum teams,

• Assigning product backlog items to Scrum teams,

• Collecting project status information,

• Synchronizing the work of the Scrum teams,

• Working closely with the continuous improve-ment teams,

• Requesting supportive actions in case of impedi-ments.

6.2 Area Product Teams

Product teams can rarely support more than sevenScrum teams. If the products or components are betoo big or too complex to be developed in this orga-nizational setup, an intermediate organizational layeris inserted between the product team and the Scrumteams. These teams are called “area product teams”.Their responsibility is the same as the product teams’responsibility with the exception of budget and finalproduct decisions. In this three-layer organization aproduct team works similar to a project management

office. The complete budget and product responsi-bility is with the product team, while the operationalday-to-day decisions are handled by the area productteams.

7 CONCLUSIONS ANDOUTLOOK

The Scrum project management methodology hasgained wide acceptance at SAP. Most teams considerScrum their method of choice. Employees who knowSAP from its early days call it a dej vu althoughdirect customer involvement in current developmentprojects is very limited.

Scaling Scrum to a multi-team development orga-nization is not as easy. Scrum of Scrums and backlogpreparation for many teams can be combined by prod-uct teams as outlined above. Looking at all known pa-rameters of agile project management at SAP we tendto say that not much more than 130 development em-ployees may be organized in that fashion. This num-ber sums up developers in 7 teams (max. 70 people),the product team (max. 16), development infrastruc-ture responsibles (about 10), quality assurance andtesters (about 25), general management (about 10).

We believe that a three-level hierarchy of teamsto manage requirements for product backlog gener-ation makes the flow of information slow enoughto lose the feeling of agility. Currently the highcomplexity of SAP’s products which is reflectedin the organizational structure of SAP’s develop-ment areas makes it impossible to drop one hier-archy level of project management. This observa-tion has triggered a discussion about a more rigorousbreakup of SAP’s product lines into separate com-ponents to ensure that no product component needsmore resources than the 130 people as calculatedabove.

A significant budget of time and money for ed-ucation is mandatory when switching to Scrum. Weobserved some effects of reduced training efforts aftera few months: Teams which worked overtime insteadof reducing their workload, Scrum masters who didnot feel empowered to communicate problems, prod-uct owners who prepared unfeasible product backlogswere some of the consequences found. As Scrum mayrequire a dramatic change in attitudes towards work,management, leisure time, controlling, and reportingthe mentorship model applied at SAP is a powerfulmeans to overcome early resistance and issues, col-lecting information about the teams’ Scrum adoption,and correcting mistakes. As different development ar-eas at SAP applied the mentorship model with differ-

INTRODUCING AGILE SOFTWARE DEVELOPMENT AT SAP AG - Change Procedures and Observations in a GlobalSoftware Company

137

ent rigor we could see significant differences in Scrumadoption and acceptance among the areas.

To learn about the effects of lean development asimplemented at SAP, the company chose to partici-pate in the DIWA-IT study about health protection inthe IT industry sponsored by the German Bundesmin-isterium fr Bildung und Forschung and the EuropeanUnion. An ongoing research project is scheduled toexamine long-term effects.

We expect that after each product release themaintenance effort will increase for a couple ofyears when a new product gets widely adopted bycustomers. As discussed in a recent case study thismaintenance effort requires additional considerationswhen creating the product backlog (Vlaanderen et al.,2009). We consider the “competition” between new-product development and old-product maintenancea challenge to the long-term acceptance of Scrumat SAP. To counterbalance this effect organizationalmeasures might be advisable.

Introducing lean development is a learning pro-cess which brings many problem areas to light. Manyobservations made at SAP would not have been madein the old environment. It is still too early to assess thebenefits of the ongoing change in completeness, butthe transparency of the development processes andthe broad acceptance of agile methods gained makethe change a worthwile effort. In addition to ScrumSAP is in the process of applying more and more ofthe developer-centered methods of Extreme Program-ming, e. g. test-driven development, pair program-ming, project metaphor, early code integration.

Looking back at the waterfall model that SAPused for about 10 years, the authors found that thebiggest disadvantage of that model is not that it makesit impossible to correct errors at a later stage, but thestrong impact the model has on organization and com-munication. The waterfall model suppresses commu-nication along its path. Experts for one phase onlycommunicate with experts for other phases throughhighly formalized documents and status data. Infor-mal communication is regarded as undermining themodel’s simplicity. Unfortunately this attitude de-stroys the only remaining risk mitigation strategy left:communication.

ACKNOWLEDGEMENTS

The change described in this paper could not be car-ried out without a solid fundament of determined col-leagues willing to accept delay and hardship whilemoving forward. In particular we wish to nameMartin Fassunge, Alexander Gerber, Bernhard Grne,

Christiane Kuntz-Mayr, Christian Schmidkonz, andJrgen Staader whose contributions were outstanding.We also would like to thank Jrgen Mller of the HassoPlattner Institute for his support to run the Scrum scal-ing experiments.

REFERENCES

Ambler, S. W. (2009). Scaling agile software developmentthrough lean governance. InSDG ’09: Proceedingsof the 2009 ICSE Workshop on Software DevelopmentGovernance, pages 1–2, Washington, DC, USA. IEEEComputer Society.

Eckstein, J. and Josuttis, N. (2004).Agile Softwareentwick-lung im Großen: Ein Eintauchen in die Untiefen er-folgreicher Projekte. dpunkt, Heidelberg, 1st edition.

Keller, F. and Wendt, S. (2003). FMC: An approach towardsarchitecture-centric system development. InECBS,pages 173–182. IEEE Computer Society.

Knopfel, A., Grone, B., and Tabeling, P. (2006).Funda-mental Modeling Concepts: Effective Communicationof IT Systems. John Wiley & Sons, Chichester, UK.

Kowark, T., Muller, J., Muller, S., and Zeier, A. (2010).An educational testbed for large-scale agile softwaredevelopment processes.to be published.

Leffingwell, D. (2007). Scaling Software Agility: BestPractices for Large Enterprises (The Agile SoftwareDevelopment Series). Addison-Wesley Professional,Boston, MA.

Poppendieck, M. and Poppendieck, T. (2005). Introduc-tion to lean software development. In Baumeister, H.,Marchesi, M., and Holcombe, M., editors,XP, volume3556 ofLecture Notes in Computer Science, page 280.Springer.

Poppendieck, M. and Poppendieck, T. (2008).Lean soft-ware development: An agile toolkit. The agile soft-ware development series. Addison-Wesley, Boston,MA.

Schwaber, K. (2004). Agile project management withScrum. Microsoft Press, Redmond, WA.

Schwaber, K. (2007).The enterprise and Scrum. MicrosoftPress, Redmond, WA.

Sutherland, J. (2005). Future of scrum: Parallel pipeliningof sprints in complex projects. InADC ’05: Proceed-ings of the Agile Development Conference, pages 90–102, Washington, DC, USA. IEEE Computer Society.

Takeuchi, H. and Nonaka, I. (1986). The new new prod-uct development game.Harvard Business Review,64:137–146.

Vlaanderen, K., Brinkkemper, S., Jansen, S., and Jaspers,E. (2009). The agile requirements refinery: ApplyingScrum principles to software product management.In 3rd International Workshop on Software ProductManagement, Atlanta, Georgia, USA, September 1,2009.

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

138