Knowledge Management and Creativity Practices in Software

Engineering

Broderick Crawford

, Claudio Le´on de la Barra

, Ricardo Soto

, Sanjay Misra

and Eric Monfroy

Pontiﬁcia Universidad Cat´olica de Valpara´ıso, PUCV, Valpara´ıso, Chile

Federal University of Technology, Minna, Nigeria

LINA, Universit´e de Nantes, Nantes, France

Keywords:

Knowledge Management, Creativity, Software Engineering, Agile Methodologies.

Abstract:

An increasing number of organizations are trending to teams for innovation and creativity. In software engi-

neering it is the same, 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

knowledge sharing and creativity is one of the keys to response to common problems and challenges of soft-

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

useful ideas. Here, we ﬁxed some concepts from knowledge management and creativity in relation with new

software engineering trends.

1 INTRODUCTION

Software engineering is a knowledge intensive dis-

cipline where its activities require the use and shar-

ing of knowledge between the stakeholders. Then a

better transfer and application of the knowledge aim

to foster the software processes, whether these are

done using traditional or agile approaches. In soft-

ware organizations the knowledge held by the em-

ployees is the main asset and software development

projects depends mostly on team performance: ”Soft-

ware is developed for people and by people” (John

et al., 2005). But surprisingly, most of software en-

gineering research is technical and deemphasizes the

human and social aspects. By other hand, the tradi-

tional development process of new products that is

a fundamental part in the marketing, has been re-

cently criticized by Kotler and Tr´ıas de Bes (Kotler

and Tr´ıas de Bes, 2004). They point out that funda-

mental creative aspects are not considered at all and

as a consequence this development is not useful, vi-

able or innovative. In this context, it is interesting to

consider the new proposals of agile methodologiesfor

software developmentin order to analyse and evaluate

them at the light of the existing creative expositions,

mainly considering the teamwork practices. The ag-

ile principles and values have emphasized the impor-

tance of collaboration and interaction in the software

development and, by other hand, creative work com-

monly involves collaboration in some form and it can

be understood as an interaction between an individ-

ual and a sociocultural context. In relation with the

joint work between users and software developers,

there are very interesting cases in healthcare enter-

prises and medicine. The relationship between agile

approaches and the health sector has a notable case

with the work of Jeff Sutherland, the inventor of the

popular Scrum Agile Development Process (Suther-

land, 2001). Scrum, the most notorious competitor

of eXtreme Programming XP (Beck, 2000), has at-

tained worldwide fame for its ability to increase the

productivity of software teams by several magnitudes

through empowering individuals, fostering a team-

oriented environment, and focusing on project trans-

parency and results. There are recent studies report-

ing efforts to improve agile process (Crawford and

Leon de la Barra, 2008). Agile software develop-

ment addresses software process improvement within

teams. The work in (Ringstad et al., 2011)(Moe et al.,

2010) argue for the use of diagnosis and action plan-

ning to improve teamwork in agile software devel-

opment. The action planning focused on improving

shared leadership, team orientation and learning. The

improvement project provided most new insight for

the mature team. We believe that the innovation and

development of new products is an interdisciplinary

issue (Takeuchi and Nonaka, 1986), we are interested

in the study of human and social factors to foster

277

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

Knowledge Management and Creativity Practices in Software Engineering.

DOI: 10.5220/0004141002770280

In Proceedings of the International Conference on Knowledge Management and Information Sharing (KMIS-2012), pages 277-280

ISBN: 978-989-8565-31-0

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

software quality (Sanz and Misra, 2011)(Mishra and

Misra, 2010).

2 CREATIVITY IN SOFTWARE

DEVELOPMENT

Software engineering is a knowledge intensive pro-

cess that includes some aspects of Knowledge Man-

agement (KM) and Creativity in all phases: elicit-

ing requirements, design, construction, testing, im-

plementation, maintenance, and project management

(John et al., 2005). No worker of a development

project has all the knowledge required to fulﬁll all ac-

tivities. This underlies the need for communication,

collaboration and knowledge sharing support to share

domain expertise between the customer and the de-

velopment 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, 2000).

Since human creativity is thought as the source to

solve complex problem or create innovative products,

one possibility to improve the software development

process is to design a process which can stimulate the

creativity of the developers. There are few studies re-

ported on the importance of creativity in software de-

velopment. In management and business, researchers

have done much work about creativity and obtained

evidence that the employees who had appropriatecre-

ativity characteristics, worked on complex, challeng-

ing jobs, and were supervised in a supportive,noncon-

trolling fashion, produced more creative work. Then,

according to the previous ideas the use of creativity in

software developmentis undeniable, but requirements

engineering is not recognized as a creative process in

all the cases (Maiden et al., 2004). In a few publi-

cations the importance of creativity has been investi-

gated in all the phases of software development pro-

cess (Gu and Tong, 2004)(Glass, 1995)(Crawford and

Leon de la Barra, 2007)(Leon de la Barra and Craw-

ford, 2007) and mostly focused in the requirements

engineering (Robertson, 2005)(Mich et al., 2005).

Nevertheless, the use of techniques to foster creativ-

ity in requirements engineering is still shortly investi-

gated. It is not surprising that the role of communica-

tion and interaction is central in many of the creativ-

ity techniques. The most popular creativity technique

used for requirements identiﬁcation is the classical

brainstorming and more recently, role-playing-based

scenarios, storyboard-illustrated scenarios, simulat-

ing and visualizing have been applied as an attempt

to bring more creativity to requirements elicitation.

These techniques try to address the problem of iden-

tifying 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-

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-

KMIS2012-InternationalConferenceonKnowledgeManagementandInformationSharing

278

tional creativity.

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

ganization level, and this is exactly what KM pro-

poses. People in such groups must collaborate, com-

municate, and coordinate their work, which makes

knowledge management a necessity. In software de-

velopment one can identify two types of knowledge:

Knowledge embedded in the products or artifacts,

since they are the result of highly creative activi-

ties and Meta-knowledge, that is knowledge about

the products and processes. Some of the sources

of knowledge (artifacts, objects, components, pat-

terns, 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 knowl-

edge sharing culture, as well as technology support

for knowledge management. About knowledge shar-

ing in plan-driven and agile development approaches

the main different strategies are in the following di-

mensions (Chau and Maurer, 2004):

Eliciting Requirements and Documentation. Com-

mon to all software development processes is the need

to capture and share knowledge about the require-

ments and design of the product, the development

process, the business domain and the project status. In

Tayloristic development approaches this knowledge

is externalised in documents and artifacts to ensure

all possible requirements, design, development, and

management issues are addressed and captured. One

advantage to this emphasis on knowledge external-

isation is that it reduces the probability of knowl-

edge loss as a result of knowledge holders leaving

the organisation. Agile methods advocate lean and

mean documentation. Compared to Tayloristic meth-

ods, there is signiﬁcantly less documentation in ag-

ile methods. As less effort is needed to maintain

fewer documents, this improves the probability that

the documents can be kept up to date. To compensate

for the reduction in documentation and other explicit

knowledge, agile methods strongly encourage direct

and frequent communication and collaboration.

Training. With regards to disseminating process and

technical knowledgefrom experiencedteam members

to novices in the team, Tayloristic and agile methods

use different training mechanisms as well. While it

is not stated, formal training sessions are commonly

used in Tayloristic organizations to achieve the above

objective. Agile methods, on the other hand, recom-

mend informal practices, for example, pair program-

ming and pair rotation in case of eXtreme Program-

ming.

Trust and Freedom. As software development is

a very social process, it is important to develop or-

ganisational and individual trust in the teams and

also between the teams and the customer. Trusting

other people facilitates reusability and leads to more

efﬁcient knowledge generation and knowledge shar-

ing. Through collective code ownership, stand-up

meetings, on site customer, and in case of XP, pair

programming, agile methods promote and encour-

age mutual trust, respect and care among developers

themselves and to the customer as well. The key of

knowledge sharing here are the interactions among

members of the teams which happen voluntarily, and

not by an order from the headquarters (Cockburn and

Highsmith, 2001).

Team Work and Roles. In Tayloristic teams different

roles are grouped together as a number of role-based

teams each of which contains members who share the

same role. In contrast, agile teams use cross func-

tional teams. Such a team draws together individuals

performing all deﬁned roles. In knowledge intensive

software development that demands information ﬂow

from different functional sub-teams, role based teams

tend to lead to islands of knowledge and difﬁculties

in its sharing among all the teams emerge. Learn-

ing, or the internalisation of explicit knowledge, is a

social process. One does not learn alone but learns

mainly through tacit knowledge gained from interac-

tions with others. Furthermore, tacit knowledge is

often difﬁcult to be externalised into a document or

repository. A repository by itself does not support

communication or collaboration among people either.

Due to the high complexity of the software process

in general, it is hard to create and even more difﬁcult

to effectively maintain the experience repository (Rus

and Lindvall, 2002).

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

KnowledgeManagementandCreativityPracticesinSoftwareEngineering

279

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, commu-

nication, and collaboration in facilitating the practice

of sharing tacit knowledge at a team level. An im-

portant ﬁnding is the need to not focus exclusively

on explicit knowledge but also on tacit knowledge.

They also foster a team culture of knowledge sharing,

mutual trust and care. Agile development is not de-

ﬁned by a small set of practices and techniques. Ag-

ile 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

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. By other side, creativity and innovation

are essential skills in almost any teamwork. Having a

team that can solve problems quickly and effectively

with a little creative thinking is beneﬁcial to every-

one. The performance of a team depends not only on

the competence of the team itself in doing its work,

but also on the organizational context. The perfor-

mance that characterizes the team through certain ad-

visable practices, from the perspective of creativity,

constitutes the necessary basic conditions, although

nonsufﬁcient, in order to favor the group creative per-

formance.

REFERENCES

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

brace change. Addison-Wesley Longman Publishing

Co., USA.

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.

Cockburn, A. and Highsmith, J. (2001). Agile software

development: The people factor. IEEE Computer,

34(11):131–133.

Crawford, B. and Leon de la Barra, C. (2007). Enhancing

creativity in agile software teams. Lecture Notes in

Computer Science, 4536:161–162.

Crawford, B. and Leon 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.

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.

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.

Kotler, P. and Tr´ıas de Bes, F. (2004). Marketing Lateral.

Editorial Pearson/Prentice Hall, Spain.

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

ing creativity thinking in agile software development.

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

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.

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

pragmatics-based creativity-fostering technique to re-

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

Mishra, A. and Misra, S. (2010). People management in

software industry: the key to success. ACM SIGSOFT

Software Engineering Notes, 35(6):1–4.

Moe, N., Dingsoyr, T., and Dyba, T. (2010). A teamwork

model for understanding an agile team: A case study

of a scrum project. Information and Software Tech-

nology, 52:480–491.

Ringstad, M., Dingsoyr, T., and Moe, N. (2011). Agile

process improvement: Diagnosis and planning to im-

prove teamwork. Communications in Computer and

Information Science, 172:167–178.

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.

Sutherland, J. (2001). Agile can scale: Inventing and rein-

venting scrum in ﬁve companies. Cutter IT Journal,

14:5–11.

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

development game. Harvard Business Review.

KMIS2012-InternationalConferenceonKnowledgeManagementandInformationSharing

280