Lack of Knowledge Sharing Indicators in Distributed Agile Development
Posted by Jai on March 12, 2009
The success of any project is truly measured by the real outcome in terms of what the intent of the project/product was. It may be the ROI or some other measurement criteria. The delivery model, the client focused delivery we talk about is keeping in mind the end result which is the success of the project and which is hard to measure satisfying all the parties. That is where the Agile process makes it more flexible to indulge every party in the process and all working together for the common goal. Both the parties the client and the project implementing party work together from initial stage and very closely and open to the changes during implementation and deliver the product regularly for the feedbacks.
To work that closely with the client the domain knowledge and the functional knowledge plays important role and this knowledge sharing between both the parties makes the project to be successful. In case of Agile Distributed Development it asks for additional responsibility to share and pass this knowledge among team members to make it success.
Usually it is the client who keeps a tap on the requirements and latest happening in the market, the domain of the project. And sometimes the client hire the domain expert to help the other party to get the things done.
As both the parties are dedicated to the success of the project, it puts some responsibility on the implementing party also to suggest the ideas if any and which may impact the project success and behavior but after all the call still lie with the client. Point is both should be open to new ideas.
The team working offshore is always left out with out some of the functional knowledge. Either it may be because of single point of contact/client proxy or the communication problems or not every team member kept in loop for everything or may be not every developer giving that much importance to have full idea about the application. How important role does this functional behavior plays in the overall process. Can you assume the success of the project with out keeping in mind that everyone is aware of the things.
If the developer is not aware what is the bigger picture, it always comes back and bites back all. If just writing down the few lines of code is one’s job, it certainly won’t help to achieve the goal. Lack of functional knowledge will always lead to hidden/known issues and definitely quality issues.
The total time spend in functional knowledge transfer to the offshore team is comparatively very less in comparison the on-site team having full access to the client.
This is very general situation that different people having different level of expertise in different technologies. If you are not going to work on a particular piece of technology then you can assume that you need not to worry but that is not the collective code ownership and not very much possible in usual scenarios. Either you can choose to divide the team in horizontal brackets to keep the dedicated people working on one technology or you can choose to divide the team in vertical brackets and on regular rotation basis, the long term results will be self explanatory. Plan the knowledge sharing sessions with in the team so that every team member is aware of what is happening in the other part of the application and will help to the success of the project in real terms.
Lack of Knowledge Sharing Indicators:
The lack of knowledge sharing with in the team is very much get reflected soon enough looking at the different behaviors and problems:
Extra time to complete the task: If the clarifications for the task is taking extra time and team members are not getting clarity then you need to think twice to get the team up to the speed. The time wasted in getting the clarifications which could have been avoided by knowledge sharing would directly reflect it.
Degrading Code Quality: The degrading code quality is one of the direct indication of the lack of knowledge sharing. The reason can be anything like not knowing the bigger picture and the current design does not take care of other requirements and may the team member working on the task is not very familiar with the technology he is working on.
Wrong time estimates for the task: If the time estimations for a particular functionality or technology is more than the expected one gives the indication that the team is not very comfortable in it and requires urgent attention.
Important details are missed/overlooked: If for a particular task the important details are missed or overlooked by the team, leaving aside the obvious human errors, gives the indications that the team is missing the bigger picture somewhere.
Team asking for documents: Well you only need adequate documentation but if team members are very frequently asking of documents for everything indicates that something is not right. The documents are going to be irrelevant soon or later and try to minimize the use.
Hesitation in task assignment: If the team members are hesitant in picking up one particular type of tasks, may be one particular functionality or technology, reflects the lack of confidence.
Dependency on selected people: If the team members are usually dependent on selected people for problem resolution which may be for some functional part or technical help indicates that the knowledge is not shared among all.
Knowledge Sharing Management:
The whole idea is to support the face-to-face communication for knowledge sharing over heavy-weight and document centric approaches. The topic itself is big enough to discuss and different teams use different methods for the knowledge management. Some teams plan regular sessions every sprint for knowledge sharing. Some teams use wiki for sharing minimal information. Some teams use regular rotation of members to work on different modules. Some teams organize special sessions and trainings for domain and technical knowledge. It all depends on the team how they plan and organize it which works best for them.