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.

The Medium

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. 

The Messages

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. 

The Mindset

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. 

The Practices

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. 

Moving Forward

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)