KNOWLEDGE SHARING IN TRADITIONAL AND AGILE

SOFTWARE PROCESSES

Broderick Crawford

Pontiﬁcia 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

Pontiﬁcia Universidad Cat´olica de Valpara´ıso, Universidad de las Am´ericas - Laureate International Universities, Chile

Keywords:

Knowledge Sharing, Agile Development, Software Development Techniques, Knowledge Management.

Abstract:

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.

1 INTRODUCTION

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 fulﬁlling 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

methodologies.

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

376

Crawford B., León de la Barra C. and Miguel Rubio León J. (2008).

KNOWLEDGE SHARING IN TRADITIONAL AND AGILE SOFTWARE PROCESSES.

In Proceedings of the Third International Conference on Software and Data Technologies - PL/DPS/KE, pages 376-379

DOI: 10.5220/0001892203760379

 SciTePress

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.

3 TWO APPROACHES TO KM:

PRODUCT AND PROCESS

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 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 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).

4 AGILE METHODS

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-

ﬁed 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 signiﬁcant 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

KNOWLEDGE SHARING IN TRADITIONAL AND AGILE SOFTWARE PROCESSES

377

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, sufﬁcient 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-

eration.

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.

5 KNOWLEDGE SHARING IN

AGILE AND TAYLORISTIC

METHODS

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 signiﬁcantly 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 efﬁcient 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

378

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-

ﬁned roles. In knowledge intensive software devel-

opment 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. 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 difﬁcult 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 difﬁcult to effectively maintain

the experience repository (Rus and Lindvall, 2002).

6 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. They also fos-

ter a team culture of knowledge sharing, 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 capabilityto create and

respond to change, a capability to balance ﬂexibility

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.

REFERENCES

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 http://agilemanifesto.org.

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

34(11):131–133.

Fowler, M. (2001). The new methodology. Available at

http://www.martinfowler.com/articles/newMethodolo-

gy.html.

Highsmith, J. (2008). Reuse as a knowledge

management problem. Available at http://

www.informit.com/articles/article.aspx?p=31478.

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.

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-

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

KNOWLEDGE SHARING IN TRADITIONAL AND AGILE SOFTWARE PROCESSES

379