Broderick Crawford
Pontificia Universidad Cat´olica de Valpara´ıso, Universidad T´ecnica Federico Santa Mar´ıa, Chile
Claudio Le´on de la Barra, Jos´e Miguel Rubio Le´on
Pontificia Universidad Cat´olica de Valpara´ıso, Universidad de las Am´ericas - Laureate International Universities, Chile
Knowledge Sharing, Agile Development, Software Development Techniques, Knowledge Management.
The software development community has a wide spectrum of methodologies to implement a software project.
In one side of the spectrum we have the more Traditional deterministic software development derived from
Tayloristic management practices, and in the other side, are the Agile software development approaches. The
Agile processes are people oriented rather than process oriented, unlike the Traditional processes they are
adaptive and not predictive. Software development is a knowledge intensive activity and the Knowledge Cre-
ation and Sharing are crucial parts of the software development processes. This paper presents a comparison
between Knowledge Sharing approaches of Agile and Tayloristic software development teams.
In Software Engineering a vision of the methodolo-
gies that improve productivity and quality of its soft-
ware products is absolutely necessary. Furthermore,
Software Engineering is a knowledge intensive pro-
cess that includes some aspects of Knowledge Man-
agement (KM) in all phases: eliciting requirements,
design, construction, testing, implementation, main-
tenance, and project management. No worker of a
development project possess all the knowledge re-
quired for fulfilling all activities. This underlies the
need for 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 Tay-
loristic, like the waterfall model and its variances,
facilitate knowledge sharing primarily through doc-
umentation. They also promote usage of role based
teams and detailed plans of the entire software de-
velopment life-cycle. It shifts the focus from indi-
viduals and their creative abilities to the processes
themselves. In contrary, agile methods emphasise and
value individuals and its interactions over processes.
Tayloristic methods heavily and rigorously use doc-
umentation for capturing knowledge gained in the
activities of a software project life-cycle (Chau and
Maurer,2004). In contrast, agile methods suggest that
most of the written documentation can be replaced
by enhanced informal communications among team
members and among the team and the customers with
a stronger emphasis on tacit knowledge rather than
explicit knowledge (Beck et al., 2001). We believe
that in software development projects, a better under-
standing of knowledge sharing and transfer, from a
Knowledge Management perspective, offers impor-
tant insights about the use of 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 level and
organization 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-
Crawford B., León de la Barra C. and Miguel Rubio León J. (2008).
In Proceedings of the Third International Conference on Software and Data Technologies - PL/DPS/KE, pages 376-379
DOI: 10.5220/0001892203760379
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, patterns
and templates) are stored in electronic form. How-
ever, the majority of knowledgeis tacit, residing in the
brains of the employees. A way to address this prob-
lem can be to develop a knowledge sharing culture, as
well as technology support for knowledge manage-
ment. In (Rus and Lindvall, 2002) there are several
reasons to believe that knowledge management for
software engineering would be easier to implement
than in other organizations.
Knowledge Management has been the subject of
much discussion over the past decade and different
KM life-cycles and strategies have been proposed.
One of the most widely accepted approaches to classi-
fying knowledgefrom a KM perspectiveis the Knowl-
edge Matrix of Nonaka and Takeuchi (Nonaka and
Takeuchi, 1995). This matrix classifies 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 experi-
ences). Traditional methods of software development
use a great amount of documentation for capturing
knowledge gained in the activities of a project life-
cycle. In contrast, the agile methods suggest that most
of the written documentation can be replaced by en-
hanced informal communications among team mem-
bers and customers with a stronger emphasis on tacit
knowledge rather than explicit knowledge. In the KM
market a similar situation exists and two approaches
to KM have been mainly employed; we will refer
to them as the Product and the Process approaches.
These approaches adopt different perspectives in re-
lation to documentation and interactions among the
stakeholders (Mentzas, 2000).
3.1 Knowledge as a Product
The product approach implies that knowledge can be
located and manipulated as an independent object.
Proponentsof this approach claim that it is possible to
capture, distribute, measure and manage knowledge.
This approach mainly focuses on products and arte-
facts containing and representing knowledge.
3.2 Knowledge as a Process
The process approach puts emphasis on ways to pro-
mote, motivate, encourage, nurture or guide the pro-
cess of learning and abolishes the idea of trying to
capture and distribute knowledge. This view mainly
understands KM as a social communication process,
which can be improved by collaboration and coop-
eration support tools. In this approach, knowledge
is closely tied to the person who developed it and
is shared mainly through person-to-person contacts.
This approach has also been referred to as the Collab-
oration or Personalisation approach. Choosing one
approach or other will be in relation to the character-
istics of the organization, the project and the people
involvedin each case (Apostolouand Mentzas, 2003).
A new group of software development methodologies
has appeared over the last few years. For a while these
were known as lightweight methodologies, but now
the accepted term is Agile methodologies (Fowler,
2001). There exist many variations, but all of them
share the common principles and core values speci-
fied in the Agile Manifesto (Chau and Maurer, 2004).
Through its work they have come to value individuals
and interactions over processes and tools. Working
software over comprehensive documentation. Cus-
tomer collaboration over contract negotiation. Re-
sponding to change over following a plan.
These new methods attempt a useful compromise
between no process and too much process, provid-
ing just enough process to gain a reasonable pay-
off. The result of all of this is that agile methods
have some significant differences with the former en-
gineering methods (Fowler, 2001): Agile methods are
adaptive rather than predictive and people oriented
rather than process oriented. The different software
development approaches implicitly consider a simple
linear life cycle model in which the algorithm un-
dergoes a design/tuning phase and is then employed
in production. Beside being the simplest life cycle
model, the linear model is also the building block
composing more complex models: Iterative, Hybrid
(such as the Spiral) and Agile. Spiral, in this con-
text, can be described as a sequence of interleaved
design/tuning phases and production phases: At the
end of each production phase, sufficient information
is gathered which can be employed in the following
design/tuning phase for improving the algorithm. Ag-
ile methods attempt to minimize risk by developing
software in short iterations, each iteration is like a
miniature software project of its own, and includes all
of the tasks necessary to release the mini-increment of
new functionality: planning, requirements analysis,
design, coding, testing, and documentation. That is,
some agile teams use the waterfall model on a small
scale, repeating the entire waterfall cycle in every it-
Knowledge Management implementations in
Software Engineering can extract knowledge from
its sources of knowledge: documentation, artifacts,
objects, components, patterns, templates and code
repositories, exploiting this knowledge in future soft-
ware developments. But, software reuse is not a tech-
nology problem, nor is it a management problem.
Reuse is fundamentally a Knowledge Management
problem. In (Highsmith, 2008) Jim Highsmith ex-
plains how over the last ten or so years, by pack-
aging objects into components and components into
templates, we have made the problem bigger, not
smaller. Objects, patterns, templates, and compo-
nents are packaged (explicit) knowledge: the larger
the package, the greater the encapsulated knowledge.
The greater the encapsulated knowledge, the harder
it is to transfer. Additionally, the essence of problem
solving, innovation, creativity, intuitive design, good
analysis, and effective project management involves
more tacit knowledge, the harder it is to transfer. By
putting tacit knowledge in a principal role and culti-
vating tacit knowledge environments, KM can play an
importantrole in application development, and partic-
ularly in reuse. A second aspect of the explicit knowl-
edge problem, observed by Highsmith, is the fallacy
that documentation (explicit knowledge) equals un-
derstanding. When, in order to successfully reuse a
component, we seek understanding in the documenta-
tion, the larger and more complex the component, the
harder it is to gain the required understanding from
documentation alone. Understanding, in this con-
text at least, is a combination of documentation and
conversation about the component and the context in
which that component operates. No writer of docu-
mentation can anticipate all the questions a compo-
nent user may have.
About knowledge sharing in plan-drivenand agile de-
velopment approaches the main different strategies
are in the following dimensions (Chau et al., 2003):
5.1 Eliciting Requirements
Common to all software development processes is the
need to capture and share knowledge about the re-
quirements and design of the product, the develop-
ment 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, develop-
ment and management issues are addressed and cap-
tured. One advantage to this emphasis on knowl-
edge externalisation is that it reduces the probabil-
ity of knowledge loss as a result of knowledge hold-
ers leaving the organisation. Agile methods advocate
lean and mean documentation. Compared to Tayloris-
tic methods, there is significantly less documentation
in agile 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.
5.2 Training
With regards to disseminating process and techni-
cal knowledge from experienced team 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 (XP).
5.3 Trust
As software development is a very social process, it
is important to develop organisational and individual
trust in the team and also among the team and the
customer. Trusting other people facilitates reusability
and leads to more efficient knowledge generation and
knowledge sharing. Through collective code owner-
ship, stand-up meetings, on site customer, and in case
of XP, pair programming, agile methods promote and
ICSOFT 2008 - International Conference on Software and Data Technologies
encourage mutual trust, respect and care among de-
velopers themselves and to the customer as well. The
key of knowledge sharing here are the interactions
among members of the teams which happen voluntar-
ily, and not by an order from the headquarters (Cock-
burn and Highsmith, 2001).
5.4 Team Work
In Tayloristic teams different roles are grouped to-
gether as a number of role-based teams each of which
contains members who share the same role. In con-
trast, agile teams use cross functional teams. Such
a team draws together individuals performing all de-
fined roles. In knowledge intensive software devel-
opment 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. Learning, or the inter-
nalisation of explicit knowledge, is a social process.
One does not learn alone but learns mainly through
tacit knowledge gained from interactions with others.
Furthermore, tacit knowledge is often difficult to be
externalised into a document or repository. A reposi-
tory by itself does not support communication or col-
laboration among people either. Due to the high com-
plexity 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).
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. They also fos-
ter a team culture of knowledge sharing, mutual trust
and care. Agile development is not defined by a small
set of practices and techniques. Agile development
defines a strategic capability, a capabilityto create and
respond to change, a capability to balance flexibility
and structure, a capability to draw creativity and in-
novation out of a development team, and a capability
to lead organizations through turbulence and uncer-
tainty. They rough out blueprints (models), but they
concentrateon creating working software. They focus
on individuals and their skills and on the intense in-
teraction of development team members among them-
selves and with customers and management. Since
software development is a knowledge intensive ac-
tivity, we think that a better understanding from a
Knowledge Management perspective offers important
insights about Reusability and Software Engineering.
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., 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
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 vs tayloristic meth-
ods. In Twelfth International Workshop on Enabling
Technologies: Infrastructure for Collaborative Enter-
prises, WETICE, pages 302–307, Los Alamitos, CA,
USA. IEEE Computer Society.
Cockburn, A. and Highsmith, J. (2001). Agile software
development: The people factor. IEEE Computer,
Fowler, M. (2001). The new methodology. Available at
Highsmith, J. (2008). Reuse as a knowledge
management problem. Available at http://
Mentzas, G. (2000). The two faces of knowledge manage-
ment. International Consultant’s Guide, pages 10–
11. Available at http//
Nonaka, I. and Takeuchi, H. (1995). The Knowledge Creat-
ing Company. Oxford University Press.
Rus, I. and Lindvall, M. (2002). Knowledge man-
agement in software engineering. IEEE Soft-
ware, 19(3):26–38. Available at http://fc-