Knowledge Transfer in Agile Maintenance Projects

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.

How do we do KT?

For doing the KT we adopted following methodology.

Set up the development environment

The first step a new joinee takes, is to set the development environment. Project knowledge-base should be prepared in a such way that time-waste is minimal. So one-touch build is recommended. Instead of getting project softwares from internet and wasting time, they may be available in the local repository. Similarly for setting up the project-environment, a screen-cast can be prepared which becomes handy instead of asking people for trivial things.

Study the documentation available

Before new developer gets involved with the knowledge transfer along with senior developers, he need to first study the documentation available in the order mentioned by project-mentor. It provides the initial impression of the application to the new joinee.

Create a wiki page defining schedule and review

Instead of doing the knowledge transfer on adhoc basis, it's important to properly plan it using wiki pages. Here one plans for the time require from team members and schedule the whole knowledge transfer to be effective. Keep in mind to add some slack in the schedule for the new joinee to digest the information.

Team involvement in knowledge transfer

Instead of doing the knowledge transfer in teacher/student mode, it's more about teacher+assistant teachers transferring the knowledge to a student. The basic reason of doing that is to reinforce the application concepts in the team. It's good for teachers as well as for students. Depending on questions/answers, different perspectives come out while discussing a concept which is good for team in general.

Last person taking KT conducts the KT for a newcomer

It works pretty good to reinforce the project-concepts for a team-member. He becomes the main teacher assisted by other senior teachers. By having the healthy discussion on project topics, it works well for the entire team. So instead of having a team of one expert, there will be multiple project experts. The methodology mentioned, encourages the teacher to ask other assistant teachers their opinion on the available information. It gives almost every time a new insight in the knowledge. Sharing/discussing knowledge increases the knowledge itself.

Improvements in the documentation

Along with knowledge exchanged between senior developers and new joinee, a very important task is to document the gap new joinee could see in the available documentation. It's simultaneous effort along with continuing knowledge transfer. It's important because with the improved documentation in form of multimedia and written documents, next KT becomes even more easier.

Conclusion

As you can see based on above mentioned discussion, knowledge transfer in an Agile maintenance project is not same as may be a case in an Agile development project. It poses different kind of challenges to the team. Above mentioned strategy worked very well to handle the knowledge transfer of a complex project. Any suggestions for improvements areas are welcome.

Comments (10)

  1. AVH - Reply

    August 19, 2008 at 7:52 am

    I see a lot of emphasis on documentation again and again. If you are doing XP there are 2 arifacts code & test cases. And why would any developer need to go through a gazillion lines of code if you have proper test cases in place? I think the project is not done using Agile development techniques.

  2. Lars Vonk - Reply

    August 19, 2008 at 2:49 pm

    Hi AVH,

    I agree with you that test cases and code are the most important artifacts of your project. But testcases and code is by far not enough to get an understanding on the application architecture. As a new joiner on a project, or as the application maintainer you will definitely need such an overview.

  3. AVH - Reply

    August 20, 2008 at 8:46 am

    Right, so are you saying that the application architecture is documented? and i guess updated regularly too because in an Agile project architecture is evolves. So you have people document and update the architecture regularly? Does not sound like Agile but may it works in your scenario

  4. Shrikant Vashishtha - Reply

    August 20, 2008 at 9:11 am

    When we talk about documenting project overview or architecture overview, the kind of documentation we are talking about here, itself is Agile. Instead of creating documents as project evolves in stages and updating it time and again, we are talking about explaining it on white-board along with question and answers from audience and get it recorded as video (please take a look at http://blog.xebia.com/2008/05/05/agile-way-of-documentation/). Also we do it when project functionality/architecture are in stable/later stage (that's where we need them too). It doesn't take that much time as it would have taken in documenting it and then reading it. Also, it's more effective and easy to grasp for the newcomer. When you talk about source-code and test-cases, I find them too fine-grained to take out the bigger picture out of them. It's definitely not easy to see source code of 1 million lines of code and then abstract out the functionality of the application. It doesn't and can't work irrespective of whether we work Agile or with traditional approaches. The audience and focus of different kind of knowledge base will be different and it makes a huge difference. It may sound a bit of non-Agile, but I think documentation is not as bad as it may sound. It all depends on how you create it (multimedia answers some of the questions) and improve it to reduce waste which implicitly takes us towards "just enough".

  5. Erwin van der Koogh - Reply

    August 21, 2008 at 11:46 am

    "Working software over comprehensive documentation."

    "That is, while there is value in the items on the right, we value the items on the left more."

    Please remember the "while there is value in.." in all clauses of the Agile Manifesto.
    Not all documentation is inherently evil, just most of it.

  6. [...] you'll have one team working on two projects doing pair-programming. You may want to take a look on a blog on knowledge transfer in Agile maintenance for [...]

  7. AVH - Reply

    August 22, 2008 at 9:58 am

    When you talk about source-code and test-cases, I find them too fine-grained to take out the bigger picture out of them. It’s definitely not easy to see source code of 1 million lines of code and then abstract out the functionality of the application.

    So I am not just talking about unit tests here. How about integration tests, acceptance tests?

  8. Shrikant Vashishtha - Reply

    August 27, 2008 at 12:49 pm

    They definitely help in understanding the functionality of the application but I don't think they're sufficient as you need some context to relate that functionality. So when you want to talk about some stories, background, design decisions, why the application is the way it is, architecture, integration/acceptance tests don't help. You need someone to talk about them on white-board, some conversations with question-answer sessions. And if you want to preserve this knowledge base, you may want to record it.

  9. [...] you'll have one team working on two projects doing pair-programming. You may want to take a look on a blog on knowledge transfer in Agile maintenance for [...]

  10. Akilah - Reply

    January 24, 2014 at 5:15 am

    I tend not to leave a bunch of responses, however after reading through a few of the responses on Knowledge Transfer in Agile Maintenance Projects . I actually do have a few questions for you if it's allright. Is it only me or do some of these remarks come across as if they are coming from brain dead visitors? 😛 And, if you are posting at additional social sites, I'd like to keep up with you. Could you list of all of your social networking sites like your twitter feed, Facebook page or linkedin profile?

Add a Comment