Knowledge Management and Creativity Practices in Software
Engineering
Broderick Crawford
1
, Claudio Le´on de la Barra
1
, Ricardo Soto
1
, Sanjay Misra
2
and Eric Monfroy
3
1
Pontificia Universidad Cat´olica de Valpara´ıso, PUCV, Valpara´ıso, Chile
2
Federal University of Technology, Minna, Nigeria
3
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 fixed 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 Tı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
Copyright
c
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 fulfill 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 identification 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, identifies 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 significantly 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
efficient 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 defined roles. In knowledge intensive
software development that demands information flow
from different functional sub-teams, role based teams
tend to lead to islands of knowledge and difficulties
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 difficult 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 difficult
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 finding 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-
fined by a small set of practices and techniques. Ag-
ile development defines a strategic capability, a ca-
pability to create and respond to change, a capabil-
ity to balance flexibility 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 beneficial 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
nonsufficient, 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 Artificial 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). Influence 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 five 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