Multimedia

Knowledge Transfer in Agile Maintenance Projects

ShriKant Vashishtha · August 15, 2008 · Leave a Comment

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.

Preparing for Agile Maintenance – Knowledge Management

ShriKant Vashishtha · August 14, 2008 · Leave a Comment

When you think about documentation in Agile software development, most of the times it talks about “just enough” which definitely makes sense considering the thickness of design documents in traditional software development. The Agile mind specifically thinks what actually is required in terms of documentation.

Agile software development also gets translated into efficient communication, collocation and sitting in one room or same table and having conversations whenever there are issues. Some of the XP practices like pair-programming helps a new joinee to come upto the speed when she joins the project.

When you talk about effective communication and resolving issues in a team as and when they arrive, you lead towards a situation in which knowledge resides in the heads. People may not feel the need of documenting in detail as they seem to know everything about the project. You may end up in a situation where a new team doesn’t have “enough” documentation to begin with in maintenance phase. That’s why when one talks about “just enough documentation”, that “enough” word needs to be quantified.

Agile way of documentation!!!

ShriKant Vashishtha · May 5, 2008 · Leave a Comment

As you enter into Agile world, a statement welcomes you – “Just do enough documentation”. For quite sometime, I was puzzled what we really mean by this. In my view “just-enough” is very ambiguous or abstract. You cannot quantify it. For some who are working for a development project, creating documentation may not make much sense as you can find people just across your table to answer your question and you can get away by doing “not just-enough documentation” (no java-docs, no project overview etc). However when you come in maintenance cycle of the project, it just sucks. Maintenance may implicitly means new people, a long project cycle and people who leave the project or even organization itself.

What do you do then? People who were in the project at the beginning may not be there anymore, either from customer side or from software developers side. Without having a knowledge repository, new people will try to reinvent the wheel, will go through the code (white box, which ideally should be a black box most of the times) or will look like people who enter in a dark tunnel without having clue on what they are supposed to do.