ROI of Agile Development

Scott Sehlhorst at Tyner Blain has added an excellent article on ROI in Agile. Take a read!

Agile 101: What is Continuous Integration?

What is Continuous Integration (CI)?

Continuous Integration (CI) is the practice of periodically executing Automated Build Scripts (ABS), preferably in short intervals. There are two flavors of this practice. The first flavor, mostly applied by early XP practitioners states that the system is built by one developer at any given time. The teams have adopted various physical tokens signifying the builders’ "right of build". In this flavor of CI Automated Build Scripts are still required, albeit the kicking off the build happens manually. Since this version relies heavily on the entire team to be colocated, it does not scale well in distributed Agile projects.

The second flavor of CI relies on a computer background process to poll the code repository in short intervals and automatically trigger the build process if it detects any changes since the last build. In this version of CI, the developer is only responsible to build locally and check-in the code. This model is better suited for highly scalable Agile teams because of its reliance on automated asynchronous processes to trigger the build. This gives distributed teams an early feedback on the status of the system and therefore it enables dislocated team members and managers to have the same quick feedback as the team itself.

Distributed Agile Development

Team Structures in Onshore-Offshore Distributed Agile Development Teams (OODT)

One of the biggest challenges of offshore development is finding a reliable partner. Unless the US company owns the operations overseas and regardless of the engagement model, special care should be taken to start with a competent and trustworthy partner. If the offshore partner or its employees have prior US work history and some Agile development experience, this will increase the chances of success for the OODT Agile initiative.
Flexibility is another important attribute and despite flashy marketing materials, not all of the offshore companies have developed habits of business savvy and flexibility.
Try to identify an offshore partner willing to work flexible hours to accommodate for the time zone differences. Activities such as testing and deployment can be seen as separate and therefore can be run on a separate schedule, but that does not scale well within the Agile team, especially if it practices the Whole Team. Therefore, effort should be taken to make the whole offshore team available to the onshore team for a portion of the day.

Now, let’s take a look at some possible variations of the offshoring model. There are probably as many models as thinking heads, however it is possible to classify them as partial and complete offshoring. Before looking into the details of each model, let’s take the composition of the typical colocated Agile team as a baseline and compare it to three possible models for offshoring.

Baseline: Colocated Onshore Agile Team

Let’s start with a typical colocated team where all team members are located in a US-based facility. The diagram below is presented as a baseline for comparison with the three possible offshoring models.

Model 1: Partial Offshoring

This is the first model of offshoring where parts of the functional team are shipped overseas. In this model the design team is located onshore and it sends the requirements overseas. The offshore team responds with back fully-tested and working code.The onshore team then performs the user acceptance tests and validates the requirements and the defects.

Model 2: Complete Offshoring

The second model tries to provide as much colocation as possible by shipping the entire production team overseas. The only person left onshore is the customer. The customer sends features and the offshore team responds with fully tested working code. This scenario is arguably the most cost-effective among all.

Model 3: Mirrored Offshore Team

The third and most effective model for companies transitioning to Agile is the mirrored-design model. This model can be less cost-effective in the beginning, than Model 2, however it the initial investment pays itself out with less defects and shorter development cycles. In addition, the mirrored teams lay the groundwork for a smooth transition by gradually shifting responsibilities to the offshore team.

Agile 101: Automated Build Scripts (ABS) defined

What is ABS?

Automated Build Scripts (ABS) provide an ability to build software in an unattended and machine-independent environment. ABS are generally written and maintained by a special group of developers called configuration managers, or software integrators or just application builders. Some of the tools used to write ABS are Ant, NAnt, Maven, MSBuild, Visual Build Pro, and make.

Automated builds are one of the most important practices for any Agile team. They help developers see the effects of any change immediately and make it possible to deliver working software at the end of each iteration. The need for ABS is even more pronounced in distributed Agile teams because multiple people build simultaneously and in the absence of a common team room it is paramount that every change is properly integrated into the build. This is a fundamental attribute of a well designed automated build system since it helps keep the repository coherent and the code base buildable.

Other important features of good ABS are:

• Allow a system to be built on any machine while requiring minimal (properties) or no changes to the base scripts - in most Agile teams it is more than likely that teams will have different machine settings such as OS, language, IDE. The ABS should be machine- and environment-independent.
• ABS should be easy to plug-in to a Continuous Integration (CI) sever - this is especially important for distributed and offshore Agile teams as the time zone differences make it necessary to build continuously and notify the teams of any problems early. ABS written in Ant or Maven for instance, allow for automated and unattended execution, making them a perfect choice for CI.
• Ability to execute ABS with a simple shell command - both the architect and the developers should be able to trigger a full build with a simple shell command. The best ABS are designed to be simple and guiding the user through the steps so that even relatively non-technical team members such as business analysts and project managers are able to stand-up a system with minimal help from the rest of the team.
• Ability to define and manage project dependencies. These are both compile-time dependencies such as libraries as well-as deploy-time dependencies such database scripts and XML configuration files. In highly collaborative Agile projects the DB servers and XML configurations are likely to change often, so a good ABS should take care of the dependencies in a transparent manner.