Hadi's post (The Bus number isn't agile, it's common sense ), was quite thought provoking... Loss of knowledge, be that temporary (someone on holiday) or permanent (moving on or retirement), is a massive problem for all kinds of businesses. This is even more critical in organisations who essentially sell their expertise, i.e. consultancy companies. Knowledge management for large organisations is a massive priority. However, SME's don't have the resources, expertise or drive to implement a framework for knowledge management.
The problem, which Hadi describes, is the impact short term loss of knowledge has on productivity. In terms of delivering a project the importance of sharing knowledge is crucial.
The long term loss of knowledge (a year after a solution is delivered) is a different problem. The global trend (or at least the trend in the USA), as observed by Daniel Pink in Free agent nation, is that people move on in their career much quicker than before. Loyalty to a particular company is replaced with vertical loyalty (loyalty to products, colleagues, ex colleagues, professions and family)... Jobs, are now gigs, or as Tom Peters says WOW Projects... You move from gig to gig, project to project. You may do several gigs for a single company... The key is that you are constantly developing, learning, achieving amazing things - you go to the best gig, the one with the biggest WOW factor. People will move on - the sufficiency of the project residue is now crucial to the long term maintainability of a product.
Addressing the short term problem can also address the longer term problem. If you subscribe to the CMMI, then your processes will ensure the repeatability of projects: a key premise is that the heroic effort of individuals to deliver a project is removed by reliable processes. If you have a certain level of process maturity these problems are said to be alleviated. I say, said to be, for a reason. Long term, a new team can read the reams of documentation and start to get an understanding of what went on. But, on a project, there is time to get up to speed... When you're delivering the product, you don't have time to get up to speed, getting up to speed costs in terms of productivity (slippage on the plan and eventually reduced profit margins).
Short term, teaming is the answer. In fact, effective communication is the answer. I say effective for a reason, because communication can also be a problem. The overhead of communication is positively correlated to team size, i.e. bigger teams more overhead (therefore lower productivity). Brooks observed, a long time ago, small sharp teams will destroy large teams in terms of productivity and product quality. If you have the optimum team size for your problem, then you're most likely in trouble if you work near a bus stop! Team size is a side issue. The issue is sharing information, or in Hadi's case, not creating knowledge silos (someone who knows everything about the GUI and nothing about the middle tier and vice versa). The way you get the most out of your team is effectively down to task division. In some cases task division means that you have people working solely on the GUI and others working on the back end. For example, if you agree a contract, let's say it's your WSDL, then one team can crack on with the implementation of the capabilities encapsulated by the web methods, the other can work on bringing those capabilities to bear via the GUI. Also, someone might want to do a certain bit of work more than someone else, they may be better at it and will do it quicker (note: just because they want to do something more than something else doesn't mean they don't also want to do the other thing...). Commercially, both these economies are important to providing good value for money and therefore cannot be ignored. You have a problem if those teams consist of two people, one person in the GUI and the other in the service implementation team. Now, you can still have the ability to switch between both (in the case where someone goes on holiday) without losing too much productivity. It, however, depends on two things. The first is the effectives of the communication; the second is level of listening of people in your team.
There are many things you can do create an environment for effective communication, and they are well documented in numerous books, in the context of software, and many other contexts. But, specifically, I'll highlight some (and a great place to read about them in more detail is Agile Software Development):
- "Osmotic" communication. Sit together. Don't go to a meeting room to have a chat, have a chat so others can hear. It's amazing what you hear by listening without knowing. A great example (I can't remember where this came from, probably my project management unit on my MSc): There was a coffee machine outside an IT lab in a university library. The machine was just outside the office of the helpdesk staff (people employed to help stuck students through problems). The staff complained about the noise of students congregating around the coffee machine, so it got removed. The number of people going to see the help desk staff shot up. The reason? People got stuck and went for a coffee. They met fellow students also stuck sipping their coffee pondering... They start chatting about their problems and before they know it, they've collaboratively solved it. On lookers, also stuck, drinking coffee heard them and were also able to try and continue. No more coffee machine, no more environment for collaborative problem solving. The help desk staff soon put up with the noise...
- Collaboration. Kind of carries on from that example above... Pair programming is the ultimate example of collaboration, it solves all the problems with knowledge sharing (unless they practice pair holiday taking and fly XL airways, then you might have a knowledge gap for longer than expected!) But, just because I'm working on the GUI doesn't mean I don't have good ideas about how to solve a problem in the data access layer and vice versa. Google, is sometimes our worse enemy. I can Google a problem and get a solution, or look for similar implementations, design patterns etc... However, if you solve problems collaboratively you build shared experiences which can be used when that person needs to work on what you've been working on. And, the old adage, two brains are better than one... Sometimes mealy talking aloud a problem you figure it out... That, with communication osmosis is extremely powerful. If you watch it happen, you'll also notice productivity is better...
- Build shared experiences. One of the biggest barriers to effective communication is the lack of shared experiences. You can communicate at a pace, if you share a common experience. You always look for ways to touch into them every time you talk to someone. Think about your recent conversations, you'll see what I mean. So, when the customer comes in to look at the GUI, get the back end guy in there to share the experience... If you DO collaboration, then you'll do this anyway.
- Create rich artifacts. Think about the purpose of the artifact... Is it to help Fred fix bugs in the GUI, or for Bill a year later to know everything about the product. Is it to document a customer requirement so Jim can implement it? Where shared experiences exist, simply create artifacts that touch into them and recreate the thoughts and experiences at the time of that conversation... Leave markers to enable the reconstruction of ideas. The least rich means of communication, by a massive order of magnitude, is the written word. It is impossible to completely document an experience, so don't try.
- LISTEN naively! The single biggest reason people don't like talking about their problems is because people don't listen; they assume they know the answer. Sometimes, simply listening is all you need to do. One of the biggest reason a product isn't a success is because people didn't listen to their focus group. The CUSTOMER is the source of the best ideas. Bottom up innovation is critical, not top down. Tom Peters advocates this in "A passion for excellence".
- Motivation. Don't make people collaborate; motivate them to do it... In fact, they will automatically be motivated to collaborate, what better feeling is there than knowing you've helped someone? Why do teachers teach? As project managers, do not hinder communication, don’t undermine people, don't be a devil’s advocate, encourage and enable communication. Be the facilitator; remove the interference from your team so they can effectively communicate. Except that failures happens and encourage people to share those failures.
There's certainly a LOT more... But it's not about software, it's about teamwork!
Now, what do I mean by levels of listening? There are limits to how effectively individuals can communicate. That's based on their ability. A top class software developer can draw on their previous experience, understanding of best practice and the problem at hand to synthesise a solution which solves the problem in the best way. When they communicate, this synthesis is happening to maximise the value they take from their conversations. A more junior developer cannot do this yet, they'll need support. You need to understand the makeup of your team and facilitate communication by having people on hand that can help cut through the fog. It is important they don't just solve the problems; rather they facilitate the others in solving the problems. If the problem is too complicated and economic reasons mean the senior guy needs to do it, make damn sure he talks about what he's doing (creates the shared experience)! This also creates a great learning environment, which is critical to staff retention. Hertzberg defines motivation as a function between ability and opportunity to use that ability. The more you can do, the more you can be motivated to do. That's the reason why training is one of the biggest motivators. By motivating your staff, you're also increasing the composite capability of your company... Training is win win, especially when it's free like facilitated on the job learning is...
If you do these things, then someone going on holiday means that another person in the team is MOTIVATED to pick it up and solve the problem. It is that level of motivation that will keep your productivity at a reasonably constant level. Also, if the project is highly collaborative, learning will be high, therefore, it'll be a good place to be... People will stay, because the next project is the next gig they want to play at! Teamwork wins!