Sharing Knowledge

In my early days of computing back in the late 70s and early 80s, having an interest in microprocessor design was unusual. I remember getting almost monthly updates from Motorola and Intel on their latest chips and my shelves were filled with technical manuals.

Information flowed freely and it felt that we were part of a community figuring out how to use microcomputers in our daily work. There was a common feeling of camaraderie and it wasn't uncommon to be able to pick up the phone and ask a technical question of a person who worked at a completely different company. We often posted what we learned on bulletin boards so others could benefit.

Then along came Microsoft. Software became a business and knowledge about how to do it became a valuable commodity. The industry started to close down and people were less ready to share information with those outside their company.

I've been at companies where people try to increase their value to the company by knowing more than other people and guard that information so that they retain that competitive advantage. This is really a post-industrialist perspective and it has no place in the Agile mindset.

In Agile, we encourage and reward exactly the opposite. We want people to share information and knowledge freely because we know that it not only helps them but it also helps all of us. We try to pair and work with as many different people as we can because we know that we have something to learn from everyone and through that process we improve as well.

Hoarding knowledge is not good for anyone. It puts your company at risk because you oftentimes become a critical resource for a particular tool or technology that only you can fix if it goes down and important things depend on it staying up. That's also bad for you because it means that you can't take a vacation or move on to other projects, so you may have job security but that can also make you stagnant.

In Agile, we want to be the guy or gal who helps others. We want to learn from them and we want them to learn from us. We really discourage specializations on a development team because we want it so that any developer can work on any part of the code. We also wanted so that all the code conforms to a uniform look and feel. This supports collective code ownership and allows people to read and understand a system more quickly and efficiently.

So, the best source of radiators are the people themselves because we're always sending and receiving information. We want to work in an information-rich environment where we constantly know the status of our build and what we're working on as well as what everyone else is working on.

As Rich Sheraton, author of Joy, Inc. says, we want to "filter out ambiguity" so people have a clear sense of the purpose of their work. This helps people get more meaning from their job and share knowledge more readily. Software development is a constantly changing field and so we want to be immersed in constant learning.