Knowledge Management in Agile Projects - Cognizant

• Cognizant 20-20 InsightsKnowledge Managementin Agile ProjectsExecutive SummarySoftware development is knowledge-intensivework and the main challenge is how to managethis knowledge. The Agile manifesto advocates“individuals and interaction over process andtools,” and hence it requires even more attentionto manage knowledge in Agile projects.This paper demarcates the types of knowledgeinvolved in the lifecycle of software projects anddescribes the mechanisms to effectively managethem in Agile software development. It thenargues for the need to scale Agile developmentstrategies in knowledge management to addressthe full delivery process.Knowledge Management inSoftware DevelopmentKnowledge management is “a method thatsimplifies the process of sharing, distributing,creating, capturing and understanding thecompany knowledge.” 1 Knowledge itself “is a fluidmix of framed experience, values, contextualinformation and expert insight that provide aframework for evaluation and incorporating newexperience and new information.” 2 Furthermore,“knowledge passes through different modes ofconversion, which makes the knowledge morerefined and spreads it across different layers inan organization.” 3The main assets of software development are notmanufacturing plants, buildings and machinesbut the knowledge held by the employees andthe development culture of an organization.Companies developing information systemshave failed to learn effective means for problemsolving to such an extent that they havelearned to fail. The key drivers for companiesto manage knowledge effectively in softwaredevelopment are:• Reducing the effort spent in acquiringrequired knowledge for project execution.• Improving reusability (i.e., avoidingreinvention).• Reducing dependency on individuals forproject success.• Improving the overall team’s productivity.Knowledge TypesTypically, knowledge can be classified into twotypes, explicit and tacit.Explicit knowledge is knowledge that is articulableand transmittable in formal, systematic language.This can include grammatical statements, mathematicalexpressions, specifications, manualsand so forth. Such knowledge can be transmittedformally among individuals with ease.Tacit knowledge is personal and context-specific,and is therefore difficult to formalize and communicate.It is embedded in individual experience andinvolves intangible factors such as personal belief,perspectives and value systems. Tacit knowledgecognizant 20-20 insights | january 2012

is difficult to communicate and share in an organizationand thus must be converted into words orother forms of explicit knowledge.The Knowledge Lifecycle inSoftware ProjectsThe knowledge life cycle in software projects canbe described in five steps.1. Gather available explicit knowledge.Generally, this happens during the start ofthe project whereby available knowledge iscaptured and made available in knowledgebases, marketing, different departments, etc.2. Personalize explicit knowledge. The gatheredinformation/knowledge needs to be convertedby the individuals involved in the projects intotacit knowledge.3. Application of the acquired knowledge.Converted tacit knowledge will be applied tothe project execution.4. Learning from the project. There could besome learning, innovations or new methods ortechniques uncovered during the execution ofthe project which will be in the form of tacitknowledge.5. Convert to explicit knowledge. The learningneeds to be converted into explicit knowledgeand added to the repository for futurereference.There are many questions related to knowledgemanagement, especially in Agile projects: Howdifferent is it to manage knowledge in AgileThe Knowledge CircleFigure 15Convert theLearning toExplicitKnowledgefor FutureReference1AvailableExplicitKnowledgeLearning fromPersonalize thethe Project in theExplicit KnowledgeForm of Taciti.e., Convert toKnowledgeTacit KnowledgeApplicationof AcquiredKnowledge to4 Project Execution32projects? What should be the relative levels offocus on explicit knowledge vs. tacit knowledge?This paper will address these queries.Knowledge Management in TraditionalSoftware DevelopmentTraditional software development approachesorganize the required knowledge sharing basedon different roles following a Tayloristic 4 mind-set:people involved in the development process areassigned specific roles (e.g., business analyst,software architect, lead designer, programmer,tester, etc.) that are associated with specificstages in the development process (requirementsanalysis, high-level design, low-level design,coding, testing, etc.).LimitationsKnowledge sharing between each of the stagesis primarily document based (i.e., through explicitknowledge). One role produces a document (e.g.,requirements specifications, design documents,source code, test plans, etc.) and hands it off tothe people responsible for the next stage in thedevelopment process.Assuming merely 5% of relevant information islost in each transfer between the stages, nearlya quarter of the information does not reach thecoder (who has to encode the domain knowledgeinto software) in a Tayloristic developmentprocess. The results are even worse if more than5% is lost in each stage.Another problem resulting from the long communicationchains in Tayloristic software organizationsis a tendency to over-document. Informationis useful only when it is new to the receiver;providing a known fact to somebody is old, boringnews. In fact, such repetition makes it moredifficult to find the relevant “gems” of informationin a document and hence increases knowledgetransfer costs. People involved in the early stagesof software development do not (and cannot)know what information is already known to thecoders. Relevance of information is completelysubjective in the sense that it depends on thecurrent knowledge of the information receiver.Knowledge Management inAgile Software DevelopmentAgile software development relies on direct communication— i.e., synchronized and osmotic communicationsbetween customers and developersfor knowledge sharing. This reduces the informationloss due to long communication chains andcognizant 20-20 insights 2

team members who may not talk to each otherregularly. Team members learn whom to contactwhen they work on parts of the system that theyare unfamiliar with.To reduce the communication cost among thevarious roles that are involved in software development— such as business analysts, developersand testers — Agile methods recommend the useof cross-functional teams instead of role-basedteams. A role-based team contains only membersin the same role. By contrast, a cross-functionalteam draws together individuals of alldefined roles. Experiences indicate that crossfunctionalteams facilitate better collaborationand knowledge sharing, which leads to reducedproduct development time.Continuous learning is supported by some Agilemethods in the form of project retrospectives.Retrospectives are in essence post-mortemreviews on what happened during development,except that they are conducted not only at theend of a project but also during it. Retrospectivesfacilitate the identification of any successfactors and obstacles of the current managementand development process. In cases where teammembers face obstacles of the current process,such as lengthy stand-up meetings, retrospectivesprovide the opportunity for these issues tobe raised, discussed, and dealt with during theproject rather than at the end of the project.LimitationsAlthough the concept of learning is embeddedin various Agile software development practices,as shown above, these practices only addressknowledge sharing within a team. They do notaddress issues of knowledge sharing across teamboundaries. In a large organization, there mayexist multiple teams that work on similar tasks,face common problems or have overlappinginterests in specific knowledge areas. In short,there is a lack of explicit support for organizationallearning. Also, there will be instances whereAgile teams are distributed due to the natureof business, which also makes tacit knowledgesharing difficult.To address this, we need to have lightweightmechanisms to convert tacit knowledge intoexplicit knowledge in Agile software development.Some of the mechanisms are as follows.Agile teams should make it a practice to capturelearns in a particular Sprint as part of everyretrospective meeting and ensure that this isconverted into explicit knowledge (through documentation)and published in a common area thateveryone can access. The common area could bea lightweight collaboration Website like a Wikiwhich should act as a collaborative knowledgerepository for the team.The majority of the information captured in traditionalspecification documents, such as requirementsspecifications, architecture specificationsor design specifications, can be capturedas “executable specifications” in the form oftests. When you take a test-driven development(TDD) approach, you effectively write detailedspecifications on a just-in-time (JIT) basis. WithTDD, you write a test, either at the customer/acceptance level or the developer level, beforewriting sufficient code/functionality to fulfill thattest. The tests accomplish two purposes: theyspecify the requirements/architecture/design andthey validate your work. This is an example of thepractice of single source information.Make it a practice to create needy documents —i.e., if and only if they fulfill a clear, important, andimmediate goal of overall project efforts. Don’tforget that this purpose may be short-term orlong-term; it may directly support software developmentefforts or it may not. Also, rememberthat each system has its own unique documentationneeds, that one size does not fit all. Theimplication is that you’re not going to be able tofollow a “repeatable process” and leverage thesame set of documentation templates on everyproject, at least not if you’re interested in actuallybeing effective.ConclusionTraditionally, software development teams followthe Tayloristic approach favoring division of labor;hence, the use of role-based teams. Role-basedteams with handoffs between job functions havethe inherent problem of amplifying the problemof miscommunication due to indirect and longcommunication paths (i.e., knowledge sharingthrough explicit knowledge).Agile development teams address this problem byusing cross-functional teams, which encouragesdirect communication through release anditeration planning, pair programming and pairrotation, and daily stand-ups and retrospectives— all of which reduces the likelihood of miscommunication.They rely on various practices whichemphasize approximate knowledge sharing bycognizant 20-20 insights 4

social interaction and fast feedback loops insteadof structured (logical) representations (i.e.,knowledge sharing through tacit knowledge).However, there are major inherent limitations tothe various knowledge-sharing practices used byAgile teams in their original forms. They do notfacilitate inter-team learning and also do not workwell if the teams are distributed. To address this,Agile teams should not only rely on the knowledgesharing through tacit knowledge but should alsoemploy lightweight explicit knowledge sharing liketest-driven development, needy documentation,usage of Wikis, and the discipline of capturing thelearns through retrospectives.Footnotes1T.H.Davenprot, L.Prusak, “Working Knowledge: How Organizations Manage What They Know,”Harvard Business School Press, Boston, 1998.2Argyris C., “Knowledge for Action,” (1993), San Francisco, CA: Jossey-Bass.3I.Nonaka, H.Takeuchi, “The Knowledge-Creating Company,” Oxford University Press 1995.4Frederick W. Taylor was an American engineer who introduced scientific factory management in the early19th century. His innovations in time and motion studies paid off in dramatic improvements in productivitywhich favors division of labor and, hence, the use of role-based teams.About the AuthorVadivelan Sivanantham is a Senior Manager in Cognizant’s Advanced Solutions Group. He is a full-timeAgile Scrum Coach and has CSM certification from the Scrum Alliance. Vadivelan specializes in performingAgile assessments and coaching Waterfall to Agile transitions. His software experience includes manyyears of handling projects in both Agile and traditional methodologies. Vadivelan received a bachelor’sdegree in engineering from Anna University located in Chennai, India and a master’s degree in informationtechnology from Bharathidasan University located in Trichy, India. He can be reached at Vadivelan.Sivanantham@cognizant.com.About CognizantCognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting, and business process outsourcingservices, dedicated to helping the world’s leading companies build stronger businesses. Headquartered inTeaneck, New Jersey (U.S.), Cognizant combines a passion for client satisfaction, technology innovation, deep industryand business process expertise, and a global, collaborative workforce that embodies the future of work. With over 50delivery centers worldwide and approximately 130,000 employees as of September 30, 2011, Cognizant is a member ofthe NASDAQ-100, the S&P 500, the Forbes Global 2000, and the Fortune 500 and is ranked among the top performingand fastest growing companies in the world. Visit us online at www.cognizant.com or follow us on Twitter: Cognizant.World Headquarters500 Frank W. Burr Blvd.Teaneck, NJ 07666 USAPhone: +1 201 801 0233Fax: +1 201 801 0243Toll Free: +1 888 937 3277Email: inquiry@cognizant.comEuropean Headquarters1 Kingdom StreetPaddington CentralLondon W2 6BDPhone: +44 (0) 20 7297 7600Fax: +44 (0) 20 7121 0102Email: infouk@cognizant.comIndia Operations Headquarters#5/535, Old Mahabalipuram RoadOkkiyam Pettai, ThoraipakkamChennai, 600 096 IndiaPhone: +91 (0) 44 4209 6000Fax: +91 (0) 44 4209 6060Email: inquiryindia@cognizant.com© Copyright 2011, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by anymeans, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein issubject to change without notice. All other trademarks mentioned herein are the property of their respective owners.