Knowledge Management in Agile Projects


Published on

Managing knowledge, both explicit (objective) and tacit (personal), is the key to software development. In Agile projects, management is facilitated by cross-functional, rather than role-based, teams, and daily Scrum meetings, retrospectives, pair programming and rotation and release iteration.

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Knowledge Management in Agile Projects

  1. 1. • Cognizant 20-20 InsightsKnowledge Managementin Agile Projects Executive Summary but the knowledge held by the employees and the development culture of an organization. Software development is knowledge-intensive Companies developing information systems work and the main challenge is how to manage have failed to learn effective means for problem this knowledge. The Agile manifesto advocates solving to such an extent that they have “individuals and interaction over process and learned to fail. The key drivers for companies tools,” and hence it requires even more attention to manage knowledge effectively in software to manage knowledge in Agile projects. development are: This paper demarcates the types of knowledge involved in the lifecycle of software projects and • Reducing the effort spent in acquiring required knowledge for project execution. describes the mechanisms to effectively manage them in Agile software development. It then • Improving reusability (i.e., avoiding argues for the need to scale Agile development reinvention). strategies in knowledge management to address • Reducing dependency on individuals for the full delivery process. project success. Knowledge Management in • Improving the overall team’s productivity. Software Development Knowledge Types Knowledge management is “a method that Typically, knowledge can be classified into two simplifies the process of sharing, distribut- types, explicit and tacit. ing, creating, capturing and understanding the company knowledge.”1 Knowledge itself “is a fluid Explicit knowledge is knowledge that is articulable mix of framed experience, values, contextual and transmittable in formal, systematic language. information and expert insight that provide a This can include grammatical statements, math- framework for evaluation and incorporating new ematical expressions, specifications, manuals experience and new information.”2 Furthermore, and so forth. Such knowledge can be transmitted “knowledge passes through different modes of formally among individuals with ease. conversion, which makes the knowledge more refined and spreads it across different layers in Tacit knowledge is personal and context-specific, an organization.”3 and is therefore difficult to formalize and commu- nicate. It is embedded in individual experience and The main assets of software development are not involves intangible factors such as personal belief, manufacturing plants, buildings and machines perspectives and value systems. Tacit knowledge cognizant 20-20 insights | january 2012
  2. 2. is difficult to communicate and share in an organi- projects? What should be the relative levels ofzation and thus must be converted into words or focus on explicit knowledge vs. tacit knowledge?other forms of explicit knowledge. This paper will address these queries.The Knowledge Lifecycle in Knowledge Management in TraditionalSoftware Projects Software DevelopmentThe knowledge life cycle in software projects can Traditional software development approachesbe described in five steps. organize the required knowledge sharing based on different roles following a Tayloristic4 mind-set:1. Gather available explicit knowledge. people involved in the development process are Generally, this happens during the start of assigned specific roles (e.g., business analyst, the project whereby available knowledge is software architect, lead designer, programmer, captured and made available in knowledge tester, etc.) that are associated with specific bases, marketing, different departments, etc. stages in the development process (requirements2. Personalize explicit knowledge. The gathered analysis, high-level design, low-level design, information/knowledge needs to be converted coding, testing, etc.). by the individuals involved in the projects into Limitations tacit knowledge. Knowledge sharing between each of the stages3. Application of the acquired knowledge. is primarily document based (i.e., through explicit Converted tacit knowledge will be applied to knowledge). One role produces a document (e.g., the project execution. requirements specifications, design documents,4. Learning from the project. There could be source code, test plans, etc.) and hands it off to some learning, innovations or new methods or the people responsible for the next stage in the techniques uncovered during the execution of development process. the project which will be in the form of tacit knowledge. Assuming merely 5% of relevant information is lost in each transfer between the stages, nearly5. Convert to explicit knowledge. The learning a quarter of the information does not reach the needs to be converted into explicit knowledge coder (who has to encode the domain knowledge and added to the repository for future into software) in a Tayloristic development reference. process. The results are even worse if more thanThere are many questions related to knowledge 5% is lost in each, especially in Agile projects: How Another problem resulting from the long commu-different is it to manage knowledge in Agile nication chains in Tayloristic software organiza- tions is a tendency to over-document. Informa-The Knowledge Circle tion is useful only when it is new to the receiver; providing a known fact to somebody is old, boring news. In fact, such repetition makes it more difficult to find the relevant “gems” of information 1 Convert the in a document and hence increases knowledge Learning to Available transfer costs. People involved in the early stages Explicit 5 Knowledge Explicit Knowledge of software development do not (and cannot) for Future know what information is already known to the Reference coders. Relevance of information is completely Learning from 2 subjective in the sense that it depends on the Personalize the the Project in the Explicit Knowledge Form of Tacit current knowledge of the information receiver. i.e., Convert to Knowledge Tacit Knowledge Application Knowledge Management in of Acquired Knowledge to Agile Software Development 4 Project Execution Agile software development relies on direct com- 3 munication — i.e., synchronized and osmotic com- munications between customers and developers for knowledge sharing. This reduces the informa-Figure 1 tion loss due to long communication chains and cognizant 20-20 insights 2
  3. 3. it ensures that only questions that the developer Pair programming involves two developers(who writes the code) has are answered. working in front of a single computer designing, coding and testing the software together. It is aTransferring and sharing required knowledge in a very social process characterized by informal andteam is a difficult task that in the traditional model spontaneous communications. During a pair pro-was tackled by introducing rigorous processes gramming session, knowledge of various kinds,and more and more structured and formalized some explicit but mostly tacit, is shared betweenrepresentations. While there are merits to that the pair. This includes task-related knowledge,approach, the recent trend towards Agile software contextual knowledge and social resources.processes focuses on a less formal, “fuzzier”style. It replaces “logical” representations by • Examples of task-related knowledge includeapproximations – approximations that are “good system knowledge, coding convention, designenough” for humans to proceed with develop- practices, technology knowledge and toolment but rely on the sharing of tacit knowledge usage actually do so. • Contextual knowledge is knowledge by which facts are interpreted and used. For instance,In Agile processes, knowledge sharing is knowing from past experiences or “warencouraged by several practices: stories” whether or not to use a particular• Release and iteration planning. design pattern in different coding scenarios.• Pair programming and pair rotation. • Examples of social resources include personal contacts and referrals. Developers tend not to• Daily Scrum meetings. document these types of knowledge for many• Cross-functional teams. reasons, such as being overburdened with other tasks or deeming what they know to• Retrospectives. be irrelevant or of no interest to others. SuchRelease and iteration planning are used to share knowledge is often only uncovered via informalknowledge on system requirements and the and casual domain between on-site customersand developers. In a release planning meeting The social nature of pair programming make itarranged at the beginning of a project, the project a great facilitator for eliciting and sharing tacittimeline is broken down into small development knowledge. To ensure knowledge shared among aiterations and releases. pair is accessible to the entire team, it is recom- mended to rotate pairs from time to time. As aAt the beginning of an iteration (a short, side effect of tapping tacit knowledge, the socialtime-boxed development effort that runs usually nature of pair programming helps to create andtwo to six weeks), the development team and the strengthen networks of personal relationshipscustomer representatives discuss what should within a team, and to nurture an environmentbe done in the next few weeks. The discussions of trust, reciprocity, shared norms and values.refine the initial requirements to a level that the These are critical to sustain an ongoing culture ofdevelopment team is able to estimate the develop- knowledge sharing.ment effort for each feature. Further requirementdetails are discussed with on-site customer repre- While pair programming sessions facilitate com-sentatives while a developer actually works on the munication within a pair, daily Scrum meetingsimplementation of a feature. The close interaction facilitate communication among the entire team.between developers and on-site customer repre- During a daily Scrum meeting, team memberssentatives usually leads to increased trust and report their work progress since the last meeting,better understanding. This direct feedback loop state their goals for the day and voice problems/allows a developer to express a good approxima- suggestions related to their tasks or to theirtion of the requirements in his head faster than colleagues’ tasks. Such meetings provide visibilitydocument-centric information exchange could. of one’s work to the rest of the team; raiseQuickly developed software can be demonstrated everyone’s awareness of who has worked on orimmediately to the customer representative and is knowledgeable about specific parts of theallows her to directly catch misunderstandings. system; and encourage communications among cognizant 20-20 insights 3
  4. 4. team members who may not talk to each other retrospective meeting and ensure that this isregularly. Team members learn whom to contact converted into explicit knowledge (through docu-when they work on parts of the system that they mentation) and published in a common area thatare unfamiliar with. everyone can access. The common area could be a lightweight collaboration Website like a WikiTo reduce the communication cost among the which should act as a collaborative knowledgevarious roles that are involved in software devel- repository for the team.opment — such as business analysts, developersand testers — Agile methods recommend the use The majority of the information captured in tradi-of cross-functional teams instead of role-based tional specification documents, such as require-teams. A role-based team contains only members ments specifications, architecture specifica-in the same role. By contrast, a cross-func- tions or design specifications, can be capturedtional team draws together individuals of all as “executable specifications” in the form ofdefined roles. Experiences indicate that cross- tests. When you take a test-driven developmentfunctional teams facilitate better collaboration (TDD) approach, you effectively write detailedand knowledge sharing, which leads to reduced specifications on a just-in-time (JIT) basis. Withproduct development time. TDD, you write a test, either at the customer/ acceptance level or the developer level, beforeContinuous learning is supported by some Agile writing sufficient code/functionality to fulfill thatmethods in the form of project retrospectives. test. The tests accomplish two purposes: theyRetrospectives are in essence post-mortem specify the requirements/architecture/design andreviews on what happened during development, they validate your work. This is an example of theexcept that they are conducted not only at the practice of single source information.end of a project but also during it. Retrospec-tives facilitate the identification of any success Make it a practice to create needy documents —factors and obstacles of the current management i.e., if and only if they fulfill a clear, important, andand development process. In cases where team immediate goal of overall project efforts. Don’tmembers face obstacles of the current process, forget that this purpose may be short-term orsuch as lengthy stand-up meetings, retrospec- long-term; it may directly support software devel-tives provide the opportunity for these issues to opment efforts or it may not. Also, rememberbe raised, discussed, and dealt with during the that each system has its own unique documen-project rather than at the end of the project. tation needs, that one size does not fit all. The implication is that you’re not going to be able toLimitations follow a “repeatable process” and leverage theAlthough the concept of learning is embedded same set of documentation templates on everyin various Agile software development practices, project, at least not if you’re interested in actuallyas shown above, these practices only address being effective.knowledge sharing within a team. They do notaddress issues of knowledge sharing across team Conclusionboundaries. In a large organization, there may Traditionally, software development teams followexist multiple teams that work on similar tasks, the Tayloristic approach favoring division of labor;face common problems or have overlapping hence, the use of role-based teams. Role-basedinterests in specific knowledge areas. In short, teams with handoffs between job functions havethere is a lack of explicit support for organiza- the inherent problem of amplifying the problemtional learning. Also, there will be instances where of miscommunication due to indirect and longAgile teams are distributed due to the nature communication paths (i.e., knowledge sharingof business, which also makes tacit knowledge through explicit knowledge).sharing difficult. Agile development teams address this problem byTo address this, we need to have lightweight using cross-functional teams, which encouragesmechanisms to convert tacit knowledge into direct communication through release andexplicit knowledge in Agile software development. iteration planning, pair programming and pairSome of the mechanisms are as follows. rotation, and daily stand-ups and retrospectives — all of which reduces the likelihood of miscom-Agile teams should make it a practice to capture munication. They rely on various practices whichlearns in a particular Sprint as part of every emphasize approximate knowledge sharing by cognizant 20-20 insights 4
  5. 5. social interaction and fast feedback loops instead well if the teams are distributed. To address this,of structured (logical) representations (i.e., Agile teams should not only rely on the knowledgeknowledge sharing through tacit knowledge). sharing through tacit knowledge but should also employ lightweight explicit knowledge sharing likeHowever, there are major inherent limitations to test-driven development, needy documentation,the various knowledge-sharing practices used by usage of Wikis, and the discipline of capturing theAgile teams in their original forms. They do not learns through retrospectives.facilitate inter-team learning and also do not workFootnotes1 T.H.Davenprot, L.Prusak, “Working Knowledge: How Organizations Manage What They Know,” Harvard Business School Press, Boston, 1998.2 Argyris C., “Knowledge for Action,” (1993), San Francisco, CA: Jossey-Bass.3 I.Nonaka, H.Takeuchi, “The Knowledge-Creating Company,” Oxford University Press 1995.4 Frederick W. Taylor was an American engineer who introduced scientific factory management in the early 19th century. His innovations in time and motion studies paid off in dramatic improvements in productivity which 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 informa-tion technology from Bharathidasan University located in Trichy, India. He can be reached at CognizantCognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting, and business process out-sourcing services, 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 or follow us on Twitter: Cognizant. World Headquarters European Headquarters India Operations Headquarters 500 Frank W. Burr Blvd. 1 Kingdom Street #5/535, Old Mahabalipuram Road Teaneck, NJ 07666 USA Paddington Central Okkiyam Pettai, Thoraipakkam Phone: +1 201 801 0233 London W2 6BD Chennai, 600 096 India Fax: +1 201 801 0243 Phone: +44 (0) 20 7297 7600 Phone: +91 (0) 44 4209 6000 Toll Free: +1 888 937 3277 Fax: +44 (0) 20 7121 0102 Fax: +91 (0) 44 4209 6060 Email: Email: Email:© 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.