When you think of inducting a new developer in existing project, it's relatively easier to do it in an Agile software development project than in a traditional project. The atmosphere and programming culture is entirely different here compared to any traditional project. Instead of people working in isolation and being responsible for assigned tasks, people here work in a mode where frequent communication across table is necessary. Instead of one person being responsible for assigned tasks, the whole team is responsible to complete it. The mantra is efficient communication and more interactions. So when a new developer enters the Agile project (Scrum + XP based), pair programming, communication across the table makes a person comfortable with the new project environment. Instead of going through bulk of developer's handbook and design document, conversations help to bridge the gap. However when you need to really need to refer some documentation, it's always there. Also new developer continues to develop on top of whatever existing team has built on. So you see, knowledge transfer is seamless and relatively easier compared to any traditional project. Think about maintenance phase now. First of all, application is already existing. You may not have to enhance it further. So the scope of learning while developing software is not there. You get a production problem and now you have to see in which part problem lies. Developers who developed the application may not be there anymore. You may be in a situation where you don't have any knowledge base of the project. You may try hard to go through the application with source code analysis but a normal human becomes helpless analyzing 1 million lines of code-base in a complex project. Understanding application with source-code analysis may not be the ideal way in this case. So you see knowledge transfer in maintenance phase may be a lot more trickier than in normal development cycle.
What all is required in knowledge transfer?Considering all these issues, I am going to talk about an approach for knowledge transfer (KT) used in one such complex maintenance project. To start with, in generic terms, KT can be divided in following parts:
- Application Overview - 20,000 feet view on the project as a whole. Generally it needs to be described on white-board. Many of the times, this discussion gets recorded as video and becomes the documentation for new joinee
- Application Architecture and technical design - Again focusing on broad perspective of the application. But in this case, instead of taking a look from 20,000 feet, we dive a little deeper. Explained and documented in the same way as mentioned for Application Overview
- Sessions for knowledge transfer of different application components describing functional and technical aspects. Some of the documentation is available. Rest is improved with the understanding of each new joinee
- Scrum Process - How a team does the Scrum in the project. It may be a little different in maintenance project as it generally follows Type C Scrum. The documentation is generally available on project wiki.
- Demo of running application - Whatever you talk about theoretically, may not make sense if you can't think it visually.