INTRODUCING AGILE SOFTWARE DEVELOPMENT AT SAP AG

Change Procedures and Observations in a Global Software Company

Joachim Schnitter and Olaf Mackert

SAP 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 development

processes from a waterfall-like approach to agile methodologies. This change affects about 18,000 developers

working at 12 global locations. The paper outlines the procedure to introduce Scrum as an implementation of

lean development, and the model chosen to scale Scrum up to large product development projects. The most

important observations are described, and an outlook on future improvement is given.

1 INTRODUCTION

Agile methodologies have proven to offer many bene-

ﬁts when developing user-centric software. Early

ﬁndings about how to optimize product development

led to iterative processes stressing prototyping and

early feedback (Takeuchi and Nonaka, 1986). Agile

project 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 approach

which focuses on early delivery of partial functional-

ity. In combination with regular feedback from users

and stakeholders a software development project con-

verges into something useful without the exact goal

being known beforehand. Strict prioritizing of all

requirements ensures that risks remain low. Even a

project that was cancelled because of time and budget

constraints may nevertheless have delivered a useful

result if the essential requirements were implemented

by the time the project was cancelled.

Scrum is known to work well in teams of up to

around 10 people programming for a customer on

the basis of a project contract. How well can Scrum

perform in a global software company with thou-

sands of developers in various locations working on

a few dozen highly complex software products? This

paper describes some of the experiences gained dur-

ing the change process at SAP AG, the world’s

leading producer of enterprise software, transitioning

from a waterfall-like overall process model to an ag-

ile development model that incorporates the values of

lean 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 before

introducing Scrum throughout the development orga-

nizations. In the ﬁfth section we describe the steps

taken to introduce lean development. In the sixth sec-

tion the model chosen to scale Scrum up to very large

development projects is described. The ﬁnal section

summarizes the results and observations.

2 SAP BEFORE LEAN

DEVELOPMENT AND SCRUM

SAP, founded in 1972, offers a portfolio of enterprise

applications around its ﬂagship, the SAP Business

Suite. 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 the

making. With the acquisition of Business Objects SA

in 2008 SAP gained access to user-centric analytics

products which have since been fully integrated into

SAP’s traditional product line but still are available

separately.

In its ﬁrst two decades SAP developed software

for and together with its customers. This close co-

operation helped focus on business essentials, keep

pace with business and technology trends, and even-

132

Schnitter 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-138

DOI: 10.5220/0003000601320138

 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 regular

contact with customers and users in different roles,

not only as programmers but also as consultants,

trainers, and support engineers. The success of R/3

reshaped the market for business applications. For

newer customers R/3 was no longer a system they had

helped to develop but a product they wanted to in-

stall, conﬁgure and run, despite the particularities of

their business processes. Demand shifted from more

business functionality to a higher degree of conﬁg-

urability, easier lifecycle management, and solutions

covering only parts of the R/3 application suite with

more detail and speciﬁcity.

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 time

growth started slowing most developers had become

experts on a particular technology or application area.

Specialization increased in parallel with division of

labour. By now there were experts working on re-

quirements roll-in, other experts working on detailed

requirements speciﬁcations, yet others laying out the

basic functions and algorithms, programming, test-

ing, and so on. By 2001 it had become clear that

issues with communication among the specialized

teams, departments, organizations were becoming a

major cause of reduced product quality on many lev-

els. To overcome these problems SAP introduced a

development 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 and

skills overall leading to a waterfall-like process model

with handover procedures among the involved parties.

This process model was traversed once per year by

most development departments which resulted in new

products or major product versions each year.

When agile methodologies gained broader public

interest around 2004 some teams at SAP started to

experiment 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 project

management practices were ﬁrst used in prototype de-

velopment with strong customer involvement.

3 PILOT PHASE

In 2006 SAP formed a small team to explore agile

practices in depth by educating and supporting devel-

opment teams interested in Scrum. Within two years

it was possible to run around 120 projects accord-

ing to the Scrum methodology. During this time the

expert 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 early

teams displayed scepticism due to personal attitude,

each project team had to approve its participation in

the 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 included

an in-depth analysis of project setup, risks, and

interdependencies with other teams.

• A four-hour in-depth training for Scrum masters

and product owners.

Each person in the expert team supported a number of

pilot teams for some months as a Scrum mentor. This

support included participation in all sprint planning

and review meetings, retrospectives, help with tools,

and advocating Scrum before development manage-

ment. Additionally mentors tried to track and resolve

all issues the teams had either internally or with other

teams, organizations, and management.

After eight months of direct team support the

Scrum expert team started offering trainings for fu-

ture Scrum mentors. Mentor training took one week

and included in-depth Scrum knowledge, team dy-

namics, and selected areas of software engineering,

e. g. requirements management. A prerequisite for

the mentor training was experience with Scrum ei-

ther as a Scrum master or product owner. Training

included Scrum master certiﬁcation by the Scrum Al-

liance. The teaching team consisted of the Scrum ex-

pert team, a psychologist, and a practitioner from the

Scrum Alliance.

After one year there were 25 mentors available.

By September 2008 these mentors had supported

about 120 projects in 10 global development loca-

tions.

3.2 Project Management Tools

When the Scrum expert team started its work, few

project management software systems were available

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

Software Company

133

which supported Scrum. They all lacked sub-project

support, hierarchical backlog management, and inter-

faces for inclusion into SAP’s toolchain, e. g. to the

requirements database, issue tracker, and test manage-

ment systems. Therefore SAP decided to extend its

own product for project management, SAP cProjects,

to support Scrum projects. This extension project was

also a showcase for Scrum with direct involvement of

users because the system was to be used internally. A

member of the Scrum expert team took on the role of

the product owner.

3.3 Lessons Learned

A wiki was used to manage basic information and ob-

servations. For each pilot team the following data

were collected by the Scrum mentors: scope of the

project, duration, product owner, scrum master, de-

pendencies with other teams, locality, critical deci-

sions and impediments, and other observations. These

data were used to select and communicate best prac-

tices, create a network of Scrum masters and product

owners, and set up a round table of experienced prac-

ticioners. In-depth interviews with Scrum masters,

product owners, and team members provided valuable

information and suggestions for improvement.

Scrum gives teams more power to make decisions

concerning development speed and quality. These as-

pects led to wide acceptance among teams. On the

other hand many individuals felt that they were being

monitored exessively as a result of the high degree

of interaction both within the team and with external

individuals and organizations. The predominant argu-

ments against Scrum were:

• Team member: “Scrum forces me to report to the

team every failure and impediment. This puts me

under pressure.”

• Team member: “I work more effectively when

working alone. Daily Scrum meetings force me

to interrupt my work.”

• Team member: “My manager might get a wrong

impression of my work in case someone reports

how slow my work progresses.”

• Development manager: “I have no insight into the

team’s work. Appearently nobody monitors what

is going on.”

• Other teams: “We cannot rely on teams which

do not deliver according to an agreed-upon sched-

ule.”

Most resistence of team members was removed by

pointing out that the transparency of activity within

the 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 to

monitor itself. Sceptics from management were in-

vited to sprint planning and review meetings. They

were regularly impressed by the teams’ skills in plan-

ning all activities with great detail, focusing on risk

management and high product quality.

What could not be mitigated were issues with

teams dependent on “unreliable” Scrum teams, at

least if the Scrum teams were isolated in a non-Scrum

environment. Scrum teams working jointly on a par-

ticular software product rarely had complaints about

unreliable delivery because they were familiar with

the Scrum methodology and ﬁgured out how to get

their requirements added to other teams’ backlogs and

with 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 reluctance

to set up new distributed project teams:

• Project kick-off meetings with all team members

brought together in one location were considered

to be essential.

• Neither telephone nor video conferencing systems

could produce the feeling of proximity which was

necessary to maintain team spirit.

• Oral communication was burdensome because in

every location English was spoken with a local ac-

cent.

• Timezone differences of more than three hours

made it difﬁcult to agree on a common time for

the daily Scrum meeting.

• Multicultural teams typically broke up within two

months 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 usage

but became visible in this context. Teams tended to

relate problems to Scrum usage, but deeper analysis

showedthat these issues had existed in the same teams

before or could be observed in non-Scrum teams as

well. This showed the high potential of Scrum to ex-

pose problem areas which otherwise would have gone

unidentiﬁed or had been hidden intentionally.

3.4 Other Issues

Around the same time some problems surfaced which

were not connected to Scrum usage but needed to be

resolved 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 ensure

a common understanding of development goals.

Product management often was unable to com-

municate product requirements to software engi-

neers. Languages and notations differed signiﬁ-

cantly.

• The role of software architecture (high-level de-

sign) was not yet well understood. This led

to increased dependencies among products and

components, e. g. because componentization was

weak and code reuse was highly valued. Another

result was the lack of conceptual preparation for

the development teams for whom there were too

many obstacles to harmonize on interfaces and ad-

here to delivery timelines.

To overcome both problems a team was formed to

provide education on software architecture for devel-

opers, software architects, and product management.

A simple modeling language was created by com-

bining selected Uniﬁed Modeling Language (UML)

elements with diagram types from the Fundamen-

tal Modeling Concepts (FMC) notation (Keller and

Wendt, 2003; Kn¨opfel et al., 2006). FMC block di-

agrams in particular have proven to be an immense

help to communicate technical concepts to customers,

product managers, and developers. In parallel SAP

revised its internal quality standards and added rules

for component separation and usage.

4 DEVELOPMENT PROCESS

REFORM, ROUND ONE

A major revision of the standard development pro-

cess took place while the Scrum expert team was still

running pilot projects. Early experiences with Scrum

came to the attention of management who ordered a

reform of the development process framework to in-

volve customers and users more directly. The “re-

form” team which included the members of the Scrum

expert team deﬁned three process models for different

product 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 mean

e. g. adaptions to changed legal requirements or

newer technical standards. An important criteria

for 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 includes

Scrum 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 business

case must exist as a basis for a development deci-

sion.

Research. This process model is used basically for

research and prototyping projects. These projects

are 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 process

model according to certain factors, e. g. software type

(infrastructure, UI, business logic etc.), project size,

product development or customer-speciﬁc develop-

ment, architecture constraints (from-scratch product

development, product extensions, major refactoring,

and renovation).

5 INTRODUCING LEAN

DEVELOPMENT

From industry customers who had long-standing ex-

perience with lean production and the Toyota produc-

tion system (TPS) and from talks and publications

by Mary and Tom Poppendieck (Poppendieck and

Poppendieck, 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 Scrum

is particularily well suited to implementing lean soft-

ware development.

• Scrum’s iterative cycles, called sprints, implement

takt, i. e. the cyclic, repetitive work approach.

• The pull principle of TPS (often discussed in con-

junction with Kanban) can be found in Scrum in

two places: (i) When planning a sprint the team

“pulls” only so many requirements from the prod-

uct backlog as can be fulﬁlled during the next

sprint. Scrum does not allow for asking for more

than the team promises. (ii) Each team member

picks tasks from the sprint backlog when he or

she sees ﬁt. No manager assigns tasks to a team

member.

• The Genchi Genbutsu (go and see for yourself)

principle is reﬂected 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 Global

Software Company

135

• The Kaizen principle of continuous improvement

is put into practice by regular retrospectives and

the Scrum master’s role to collect and communi-

cate impediments and ideas for improvement to

stakeholders.

In every major SAP development area (2000 to 5000

developers per area) a lean implementation team was

set up to explore what had to be done to implement

lean development processes. One team took over the

pilot role by implementing their process model six

months earlier thereby gaining experiences to share

with the other teams. These teams applied Scrum to

their own change management projects.

It is worth to note that the pull principle had been

in use at SAP for software conﬁguration management

for years. Change (delta) propagation from a devel-

opment codeline to a test or consolidation codeline

was usually done by a responsible person pulling the

changes into the target codeline. This process was

implemented for ABAP (SAP’s proprietary applica-

tion programming language) around 1990. For source

code 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 for

master 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 of

Scrums, hierarchical backlog, hierarchy of product

owners. Many insights were gained in these projects

which proved beneﬁcial to applying Scrum to multi-

team projects at SAP (Kowark et al., 2010).

5.2 Education

A one-day “lean awareness” training provided the

background of the lean development approach. This

training described the basic principles of lean produc-

tion and development. People who attended the train-

ing frequently commented that the knowledge about

lean production was helpful to understand customer

needs better, but the relationship between lean de-

velopment and software development needed clariﬁ-

cation. The authors regard the latter comments as a

strong indication of the difﬁculties of applying strict

business principles to the learning process that is an

inherent feature of software development.

To scale Scrum up fast to an entire organization

Scrum mentors were trained by the existing Scrum

mentors who had at least 1.5 years experience with

Scrum in various contexts. This training was similar

to the mentor trainings given earlier.

Scrum mentors held training courses for develop-

ment teams, product owners, and Scrum masters. In

order 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 could

not resolve themselves. These teams have to deal

with both technical development problems and issues

resulting from the new lean development approach.

Therefore no limits are imposed on the types of prob-

lems communicated. These continuous improvement

teams are also responsible for idea management in

each area and serve as escalation contacts for Scrum

masters.

6 SCALING SCRUM TO THE

MAX

Scaling agile software development processes is still

subject to research (Eckstein and Josuttis, 2004; Leff-

ingwell, 2007; Ambler, 2009). Several approaches

are known to co-ordinate the work of severat Scrum

teams working on one product, e.. Scrum of Scrums

or 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 of

multiple Scrum teams and to communicate the re-

quirements via team product backlogs, various ap-

proaches were combined. Special product teams were

formed for this purpose. These teams can be regarded

as both a permanent Scrum of Scrums and a supervi-

sory product owner.

6.1 Product Teams

Product teams introduce a second organizational layer

above the Scrum teams. A product team is responsi-

ble for the work of up to 7 development teams. It

consists of the product owners of those teams and the

same number of team members who are specialists

in particular ﬁelds. Depending on the problem area

other experts may be included. This allows for full

engineering coverage of all problem areas expected,

well-organized communication among the teams, and

direct 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 by

development team members. For a product team to

function properly, the following prerequisites have to

be 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 the

product. 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,

• Deﬁnition of the skill proﬁles, size, and numbers

of 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 seven

Scrum teams. If the products or components are be

too big or too complex to be developed in this orga-

nizational setup, an intermediate organizational layer

is inserted between the product team and the Scrum

teams. These teams are called “area product teams”.

Their responsibility is the same as the product teams’

responsibility with the exception of budget and ﬁnal

product decisions. In this three-layer organization a

product team works similar to a project management

ofﬁce. The complete budget and product responsi-

bility is with the product team, while the operational

day-to-day decisions are handled by the area product

teams.

7 CONCLUSIONS AND

OUTLOOK

The Scrum project management methodology has

gained wide acceptance at SAP. Most teams consider

Scrum their method of choice. Employees who know

SAP from its early days call it a dej vu although

direct customer involvement in current development

projects is very limited.

Scaling Scrum to a multi-team development orga-

nization is not as easy. Scrum of Scrums and backlog

preparation 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 tend

to 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 and

testers (about 25), general management (about 10).

We believe that a three-level hierarchy of teams

to manage requirements for product backlog gener-

ation makes the ﬂow of information slow enough

to lose the feeling of agility. Currently the high

complexity of SAP’s products which is reﬂected

in 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 rigorous

breakup of SAP’s product lines into separate com-

ponents to ensure that no product component needs

more resources than the 130 people as calculated

above.

A signiﬁcant budget of time and money for ed-

ucation is mandatory when switching to Scrum. We

observed some effects of reduced training efforts after

a few months: Teams which worked overtime instead

of reducing their workload, Scrum masters who did

not feel empowered to communicate problems, prod-

uct owners who prepared unfeasible product backlogs

were some of the consequencesfound. As Scrum may

require a dramatic change in attitudes towards work,

management, leisure time, controlling, and reporting

the mentorship model applied at SAP is a powerful

means 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 Global

Software Company

137

ent rigor we could see signiﬁcant differences in Scrum

adoption and acceptance among the areas.

To learn about the effects of lean development as

implemented at SAP, the company chose to partici-

pate in the DIWA-IT study about health protection in

the IT industry sponsored by the German Bundesmin-

isterium fr Bildung und Forschung and the European

Union. An ongoing research project is scheduled to

examine long-term effects.

We expect that after each product release the

maintenance effort will increase for a couple of

years when a new product gets widely adopted by

customers. As discussed in a recent case study this

maintenance effort requires additional considerations

when creating the product backlog (Vlaanderen et al.,

2009). We consider the “competition” between new-

product development and old-product maintenance

a challenge to the long-term acceptance of Scrum

at SAP. To counterbalance this effect organizational

measures might be advisable.

Introducing lean development is a learning pro-

cess which brings many problem areas to light. Many

observations made at SAP would not have been made

in the old environment. It is still too early to assess the

beneﬁts of the ongoing change in completeness, but

the transparency of the development processes and

the broad acceptance of agile methods gained make

the change a worthwile effort. In addition to Scrum

SAP is in the process of applying more and more of

the 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 SAP

used for about 10 years, the authors found that the

biggest disadvantage of that model is not that it makes

it impossible to correct errors at a later stage, but the

strong impact the model has on organizationand com-

munication. The waterfall model suppresses commu-

nication along its path. Experts for one phase only

communicate with experts for other phases through

highly formalized documents and status data. Infor-

mal communication is regarded as undermining the

model’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 while

moving forward. In particular we wish to name

Martin Fassunge, Alexander Gerber, Bernhard Grne,

Christiane Kuntz-Mayr, Christian Schmidkonz, and

Jrgen Staader whose contributions were outstanding.

We also would like to thank Jrgen Mller of the Hasso

Plattner Institute for his support to run the Scrum scal-

ing experiments.

REFERENCES

Ambler, S. W. (2009). Scaling agile software development

through lean governance. In SDG ’09: Proceedings

of the 2009 ICSE Workshop on Software Development

Governance, pages 1–2, Washington, DC, USA. IEEE

Computer 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 towards

architecture-centric system development. In ECBS,

pages 173–182. IEEE Computer Society.

Kn¨opfel, A., Gr¨one, B., and Tabeling, P. (2006). Funda-

mental Modeling Concepts: Effective Communication

of IT Systems. John Wiley & Sons, Chichester, UK.

Kowark, T., M¨uller, J., M¨uller, S., and Zeier, A. (2010).

An educational testbed for large-scale agile software

development processes. to be published.

Lefﬁngwell, D. (2007). Scaling Software Agility: Best

Practices for Large Enterprises (The Agile Software

Development 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, volume

3556 of Lecture 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 with

Scrum. Microsoft Press, Redmond, WA.

Schwaber, K. (2007). The enterprise and Scrum. Microsoft

Press, Redmond, WA.

Sutherland, J. (2005). Future of scrum: Parallel pipelining

of sprints in complex projects. In ADC ’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 reﬁnery: Applying

Scrum principles to software product management.

In 3rd International Workshop on Software Product

Management, Atlanta, Georgia, USA, September 1,

2009.

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

138