Knowledge Sharing on Agile Projects: Absent or Abundant?
May 08, 2015
Knowledge transfer and sharing on agile teams differs from traditional approaches in both form and the internal vs external focus. Agile teams produce few of the traditional knowledge transfer documents yet their daily practices focus on knowledge transfer. While agile teams spend much of their time transferring information internally they share little with external groups other than the evolving product or service they create. These differences lead to some polarizing views of knowledge sharing and transfer on agile projects.
Some people see agile projects as knowledge transfer deserts where information is hoarded by key individuals and no useful documentation produced. Others believe agile projects are all about knowledge transfer. So why the disagreement, how can smart, experienced people have such different views about the same topic? It comes down to what we consider knowledge transfer and sharing to be.
A requirements specification document should be a great vehicle for sharing knowledge and transferring it from analysts to developers. It is a permanent record of requirements that can be read by many people and referred back to when needed. If questions or the need for clarifications arise – go look in the requirements specification. This works well for stable, unchanging requirements that can be gathered comprehensively up front.
Baselined plans are great knowledge sharing tools too. They lay out what should happen, when and by whom and paint a clear picture for all to see. Plans illuminate the path forward and communicate this to all involved stakeholders. Lessons Learned documents gathered at the end of a project are classic knowledge transfer and sharing tools also. Recording what went well, what did not go well and recommendations for similar projects to follow seems the epitome of knowledge transfer.
Agile projects down play the value of upfront plans, avoid detailed requirement specifications declaring them unreliable and wasteful. They often spurn Lessons Learned documents too, instead performing retrospectives amongst themselves. It is no wonder then, that to some people agile projects appear to lack the basics of knowledge sharing and transfer. However these people are measuring with the wrong yardstick, or fishing with the wrong size net and missing the knowledge rich plankton that feeds agile teams. When you “see the matrix” of agile projects you immediately realize the whole process is about knowledge transfer.
Agile projects are the domain of the knowledge worker. They engage Subject Matter Experts (SMEs) who are brought together to collaborate and solve novel problems. Their work is often invisible, the 0 and 1’s of software, the design of a new drug, or building blocks of a reading program for dyslexic students. These problem domains are abstract and often don’t have a visible, tangible, emerging product like a building or pipeline. Instead ideas and information are the currency of the project and agile methods have developed to process it more efficiently than paper documents can.
Paper documentation turns out to be the least efficient, most time consuming way of communicating that we typically use. Alistair Cockburn illustrates this with his now famous effectiveness, efficiency diagram shown below.
From the graph we can see paper documentation is slow to create, does not allow for questions or clarification and has to assume the lowest common denominator of understanding. So, when knowledge transfer is your focus and project speed is directly linked to knowledge transfer speed we need better tools to get the job done. This is the business case for team co-location; if the transaction cost for team member A asking a question of team member B is 2 minutes via telephone or email verses 30 seconds through face to face communication then there is a 4x benefit of co-location. Since these types of information exchanges are a large part of knowledge worker agile projects this is why we try to co-locate teams whenever possible.
In addition to improved efficiencies of transferring explicit project knowledge, co-located teams also share tacit (local, unwritten) knowledge such as how to restart the build server or restock the 3D printer. Physical co-location greatly amplifies the flow of this tacit knowledge that permeates from people within earshot of daily conversations. The diagram below shows how moving from cubicles to open co-location helps sharing knowledge.
A downside of co-location can be noise pollution. Working in an open environment is useful when everyone is on the same project, but overhearing snippets of conversation about unrelated projects can be very off putting. While headphones might seem an easy fix for these situations, workers then miss out on many of the benefits of co-location with their team mates.
Agile projects deliberately have a flat communication structure since everyone has import information to share. Centralized top down, command-and-control communication structures are replaced with distributed, middle-out communication model. Instead of project managers distributing task lists of work to be completed Stand up meetings share details of work being undertaken and issues arising.
Collective Sprint Planning meetings distribute work scheduling and techniques such as Fist of Five voting and Planning Poker estimation leverage team knowledge and group decision making whenever possible.
Leaders are still required, but the role may circulate. Managers switch from Directive to Inquisitive, understanding that solving problems is more rewarding and motivating for people than following orders. “Power Over” concepts are switched to “Power With” ideas as McGregor Theory Y motivation concepts are used.
Agile team practices are focussed on knowledge sharing. The graphic below shows some of the Extreme Programming (XP) practices:
If we highlight the knowledge transfer aspects of these practices it is easy to see how focussed they are on knowledge transfer.
Extreme Programming (XP) is one example, but the ideas repeat in other agile methods too. Communication is deliberate and frequent with the aim of surfacing and correcting misunderstandings as quickly as possible. Decisions are collaborative and designs kept as simple as possible to maximize the number of people who understand them (and because the best designs are often the simplest).
Internal vs. External Information Sharing
While agile teams go out of their way to communicate, collaborate and improve together, these actions tend to be within the team. Externally stakeholders see product demonstrations but less written material because communication and knowledge transfer is deliberately being handled through higher bandwidth mediums.
This intense internal communication and outward demonstration of product progress leads to some misunderstandings. It creates a sense of mystique, external parties don’t get to see what goes on internally since lots of it is face-to-face leaving no written record. So, these agile teams work closely together “doing agile stuff” and (hopefully) out pops working products and services.
Organizations not understanding the deliberate and concentrated knowledge sharing practices of agile teams sometimes fail when trying to replicate the success of effective agile teams. They see a bunch of people working together and think they need only provide a common work space and the occasional team pizza. However, as we have seen, successful knowledge sharing and transfer in XP is achieved through numerous core practices that take discipline to execute. The same is true with all the other agile approaches and not only do the teams have to execute them, but also own these processes and evolve them too through reflection and adaptation.
Ironically agile methods recommend producing few of the traditional knowledge transfer documents but they are very focussed on knowledge transfer and sharing. From the outside agile teams may appear to be just talking and working away at a product or service. However the practices they employ are actually nested cycles of information sharing. They range from pair programming to encourage information transfer and sharing on a minute by minute level; to daily meetings to keep team members informed, weekly demos and bi-weekly retrospectives.
Knowledge transfer is the name of the game, it is just they have upped the currency from written formats that are slow to produce and maintain to models and shared knowledge that is more cost effective to create and consume - but lacks the persisting nature of written documents.
Lack of written documentation has its downsides; documents can be consumed later and referred back to for clarification. Video recordings could provide these attributes but currently searching video is not that easy. I can quickly search a file structure for references to “widget 49 specifications” but scanning video recordings for voice and whiteboard sketches about the same thing is currently not that easy.
Agile methods have created great ways to transfer and share knowledge with the team but still fall short keeping this knowledge searchable and sharing it externally. Hopefully tomorrow’s project approaches will solve these issues and we can collaborate at the speed of drawing and talking to our peers while not losing the benefits of perfect recall and easy sharing. Imagine a synthetic team member with IBM’s Watson like language processing skills or the Ship’s Computer from Sci-Fi films. A robot on the team we can ask: “What did Bob say last week about Flux Capacitor voltages?” or “What major decisions did I miss while on vacation last week?” These robots may well make better team members than I am, but I will save that concern for another day.
(This article first appeared in the Knowledge Sharing edition of ProjectManagement.com here)
I enjoyed reading your post. It is a very interesting. I never thought of agile management as knowledge sharing and transferring. All requirements of specific documents for projects are in fact sharing and transferring knowledge. These documents includes communication plan, lessons learned documents, and so on. Furthermore, you also emphasized which method of communication is effective and how important it is to have co-located team members. You suggested face-to-face is more effective than other methods of communication and you recommended co-located teams because of it.
Business world is changing and many companies are having virtual teams, including project or agile management. Based on your article and your point of view, do you think virtual team can communicate and share and transfer knowledge as effective as co-located team?
Posted by: Batchimeg Shagdarguntev | September 18, 2015 at 03:45 PM
Thanks for your comment. As for your questions: “Do you think a virtual team can communicate and share and transfer knowledge as effective as a co-located team?” I would say, No, not as effectively, but maybe effectively enough given the cost trade-off of face-to-face.
Also, we are getting more accustomed to virtual communications and technology is improving. Maybe in 10 years I would rather have a great team member available remotely versus a good team member available locally. Currently I would err towards good-and-local over great-and-remote and always over good-and-remote. It is just more efficient for conveying meaning/understanding/agreement/commitment both to and from each other.
Some work does not need this connection. If all I need to know is the temperature in Moscow, I don’t care who I get that from. If I have to collaborate with someone to build a new website, drug or car I would really like to be co-located. Like most trade-offs, it is never as simple as “A” Always Over “B”, some work will be fine done remotely, some work will have to be done remotely to keep costs reasonable, other work is best done in a co-located way to maximize communication channels.
Posted by: Mike Griffiths | September 21, 2015 at 02:23 PM