Knowledge Management and Creativity in Software Engineering

The Foundations of Agility

Broderick Crawford

1,2

, Claudio Le

on de la Barra

, Ricardo Soto

1,3

, Sanjay Misra

and Eric Monfroy

Pontiﬁcia Universidad Cat

olica de Valpara

ıso, Valpara

ıso, Chile

Universidad Finis Terrae, Santiago, Chile

Universidad Aut

onoma de Chile, Santiago, Chile

Federal University of Technology, Minna, Nigeria

LINA, Universit

e de Nantes, Nantes, France

Keywords:

Knowledge Management, Creativity, Software Engineering, Agile Methodologies.

Abstract:

Software development is a knowledge intensive activity and its success depends on knowledge and creativity

of the developers. In the last years the traditional perspective on software development is changing and agile

methods have received considerable attention. Among other attributes, the agilists claim that fostering knowl-

edge sharing and creativity is one of the keys to response to common problems and challenges of software

development today. The development of new software products requires the generation of novel and useful

ideas. The purpose of this paper is to provide an understanding of knowledge management and creativity in

relation with new software engineering trends. The implications of these ﬁndings are considered, and some

possible directions for future research are suggested.

1 INTRODUCTION

Software engineering is a knowledge intensive disci-

pline where its activities require the use and sharing

of knowledge between the stakeholders. Then a bet-

ter transfer and application of the knowledge aim to

foster the software processes, whether these are done

using traditional or agile approaches. In software or-

ganizations the knowledge held by the employees is

the main asset and software development projects de-

pends mostly on team performance: ”Software is de-

veloped for people and by people” (John et al., 2005).

But surprisingly, most of software engineering re-

search is technical and deemphasizes the human and

social aspects. By other hand, the traditional devel-

opment process of new products that is a fundamen-

tal part in the marketing, has been recently criticized

by Kotler and Tr

ıas de Bes (Kotler and Tr

ıas de Bes,

2004). They point out that fundamental creative as-

pects are not considered at all and as a consequence

this development is not useful, viable or innovative.

In this context, it is interesting to consider the new

proposals of agile methodologies for software devel-

opment in order to analyse and evaluate them at the

light of the existing creative expositions, mainly con-

sidering the teamwork practices.

The agile principles and values have emphasized

the importance of collaboration and interaction in

the software development and, by other hand, cre-

ative work commonly involves collaboration in some

form and it can be understood as an interaction be-

tween an individual and a sociocultural context (Sanz

and Misra, 2011). We believe that the innovation

and development of new products is an interdisci-

plinary issue (Takeuchi and Nonaka, 1986)(Nonaka

and Takeuchi, 1995), we are interested in the study of

the potential of new concepts and techniques to fos-

ter knowledge management and creativity in software

engineering (Gu and Tong, 2004) (Crawford et al.,

2012).

This paper is organised as follows: Section 2 is

dedicated to the presentation of Knowledge Manage-

ment. Section 3 presents the background and general

concepts on Creativity. Finally, in Section 4 we con-

clude the paper and give some perspectives for future

research.

2 KNOWLEDGE MANAGEMENT

One of the most widely accepted approaches to classi-

fying knowledge from a KM perspective is the Knowl-

265

Crawford B., León de la Barra C., Soto R., Misra S. and Monfroy E..

Knowledge Management and Creativity in Software Engineering - The Foundations of Agility.

DOI: 10.5220/0004447802650272

In Proceedings of the 15th International Conference on Enterprise Information Systems (ICEIS-2013), pages 265-272

ISBN: 978-989-8565-60-0

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

edge Matrix of Nonaka and Takeuchi (Nonaka and

Takeuchi, 1995). This matrix classiﬁes knowledge as

either explicit or tacit, and either individual or col-

lective. Nonaka and Takeuchi also proposes corre-

sponding knowledge processes that transform knowl-

edge from one form to another: socialisation (from

tacit to tacit, whereby an individual acquires tacit

knowledge directly from others through shared ex-

perience, observation, imitation and so on); exter-

nalisation (from tacit to explicit, through articulation

of tacit knowledge into explicit concepts); combina-

tion (from explicit to explicit, through a systematisa-

tion of concepts drawing on different bodies of ex-

plicit knowledge); and internalisation (from explicit

to tacit, through a process of learning by doing and

through a verbalisation and documentation of expe-

riences). Nonaka and Takeuchi model the process of

organisational knowledge creation as a spiral in which

knowledge is ampliﬁed through these four modes of

knowledge conversion (See Figure 1).

2.1 Knowledge Management in

Software Engineering

The main argument to Knowledge Management in

software engineering is that it is a human and knowl-

edge intensive activity. Software development is a

process where every person involved has to make a

large number of decisions and individual knowledge

has to be shared and leveraged at a project and orga-

nization level, and this is exactly what KM proposes.

People in such groups must collaborate, communi-

cate, and coordinate their work, which makes knowl-

edge management a necessity.

In software development one can identify two

types of knowledge: Knowledge embedded in the

products or artifacts, since they are the result of highly

creative activities and Meta-knowledge, that is knowl-

edge about the products and processes. Some of the

sources of knowledge (artifacts, objects, components,

patterns, templates and containers) are stored in elec-

tronic form. However, the majority of knowledge is

tacit, residing in the brains of the employees. A way

to address this problem can be to develop a knowledge

sharing culture, as well as technology support for

knowledge management. There are several reasons to

believe that knowledge management for software en-

gineering would be easier to implement than in other

organizations: technology is not be intimidating to

software engineers and they believe the tools will help

them do a better job; all artifacts are already in elec-

tronic form and can easily be distributed and shared;

and the fact that knowledge sharing between soft-

ware engineers already does occur to a large degree in

many successful software collaborative projects (Rus

and Lindvall, 2002)(Mentzas, 2000)(Apostolou and

Mentzas, 2003).

3 CREATIVITY

Creativity is deﬁned as the capacity to generate or rec-

ognize original, elaborated and useful ideas (Amabile,

1996). By self the creative is an act of knowledge

creation (Sung and Choi, 2012). Althoug the creativ-

ity can be approached from the individual’s perspec-

tive, its greatest potential and development is appre-

ciated at team level(Amabile, 1998)(Leenders et al.,

2003)(Gilson and Shalley, 2004)(Chen, 2006).

3.1 Creativity in Software Development

Software engineering is a knowledge intensive pro-

cess that includes some aspects of Knowledge Man-

agement and Creativity in all phases: eliciting re-

quirements, design, construction, testing, implemen-

tation, maintenance, and project management (John

et al., 2005). No worker of a development project

has all the knowledge required to fulﬁll all activities.

This underlies the need for communication, collabo-

ration and knowledge sharing support to share domain

expertise between the customer and the development

team (Chau et al., 2003).

The traditional approaches (often referred to as

plan-driven, task-based or Tayloristic), like the wa-

terfall model and its variances, facilitate knowledge

sharing primarily through documentation. They also

promote usage of role based teams and detailed plans

of the entire software development life-cycle. It shifts

the focus from individuals and their creative abili-

ties to the processes themselves. In contrary, agile

methods emphasise and value individuals and interac-

tions over processes. Tayloristic methods heavily and

rigorously use documentation for capturing knowl-

edge gained in the activities of a software project life-

cycle (Chau and Maurer, 2004). In contrast, agile

methods suggest that most of the written documen-

tation can be replaced by enhanced informal com-

munications among team members internally and be-

tween the team and the customers with a stronger em-

phasis on tacit knowledge rather than explicit knowl-

edge (Beck et al., 2001).

Since human creativity is thought as the source to

resolve complex problem or create innovative prod-

ucts, one possibility to improve the software develop-

ment process is to design a process which can stimu-

late the creativity of the developers. There are few

studies reported on the importance of creativity in

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

266

Combination

Epistemological

dimension

Externalization

Internalization

Explicit

knowledge

Socialization

Tacit

knowledge

Ontological

dimension

Individual

Group Organization Inter-organization

Knowledge level

Figure 1: Spiral of Organization Knowledge Creation.

software development. In management and business,

researchers have done much work about creativity and

obtained evidence that the employees who had appro-

priate creativity characteristics, worked on complex,

challenging jobs, and were supervised in a supportive,

noncontrolling fashion, produced more creative work.

Then, according to the previous ideas the use of cre-

ativity in software development is undeniable, but re-

quirements engineering is not recognized as a creative

process in all the cases (Maiden et al., 2004). In a few

publications the importance of creativity has been in-

vestigated in all the phases of software development

process (Gu and Tong, 2004)(Glass, 1995)(Craw-

ford and Le

on de la Barra, 2007)(Le

on de la Barra

and Crawford, 2007)(Crawford et al., 2008)(Craw-

ford and Le

on de la Barra, 2008) and mostly fo-

cused in the requirements engineering (Robertson,

2005)(Mich et al., 2005). Nevertheless, the use of

techniques to foster creativity in requirements engi-

neering is still shortly investigated. It is not sur-

prising that the role of communication and interac-

tion is central in many of the creativity techniques.

The most popular creativity technique used for re-

quirements identiﬁcation is the classical brainstorm-

ing and more recently, role-playing-based scenarios,

storyboard-illustrated scenarios, simulating and visu-

alizing have been applied as an attempt to bring more

creativity to requirements elicitation. These tech-

niques try to address the problem of identifying the

viewpoints of all the stakeholders (Mich et al., 2005).

However, in requirements engineering the an-

swers do not arrive by themselves, it is necessary

to ask, observe, discover, and increasingly create re-

quirements. If the goal is to build competitive and

imaginative products, we must make creativity part of

the requirements process. Indeed, the importance of

creative thinking is expected to increase over the next

decade (Maiden and Gizikis, 2001). In (Robertson,

2005)(Robertson, 2002) very interesting open ques-

tions are proposed: Is inventing part of the require-

ments activity? It is if we want to advance. So who

does the inventing? We cannot rely on the customer

to know what to invent. The designer sees his task

as deriving the optimal solution to the stated require-

ments. We cannot rely on programmers because they

are far away from the work of client to understand

what needs to be invented. Requirements analysts are

ideally placed to innovate. They understand the busi-

ness problem, have updated knowledge of the tech-

nology, will be blamed if the new product does not

please the customer, and know if inventions are ap-

propriate to the work being studied. In short, require-

ments analysts are the people whose skills and po-

sition allows, indeed encourages, creativity. In (Bo-

den, 2004) the author, a leading authority on cogni-

tive creativity, identiﬁes basic types of creative pro-

cesses: exploratory creativity explores a possible so-

lution space and discovers new ideas, combinatorial

creativity combines two or more ideas that already

exist to create new ideas, and trans-formational cre-

KnowledgeManagementandCreativityinSoftwareEngineering-TheFoundationsofAgility

267

ativity changes the solution space to make impossible

things possible. Then, most requirements engineer-

ing activities are exploratory, acquiring and discover-

ing requirements and knowledge about the problem

domain. Requirements engineering practitioners have

explicitly focused on combinatorial and transforma-

tional creativity.

Agile software development is a group of soft-

ware development methods based on iterative and in-

cremental development, where requirements and so-

lutions evolve through collaboration between self-

organizing and cross-functional teams. It promotes

adaptive planning, evolutionary development and de-

livery, a time-boxed iterative approach, and encour-

ages rapid and ﬂexible response to change. It is a

conceptual framework introduced in the Agile Man-

ifesto in 2001 (Beck et al., 2001).

3.2 Creative Process

The creative process constitutes the central aspect

of team performance, because it supposes a serie of

clearly distinguishable phases that had to be realized

by one or more of the team members in order to obtain

a concrete creative result.

The phases - on the basis of Wallas (Wallas, 1926)

and Leonard and Swap (Leonard and Swap, 1999) -

are the following ones:

- Initial preparation: the creativity will bloom

when the mental ground is deep, fertile and it has

a suitable preparation. Thus, the deep and relevant

knowledge, and the experience precedes the creative

expression.

- Encounter: the ﬁndings corresponding to the

perception of a problematic situation. For this situ-

ation a solution does not exist. It is a new problem.

- Final preparation: it corresponds to the under-

standing and foundation of the problem. It’s the im-

mersion in the problem and the use of knowledge and

analytical abilities. It includes search for data and the

detailed analysis of factors and variables.

- Generation of options: referred to produce a

menu of possible alternatives. It supposes the diver-

gent thinking. It includes, on one hand, ﬁnding prin-

ciples, lines or addresses, when making associations

and uniting different marks of references and, on the

other hand, to generate possible solutions, combina-

tions and interpretations.

- Incubation: it corresponds to the required time

to reﬂect about the elaborated alternatives, and ”to test

them mentally”.

- Options Choice: it corresponds to the ﬁnal eval-

uation and selection of the options. It supposes the

convergent thinking.

- Persuasion: closing of the creative process and

communication to other persons.

Considering the creativity as a ”nonlinear” pro-

cess some adjustments are necessary, redeﬁnitions or

discardings that force to return to previous phases, in

a complex creative dynamic. Therefore, for each one

of the deﬁned phases it is possible to associate feed-

backs whose ”destiny” can be anyone of the previous

phases in the mentioned sequence.

The team performance is directly determined

by the creative process (Kotler and Armstrong,

2003)(Leonard and Swap, 1999). By example, in eX-

treme Programming (XP) (Beck, 2000) it’s important

to correlate its phases with the phases considered in a

creative process.

- The initial preparation and ”ﬁnding” deﬁned in

the creative process correspond to the exploration

phase in XP, where the functionality of the prototype

and familiarization with the methodology are estab-

lished.

- The ﬁnal stage of preparation is equivalent with

the phases of exploration and planning in XP, deﬁning

more in detail the scope and limit of the development.

- The option generation phases, incubation and

election of options deﬁned in the creative process cor-

respond to the iterations made in XP and also with the

liberations of the production phase (small releases).

In XP there is not a clear distinction of the mentioned

creative phases, assuming that they occur to the inte-

rior of the team.

- The feedback phase (understanding this one as

a ﬁnal stage of the process, and not excluding that

can have existed previous micro - feedbacks since the

creative process is nonlinear) it could correspond in

XP with the maintenance phase.

- The persuasion phase is related to the phase of

death established in XP, constituting the close of the

development project with the ﬁnal liberation.

3.3 Roles in a Creative Team

Lumsdaine and Lumsdaine (Lumsdaine and Lums-

daine, 1995) raise the subject of the required cogni-

tives abilities (mindsets) for creative problem resolu-

tion. Their tipology is excellent for the creative team,

and the different roles to consider. These roles are the

following ones:

- The Detective is in charge of collecting the great-

est quantity of information related to the problem. It

has to collect data without making judgements, even

when it thinks that it has already understood the prob-

lem exactly.

- The Explorer detects what can happen in the area

of the problem and its context. It thinks on its long

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

268

term effects and it anticipates certain developments

that can affect the context (in this case, the team). The

explorer perceives the problem in a broad sense.

- The Artist creates new things, transforming the

information. It must be able to break his own schemes

to generate eccentric ideas, with imagination and feel-

ing.

- The Engineer is the one in charge of evaluating

new ide-as. It must make converge the ideas, in order

to clarify the concepts and to obtain practical ideas

that can be implemented for the resolution of prob-

lems.

- The Judge must do a hierarchy of ideas and de-

cide which of them will be implemented (and as well,

which ones must be discarded). Additionally, it must

detect possible faults or inconsistences, as well as

raise the corresponding solutions. Its role must be

critical and impartial, having to look for the best idea,

evaluating the associated risks.

- The Producer is in charge of implementing the

chosen ideas.

Leonard and Swap (Leonard and Swap, 1999)

have mentioned additional roles, possible to be in-

tegrated with the previous ones, because they try to

make more fruitful the divergence and the conver-

gence in the creative process:

The provoker who takes the members of the team

”to break” habitual mental and procedural schemes to

allow the mentioned divergence (in the case of the

”artist”) or even a better convergence (in the case

of the ”engineer”). Think tank that it is invited to

the team sessions to give a renewed vision of the

problem-situation based on his/her experticia and ex-

perience.

The facilitator whose function consists in helping

and supporting the team work in its creative task in

different stages.

The manager who cares for the performance and

specially for the results of the creative team trying to

adjust them to the criteria and rules of the organiza-

tion (use of resources, due dates).

Kelley and Littman (Kelley and Littman, 2005),

on the other hand, have raised a role tipology similar

to Lumsdaine and Lumsdaine (Lumsdaine and Lums-

daine, 1995), being interesting that they group the

roles in three categories: those directed to the learn-

ing of the creative team (susceptible of corresponding

with the detective, explorer, artist, provoker and think

tank roles), others directed to the internal organization

and success of the team (similar to the judge, facilita-

tor and manager roles) and, ﬁnally, roles whose pur-

pose is to construct the innovation (possibly related to

the role of the engineer and judge).

By example, the following is the correlation be-

tween creative and XP roles:

- The detective function consisting in collecting

information related to a problem is made by the client

him-self in XP, because this one generates the ﬁrst

contact with the software development team.

- The function of explorer consisting in deﬁning

completely the problem is made in XP as much by

the client as the manager of the team, all together they

appreciate the reach of the identiﬁed problem, as well

as of the possible solutions.

- The function of the artist consisting in transform-

ing the information, creating new relations, and there-

fore generating interesting solutions is made by the

developer, that in XP methodology is in charge of the

analysis, design and programming of software.

- The function of the engineer referred to clarify

and to evaluate the new ideas, in terms of its feasibil-

ity is made in XP by the tester and the tracker.

- The function of the judge, understood as the

deﬁnitive selection of the solutions to implant, is

made in XP by the tracker and the client.

- The function of the producer, referred to the im-

plementation of the selected ideas (strictly speaking it

is working software) is made in XP by the client in his

organization, including the processes and procedures

that this function implies.

The supporting roles considered are:

- The provoker; creativity demands that the diver-

gence as well as convergence in the solutions be max-

imum and complete. There is not explicit reference in

XP methodology about divergent thinking.

- The think tank who helps the team work ”from

outside” is equivalent completely to the role of the

consultant.

- The facilitator whose function is helping the

team, corresponds in XP to the coach role.

- The manager whose function is to lead to the

team in terms of its general efﬁciency and its effec-

tiveness corresponds with XP’s big boss or manager.

3.4 Basic Organizational Conditions

Regarding to the structure dimension of a new prod-

uct development team (in particular software), it is

possible to relate the roles in creativity to the roles

deﬁned in the agile methodology distinguishing: base

roles, that is, those directly related to the creative pro-

cesses and software development, and support roles,

whose function is to support or lead the other roles

for a better performance. In relation with the struc-

ture dimension it’s important to considerate how the

team can operate. In order to implement the function-

ality of each role, we must considerate two aspects:

KnowledgeManagementandCreativityinSoftwareEngineering-TheFoundationsofAgility

269

basic organizational conditions and the pertinent cre-

ative process.

The creative team performance is determined by

the organizational conditions in which it’s inserted

(Amabile, 1998)(Isaksen et al., 1999)(Leonard and

Swap, 1999). Some conditions are necessary - al-

though not sufﬁcient - for the creative performance.

We are interested in explore the inﬂuence of au-

tonomy, communication, cooperation and learning,

the handling of possible conﬂicts, pressure, formal-

ization, performance evaluation, available resources

(time) and the physical atmosphere of work.

The autonomy refers to the capacity of the people

and the team as a whole to act and make decisions.

By example, this aspect is related to the following XP

practices: the actual client, since it is part of the team

and, in addition, has decisional capacity delegated by

its own organization; the use of metaphors, of cod-

iﬁcation standards and the existence of ”right” rules

really represent codes of shared thought and action,

that make possible the autonomy of the team mem-

bers; the small deliveries and the fact of the collective

property allow that all the involved ones share ofﬁ-

cial and explicit knowledge, that results in a greater

independence of the members and the possibility of a

minor coordination among them. The team member’s

communication, cooperation and learning are forti-

ﬁed since the client is present and there exist opened

spaces to work together and in a pair programming

mode. The work dynamics is based on a game of

planning and metaphors involving all the participants

from the beginning (client and equipment developer).

Also, the use of codiﬁcation standards, the small de-

liveries, the collective property of the code and the

simple design, allow that the person has clear per-

formance codes and rules about what is expected and

acceptable (internal culture) in order to establish the

required communication and cooperation. The han-

dling of possible conﬂicts between the client and the

development team, and internally at team level is fa-

vored by XP practices handling it (presence of the

client, pairs programming, planning game, continu-

ous integration, tests, collective property), or to re-

duce it and to avoid it (small deliveries, simple de-

sign, 40 hour a week and codiﬁcation standard). Co-

operation and trust are associated to this issue. The

pressure (that in creativity is appraised as favorable

until certain degree, favoring the performance, and

detrimental if it exceeds this degree), is susceptible

then to favor in XP through the client in situ, the

programming by pairs, the planning game, the tests

and continuous integration. It’s possible to avoid, or

at least to reduce, the pressure through the refactor-

ization, the small deliveries, the collective property,

and the fact that surpassing the 40 weekly working

hours is seen like an error. The formalization, that

gives account of all those formal aspects (norms, pro-

cedures) deﬁned explicitly and that are known, and

even shared, by the members of the team. It’s assured

in XP through planning game, metaphors, continuous

integration, the collective property, the 40 hours per

week and the codiﬁcation standards guiding the de-

sirable conduct and performance of the team. The

evaluation of the performance is made in XP through

pair programming (self evaluation and pair evalua-

tion), frequent tests and even through the 40 weekly

hours (as a nonexceedable metric indicating limit of

effective-ness), all at the light of the planning (includ-

ing the standards). Finally, the presence of client con-

stitutes the permanent and fundamental performance

evaluation of the team and the products. The eval-

uation characteristics empower the learning processs.

The time dedicated has fundamental importance in XP

team respecting the available resources. This aspect is

strongly stressed in creativity. The pair programming

and the developer multifunctional role allow to opti-

mize the partial working-times, as well as the whole

project time, ensuring a positive pressure. The phys-

ical atmosphere of work, referred in creativity to the

surroundings that favor or make difﬁcult the creative

performance (including aspects like available spaces,

noise, colours, ventilation, relaxation places) are as-

sured only partially in XP through the open spaces, as

a way to assure the interaction between members of

the team.

4 CONCLUSIONS

In Software Engineering many development ap-

proaches work repeating the basic linear model in ev-

ery iteration, then in a lot of cases an iterative devel-

opment approach is used to provide rapid feedback

and continuous learning in the development team. To

facilitate learning among developers, Agile methods

use daily or weekly stand up meetings, pair program-

ming and collective ownership. Agile methods em-

phasis on people, communities of practice, communi-

cation, and collaboration in facilitating the practice of

sharing tacit knowledge at a team level. An important

ﬁnding is the need to not focus exclusively on explicit

knowledge but also on tacit knowledge.

They also foster a team culture of knowledge shar-

ing, mutual trust and care. Agile development is not

deﬁned by a small set of practices and techniques.

Agile development deﬁnes a strategic capability, a ca-

pability to create and respond to change, a capabil-

ity to balance ﬂexibility and structure, a capability to

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

270

draw creativity and innovation out of a development

team, and a capability to lead organizations through

turbulence and uncertainty. They rough out blueprints

(models), but they concentrate on creating working

software. They focus on individuals and their skills

and on the intense interaction of development team

members among themselves and with customers and

management.

The use of software tools for rapid prototyping

of algorithms would save considerable resources. It

would be desirable to employ Agile principles and

reusability to produce software which is easily adapt-

able to changing requirements while also improving

the quality and reduce development efforts. Since

software development is a knowledge intensive activ-

ity, an understanding from a Knowledge Management

perspective offers important insights about reusability

and Software Engineering methods.

By other side, Creativity and innovation are es-

sential skills in almost any teamwork. Having a team

that can solve problems quickly and effectively with a

little creative thinking is beneﬁcial to everyone. The

performance of a team depends not only on the com-

petence of the team itself in doing its work, but also on

the organizational context. The organizational condi-

tions in wich the team is inserted are very important

too. If workers see that their ideas are encouraged and

accepted, they will be more likely to be creative, lead-

ing to potential innovation in the workplace. The cre-

ation of a collaborative work environment will foster

the communication between employees and reward

those that work together to solve problems. Encour-

aging team members to take risks, the opposite of cre-

ativity is fear, then it is necessary to create an envi-

ronment that is free from fear of failure: failures are a

learning tool.

The Extreme Programming methodology includes

implicitly central aspects of a creative teamwork.

These aspects can be organized according to the struc-

ture that the team adopts and the performance that

characterizes to the team. The structure that the

team adopts and specially the different roles that

the methodology advises to deﬁne, nearly correspond

with the roles at the interior of a creative team. The

performance that characterizes the team through cer-

tain advisable practices, from the perspective of cre-

ativity, constitutes the necessary basic conditions, al-

though nonsufﬁcient, in order to favor the group cre-

ative performance. These conditions, called practices

in XP methodology, are accompanied by concrete

phases of constituent activities of an agile software

development process, which is possible to correspond

with the creative process, which is fundamental to the

creative performance. In spite of the previous com-

ments, we think that XP methodology should have

a more explicit reference to the provoker role that is

thoroughly described in creativity as a fundamental

factor to generate innovation. This can be explained

because, in general, agile methodologies do not aim,

as a central element, to generate an original software,

but an effective one. Secondly, it is essential the dis-

tinction and formalization of the creative phases to

generate options incubation and option choices. It is

assumed that they take place in the iterative and pro-

duction process, although XP is not focused in ”origi-

nality”. Thirdly, a more direct mention to the physical

atmosphere of work, that in creativity are considered

as highly relevant to enhance the performance. These

aspects should have a greater consideration since soft-

ware development is a special case of product devel-

opment.

REFERENCES

Amabile, T. (1996). Creativity in Context: Update to the

Social Psychology of Creativity. Westview Press.

Amabile, T. (1998). How to kill creativity. Harvard Busi-

ness Review, Sept-Oct:77–87.

Apostolou, D. and Mentzas, G. (2003). Experiences from

knowledge management implementations in compa-

nies of the software sector. Business Process Man-

agement Journal, 9(3).

Beck, K. (2000). Extreme programming explained: em-

brace change. Addison-Wesley Longman Publishing

Co., USA.

Beck, K., Beedle, M., Bennekum, A. V., Cockburn, A.,

Cunningham, W., Fowler, M., Grenning, J., High-

smith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B.,

Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J.,

and Thomas, D. (2001). Manifesto for agile software

development. Available at http://agilemanifesto.org.

Boden, M. (2004). The Creative Mind: Myths and Mecha-

nisms. Routledge, USA.

Chau, T. and Maurer, F. (2004). Knowledge sharing in ag-

ile software teams. In Lenski, W., editor, Logic ver-

sus Approximation: Essays Dedicated to Michael M.

Richter on the Occasion of his 65th Birthday, volume

3075 of Lecture Notes in Artiﬁcial Intelligence, pages

173–183. Springer.

Chau, T., Maurer, F., and Melnik, G. (2003). Knowl-

edge sharing: Agile methods versus tayloristic meth-

ods. Twelfth International Workshop on Enabling

Technologies: Infrastructure for Collaborative Enter-

prises, WETICE, pages 302–307.

Chen, M.-H. (2006). Understanding the beneﬁts and detri-

ments of conﬂict on team creativity process. Creativ-

ity and Innovation Management, 15(1):105–116.

Crawford, B. and Le

on de la Barra, C. (2007). Enhancing

creativity in agile software teams. Lecture Notes in

Computer Science, 4536:161–162.

KnowledgeManagementandCreativityinSoftwareEngineering-TheFoundationsofAgility

271

Crawford, B. and Le

on de la Barra, C. (2008). Integrat-

ing creativity into extreme programming process. In

Cordeiro, J. and Filipe, J., editors, ICEIS (3-1), pages

216–219.

Crawford, B., Le

on de la Barra, C., and Rubio, J. (2008).

Knowledge sharing in traditional and agile software

processes. In Cordeiro, J., Shishkov, B., Ranchordas,

A., and Helfert, M., editors, ICSOFT (PL/DPS/KE),

pages 376–379. INSTICC Press.

Crawford, B., Le

on de la Barra, C., Soto, R., Misra, S.,

and Monfroy, E. (2012). Knowledge management

and creativity practices in software engineering. In

Liu, K. and Filipe, J., editors, KMIS, pages 277–280.

SciTePress.

Gilson, L. L. and Shalley, C. E. (2004). A little creativity

goes a long way: An examination of teams engage-

ment in creative processes. Journal of Management,

30(4):453 – 470.

Glass, R. (1995). Software creativity. Prentice-Hall, USA.

Gu, M. and Tong, X. (2004). Towards hypotheses on cre-

ativity in software development. PROFES, 3009:47–

61.

Isaksen, S., Lauer, K., and Ekvall, G. (1999). Situational

outlook questionnaire: A measure of the climate for

creativity and change. Psychological Reports, pages

665–674.

John, M., Maurer, F., and Tessem, B. (2005). Human and

social factors of software engineering: workshop sum-

mary. ACM SIGSOFT Softw. Eng., Notes, 30:1–6.

Kelley, T. and Littman, J. (2005). The Ten Faces of Innova-

tion: IDEOs Strategies for Defeating the Devil’s Ad-

vocate and Driving Creativity Throughout Your Orga-

nization. Doubleday Random House, USA.

Kotler, P. and Armstrong, G. (2003). Principles of Market-

ing. Prentice Hall, New Jersey.

Kotler, P. and Tr

ıas de Bes, F. (2004). Marketing Lateral.

Editorial Pearson/Prentice Hall, Spain.

Leenders, R. T., van Engelen, J. M., and Kratzer, J. (2003).

Virtuality, communication, and new product team cre-

ativity: a social network perspective. Journal of En-

gineering and Technology Management, 20(1-2):69–

92. Special Issue on Research Issues in Knowledge

Management and Virtual Collaboration in New Prod-

uct Development.

on de la Barra, C. and Crawford, B. (2007). Foster-

ing creativity thinking in agile software development.

Lecture Notes in Computer Science, 4799:415–426.

Leonard, D. and Swap, W. (1999). When Sparks Fly: Ig-

niting Creativity in Groups. Harvard Business School

Press, Boston.

Lumsdaine, E. and Lumsdaine, M. (1995). Creative Prob-

lem Solving: Thinking Skills for a Changing World.

McGraw-Hill, New York.

Maiden, N. and Gizikis, A. (2001). Where do requirements

come from? IEEE Software, 18:10–12.

Maiden, N., Gizikis, A., and Robertson, S. (2004). Provok-

ing creativity: Imagine what your requirements could

be like. IEEE Software, 21:68–75.

Mentzas, G. (2000). The two faces of knowledge manage-

ment. International Consultant’s Guide, pages 10–

11. Available at http//imu.iccs.ntua.gr/Papers/O37-

icg.pdf.

Mich, L., Anesi, C., and Berry, D. (2005). Applying a

pragmatics-based creativity-fostering technique to re-

quirements elicitation. Requir. Eng., 10:262–275.

Nonaka, I. and Takeuchi, H. (1995). The Knowledge Creat-

ing Company. Oxford University Press, USA.

Robertson, J. (2002). Eureka! why analysts should invent

requirements. IEEE Software, 19:20–22.

Robertson, J. (2005). Requirements analysts must also be

inventors. IEEE Software, 22:48–50.

Rus, I. and Lindvall, M. (2002). Knowledge man-

agement in software engineering. IEEE Soft-

ware, 19(3):26–38. Available at http://fc-

md.umd.edu/mikli/RusLindvallKMSE.pdf.

Sanz, L. F. and Misra, S. (2011). Inﬂuence of human fac-

tors in software quality and productivity. In Murgante,

B., Gervasi, O., Iglesias, A., Taniar, D., and Apduhan,

B. O., editors, ICCSA (5), volume 6786 of Lecture

Notes in Computer Science, pages 257–269. Springer.

Sung, S. Y. and Choi, J. N. (2012). Effects of team knowl-

edge management on the creativity and ﬁnancial per-

formance of organizational teams. Organizational Be-

havior and Human Decision Processes, 118(1):4 – 13.

Takeuchi, H. and Nonaka, I. (1986). The new new product

development game. Harvard Business Review.

Wallas, G. (1926). The art of thought. Harcourt Brace, New

York.

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

272