Few Characteristics of Agile program in Software Development

The traditional thinking on the onshore/offshore boundaries is based on the activity that people do. So analysis and design is done onshore, construction done offshore, and acceptance testing is done onshore. When we do split an effort with onshore and offshore development teams, we do this along functionality grounds rather than activities. We break the system into broad modules and let the offshore team tackle some of these modules. We've found that contrary to this, matters improve when we make the offshore team handle as many activities as possible. So we prefer to see them do as much analysis and design as possible, subject to the limitations that the requirements are coming from onshore. However unlike most groups that do this, we don't make a big effort to design and freeze the interfaces between these modules: continuous integration and weak code ownership allow the module interfaces to evolve as development goes on.

The more someone local to the developers understands of the business, the more the development team can develop efficiently. An important part of this is to grow the analyst part of the offshore team. Instead of having to wait overnight to answer a question, developers can get answers right away - which remove blocks to progress. All this means that you have to focus on growing the business knowledge of the offshore analyst. This takes time, but the local knowledge is a vital counterpart to the business knowledge onshore.

One thing is reminded in this situation is the dominant power of Conway's Law - the structure of the system will mirror the structure of the team that built it. That means that it's important to separate distributed teams by modules that are as loosely couples as possible. So it inevitable in Of shore development.

Different communication tools

Some companies block instant messaging these days thinking it to be a distraction. It particularly hurts offshore projects as it removes informal one-to-on contacts. Different communication tools work for different kinds of problems. At the minimum make sure you have a wiki, instant messaging, and good telephone connections.

We see a surge of communication during overlap hours, which is particularly valuable when those overlap hours are short. Instant messaging is good for quick questions and answers, but a particular strength of IM is that it tells you when people are available at their desks. You do have to get into the habit keeping your IM status fresh, but that information is always useful. If it's more than a quick few messages then it's best to switch to phones. Make sure that it's easy to just pick up a phone. People shouldn't be deterred by fears of the cost of phone calls; a phone call will usually save money on misunderstanding.

These are often easier to prepare than a document, easier to sit through (if they're not too long) and crucially they also help the personal contact, since it's easier to get a broader picture of someone from a video than from a document. They aren't so good for details, but work better for a broad picture. We've found a lot of value in video presentations. Short lectures about the background of the project that can be recorded and sent over to the remote team.

Getting multi-cast rather than one-to-one communication can also be done with real time tools. Email can often be a mixed blessing. In particular we've found that it's good to discourage person-to-person email in favor of broadcast newsgroups or mailing lists. It's too easy for a piece of information not to go to someone who needs it, or be unable to find it. By posting messages and requests in a newsgroup, everyone can see the messages and it's easy to search. People find it easy to skip over threads that they aren't interested in.

The ideal matter to sort out is how to communicate the big picture - the vision of the project. Most communication, and discussion about communication, concentrates on the day-to-day details. It's important to get this right, but there's a danger that in focusing on the day-to-day nobody pays attention to the overall vision.

Often remote communication focuses too much on tactical details - what need to be built this week. But many technical decisions need a broader strategic context - so it's important for the remote team to have a broader picture of the direction the project, and the business, wants to take. This issue is particularly important for communicating the business context of a project. This method of communication is often lacking in on-site projects, particularly when there is a lot of organizational barriers between business and technology.

The necessity of documents

Documentation, however, becomes more important with offshore development since the face to face communication is reduced. This work is a waste since it wouldn't be needed if the whole team was co-located. But given the offshore model, you need to do them - so they are part of the price of doing things offshore. Agile methods downplay documentation from the observation that a large part of documentation effort is wasted. That's a price in the time for people to write them, the added time because it's harder for people to understand many things from a document, and also a price in frustration when people are using them.

We need more active collaboration tools like wikis, issue tracking tools and the like along with documents. On the whole it seems that it's often better to favor tools that impose less structure, that way the team can fit them better into how they want to work. It is better to check their documents into a version control system so people can easily get the most up to date material. This is particularly important when you are doing remote work. Expect to evolve the structure of documents as you learn what works best for your team. Make sure there's plenty of communication about the form of the documents and how well they are working.

Bug Fixing

Bug fixes allowed the Indian team to become familiar with the code base, before they did substantial work on it, since bug fixes involve more code reading than changing. Although this worked well, there is some concern that more experienced people may consider it to be a stigma to be doing only bug fixes. While some people may perceive this as a problem I believe that working on bug fixes or much localized feature changes is one of the best ways to get familiar with a large new code base.

Onshore teams can spend their day mapping out details of bugs, which can be communicated to the offshore team and worked on during the onshore night. The nature of communication of bug fixing can also make it an easier activity to work with offshore. The onshore team can then review the fixes the next day. This is not more efficient than having an on-site team fixes the bugs, due to the communication difficulty, but it can be a less complicated way of working with an offshore team.

Conclusion

And so we can conclude that agile program aids a lot for the development of software in offshore units.