Monthly Archive:: September 2011

Probably you have come to this blog because you are interested in iOS/Android-programming or in the applications made by XINFO. As you may know, the company XINFO is both focused on applications for iOS/Android and also more traditional software for the industry that is applied directly in the production process. It is definitely worthwhile to have a look at these kind of programs XINFO is doing, because there are really some ingenious gems that deal with the huge amounts of data piled up in machine building processes.

One of these programs is the iProzer. iProzer means: intelligent process analyzer. It is a tool developed for the automotive industry that creates evaluations of quality and measurement data collected during the production process.

Introduction

The previous post showed some additional practices for agile software development with distributed teams. This post will give you an example of a project which is successfully developed for a long time using globally distributed teams and open source contributors.
Furthermore, the main agile practices will be highlighted and the additional practices which are followed for the distributed environment will be pointed out.

You might also be interested in the other posts of this series:
Part 1: Motivation and Challenges
Part 2: Best Practices
Part 3: Case-Study on Eclipse
Part 4: Evaluation and Summary

Case Study: Eclipse [Ste04,Gam05a,Gam05b]

Eclipse LogoAn example for agile software development which is applied to distributed teams is provided by the Eclipse Foundation. This foundation is an open source community which is using agile methologies within geographically dispersed teams to develop Eclipse (http://www.eclipse.org/)which is not only an integrated development environment including a java development environment but also a general tools and integration platform which can even be used as a general application platform to develop diverse applications. The contributers to the software are not only the open source developers but also six globally dispersed teams which are located in: Canada (Ottawa, Toronto), United States (Portland, Raleigh), France (St. Nazaire) and Switzerland (Zürich).

Practices Used

The Eclipse Foundation is using various practices within the development of Eclipse:


The orange boxes highlight the involvement of distributed contributors within the development process of eclipse.

In the following sections the core practices used will be further discussed.

Key Practices Used for Agile Software Development

Continuous Testing

Testing is already taken into account early within the development cycle and these tests are then performed frequently and automated to ensure working software. The tests do not cover only functionality but also the performance.

Continuous integration

Eclipse is using an automated build and testing environment to ensure a working software. The builds are performed on a nightly, weekly and milestone basis whereas successful milestone builds are released to the community.

Incremental Design

With changing requirements the design is adjusted to the needs but these changes are limited to ensure that the public API is downwards compatible. A stable API is important for Eclipse because it focuses on extensibility using the plug-in design pattern [Fow02].

Short Development Cycles

Within the release cycle which takes 6-15 months each iteration is limited to six weeks.

Retrospectives

After each release a so called decompression phase is performed which is time boxed to one month. Within this phase the lessons learned from the last cycle including achievements and failures are evaluated and the processes are refined accordingly. Furthermore, this phase is used to recover from the release to ensure that the developers can keep up a constant pace. In the end the next release and cycle are getting planned.

Key Practices Used for Distributed Agile Software Development

To apply the agile practices to the distributed and open source environment Eclipse is following various practices. There are three core practices which are explained in this section:

Milestones

Each Milestone represents a miniature development cycle including planning, execution, testing and a retrospective. To make it easier for the distributed teams and the open source community to follow the milestone and to see the progress of the software the milestone plans are published to publicity beforehand and after the milestone is reached the results which where achieved are getting advertised.

Community Involvement (Customer Involvement)

As Eclipse is an open source project the customer of the product is the community. So it is an important part of the distributed agile development that all aspects of the development is performed in a transparent way. As a result the community can actively participate in the development and provide feedback which is taken into account by the developers to adjust the software.

Component Architecture

The whole software is splitted up into different components. These components are then assigned to specific sites (e.g. SWT is developed in Ottawa and the team in Portland is developing the debugger). By this approach the development of single components can be performed in an classic agile manner within one team and the communication need with other teams is reduced. If there are cross component problems occurring these are handled by dynamic created teams which will handle this specific problem. The members of this team are key developers of the affected components which ensures that the knowledge base of the newly created team is sufficient to understand and solve the problem.

Summary

Eclipse is following various agile principles and is applying these not only to globally distributed teams but also on an open source environment and as Erich Gamma states apparently with good success:

Throughout the history of Eclipse the development team was successful in hitting
projected delivery dates with precision and quality. [Gam05a, 4]

As a result the software development process of the Eclipse project can be counted as a successful application of the agile software development methologies in an distributed context because quality software releases can be delivered on time since the beginning in 2001.

The final post will try first to evaluate the twelve original agile principles if these are still applicable in an distributed environment and then give a small summary on the content provided in this series of blog posts on agile distributed software development.

References

[Fow02]: Martin Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley Professional, 2002.
[Gam05a]: Erich Gamma. Agile, open source, distributed, and on-time: inside the eclipse development process. In Proceedings of the 27th international conference on Software engineering, ICSE ’05, pages 4-4, New York, NY, USA, 2005. ACM.
[Gam05b]: Erich Gamma. Agile, open source, distributed, and on-time: inside the eclipse development process. Website, Presentation Slides, 2005. http://www.icse-conferences.org/2005/ConferenceProgram/InvitedTalks/GammaKeynote.pdf. Retrieved 18. May 2011.
[Ste04]: Christoph Steind, IBM Global Services Application Management Services. Distributed agile. Website, Presentation Slides, 2004. http://cf.agilealliance.org/articles/system/article/file/1420/file.pdf. Retrieved 31. May 2011.

by Kevin Kratzer