Software Engineering Archive

From a normal user’s point, this time it’s not a revolution: in contrast to iOS 7, the new version 8 is – according to Apple – rather an evolution. For programmers, however, a lot has changed. Several new features have been added, whose impact will be visible only in the future in the form of newly developed APPs. iOS 8 is expected to be available in Autumn 2014.

SCR20146-Logos-Final-CSM_CS5_1160x403_01In the last years, XINFO has become bigger and bigger – as consequence, more employees were hired. With this, new problems showed up that we did not know before. We had more possibilities now, but the project coordination became difficult. Therefore, we introduced the SCRUM process for our software development. This process means to move away from the traditional way of planning that relies much on control and command. We want to show you what SCRUM means and whether we had success with it.

If you think about having programmed a new app, we can recommend an article that contains all necessary information.

You find the article here at our website.

To get more information about our company, visit the XINFO website. Alternatively, you can call Mr. Moritz Biersack (089/1891 788 37), or send him an email (moritz.biersack(at) – he will get back to you.

We took an intense look at the new Windows 8 for smartphones and are impressed. It is smooth, fast, reliable and has some unique features, e.g. the animated tiles. That is why we now offer applications for this operating system. Contact us if you are interested.

Besides, Windows 8 runs also on normal PCs without any problem. I have installed it onto my own private gaming computer at home on a new SSD, and it starts very fast. One drawback here may be the new tile surface that works well on smartphones, but is rejected by most PC users. But it takes only one click to reach the desktop, meaning that you can completely forget the tile surface if you don’t want to use it. So, you lose nothing, but you win the new features and the new driver versions. Okay, you don’t necessarily need an upgrade if you use Windows 7, and probably you will miss the start menu (which can be cured easily). But apart from this, there are really not many arguments against the new system.

sense4c-TRF01 is an adapter for smartphones and tablets that is equipped with a high-precision, digital temperature and humidity sensor. It enables fast and mobile detection of climate conditions in buildings, garment components or intermediate layers.

The sensor is plugged into the headphone jack and requires no external power supply. The collected data are presented graphically on the display and recorded in the background. The smartphone provides additional information such as position data (GPS) and ensures that the data are synchronized in the cloud. The data transmission is encrypted so that sensitive information is secured. Authorized users can access the data from any location and may even intervene actively using the return channel.


In the previous posts of this series various benefits and obstacles of agile software development for distributed (offshored) teams were shown and solutions for these problems were provided. On basis of the Eclipse development process an implementation of this variation of the original agile principles was provided and it could be seen that such an approach can be a success.

In the final post the original defined twelve principles will be evaluated and it will be determined if each of them is still applicable in such a distributed environment.

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

Evaluation of the Agile Principles within Distributed Teams

To further demonstrate the challenges and to show drawbacks of agile distributed software development the twelve agile principles[BBvB+01] will be evaluated in the following section and it will be determined if these are still applicable within distributed teams.

  1. Our highest priority is to satisfy the customer
    through early and continuous delivery
    of valuable software.[SW07, 11]

    This principle can be achieved because it might be even possible to allocate more resources (manpower) in a distributed environment than with only one site [Bat09] and classic agile models which are often limited to very small teams (e.g. crystal clear 1-6 members [Coc04, 150]). Furthermore, as previously stated, the level of excellence of each team member might be increased which also results in a higher level of quality of the software (resulting in a more valuable software).

  2. Welcome changing requirements, even late in
    development. Agile processes harness change for
    the customer’s competitive advantage.[SW07, 11]

    The reduction of costs in an off shored or outsourced environment might lead to an increased flexibility concerning changed requirements [Bat09] but additional communication is required (e.g. visits of coordinators from different teams) to ensure that the changes are understood in the right manner. This communication overhead resulting from the dispersed teams might lead to an increased delay when reacting to changes compared to a single site. Thus this principle is feasible but it with the limitation that the changes might not be processed as fast as within a classic agile software development environment.

  3. Deliver working software frequently, from a
    couple of weeks to a couple of months, with a
    preference to the shorter timescale.[SW07, 11]

    As described at the first principle more resources might be available because of the distributed teams. But as a result of the hampered direct communication between distributed teams the release cycles might be increased compared to a co-located team.

  4. Business people and developers must work
    together daily throughout the project.[SW07, 11]

    The communication between the developers of sites which are not located close to the origin of the client might be hindered or even be impossible. This can be caused by two factors. The first might be the geographic distances. If these distances are too big the clients representative might not be willing to travel – and rotate – all the way to the other sites. The second can be a result of the different time zones. If the expert from the client is not willing to travel to the different sites and wants to communicate via e.g. telephone it might be hard to find a convenient time for both sides where this communication should take place. [Fow06,Bat09] Because of these factors it is hard to apply this agile principle to distributed teams but as Mikko Korkala et al. showed in their paper it is possible within globally distributed teams to establish frequent customer communication. [KPC10] Furthermore, they pointed out the importance of this principle in an agile globally distributed context:

    […] when adopting an agile approach in the globally
    distributed context […] the company should assure that […] at
    least some representatives from the customer group is always
    involved in the agile meetings.
    [KPC10, 46]

  5. Build projects around motivated individuals.
    Give them the environment and support they need,
    and trust them to get the job done.[SW07, 11]

    As a result of the increased pool of potential employees the motivation of each team member might be increased in distributed teams. But on the other hand it might be hard to control the motivation on the different sites. [Bat09] Additionally, because of the geographically dispersed sites it might be harder to support the team members and provide the required environment which they need to be fully productive. But with some controlling overhead it is possible to apply this principle to distributed teams.

  6. The most efficient and effective method of
    conveying information to and within a development
    team is face-to-face conversation.[SW07, 11]

    It’s impossible to apply this principle to geographically distributed teams. The only solution is a trade-off by using direct communication tools such as instant messenger, telephone or a video conference. But even with this tools it might still be very hard or impossible to establish a direct communication with a different site because of the different time zones and indirect communication mechanisms must be used e.g. a Wiki. [Fow06,Bat09]

  7. Working software is the primary measure of progress.[SW07, 11]

    As previously shown with the example of Continuous Integration additional attention must be put on the test and build system so that this principle can be applied. But in general this is feasible. [Fow06,Bat09]

  8. Agile processes promote sustainable development.
    The sponsors, developers, and users should be able
    to maintain a constant pace indefinitely.[SW07, 11]

    Overall this can also be applied to distributed teams (e.g. 40 hour weeks). But due to communication with sites located in a different time zone additional exhaustion might occur which has to be taken into account by the team leaders. [Bat09]

  9. Continuous attention to technical excellence
    and good design enhances agility.[SW07, 11]

    Because of the increased level of excellence within the teams resulting from the larger pool of potential software developers this principle might even be more practicable than with a single team.

  10. Simplicity-the art of maximizing the amount
    of work not done-is essential.[SW07, 11]

    This principle is feasible [Bat09] but it requires more attention because the communication might not be as direct as it would be with only one team which could lead to duplicated work.

  11. The best architectures, requirements, and designs
    emerge from self-organizing teams.[SW07, 11]

    The lack of face-to-face communication, the different cultural backgrounds of the teams and different holidays within the countries can result in a hindered self organization of the teams. To ensure a proper self organization additional measures have to be taken such as regularly exchanging developers between the teams and continuous awareness by the team members of the different cultural aspects. [Fow06,Bat09]

  12. At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly.[SW07, 11]

    Besides the already mentioned communication complications the application of this principle can also be hindered by unawareness of the cultural differences. If this challenge is not faced with the proper commitment activities like the retrospective where the whole team contributes to a process improvement will be hard to be realized successful [SW07,Fow06]. So to make this principle feasible within distributed teams the members with a different cultural background have to be introduced into these new aspects of the agile approach and then be encouraged to apply them.


It should be clear by now that there are several agile principles which are not applicable or limited when developing in distributed teams. These missing or restricted principles lead to many different challenges – where the main challenge lies within communication hindrances resulting from the lack of face-to-face communication and the physical dispersed teams – which makes it hard to apply agile principles to distributed teams. But when additional practices are introduced into the agile software development process it is possible to extend the classic co-located agile development to distributed teams. These additional practices are no replacement for the original practices but when followed with commitment and discipline a sufficient trade-off can be achieved. Especially the establishment and maintenance of communication channels is one key aspect of success in a distributed agile development process.

When a company introduces agile software development methologies to distributed teams they will face risks associated with this approach as Ade Miller concludes from the experiences of his team:

the decision maker(s) must understand that in doing so [distributing the project] they reduce the project’s likelihood of success, increase the delivery time, and reduce the team’s performance and increase its dysfunction. [Mil08, 18]

But the company can also profit from various advantages like the possibility to step into new markets or to increase the level of excellence within their employees.

Whether or not to use the agile methologies for distributed teams must thus be carefully balanced out for every project.


[Bat09]: Dinesh Batra. Modified agile practices for outsourced software projects. Commun. ACM, 52:143-148, September 2009.
[BBvB+01]: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas. Manifesto for agile software development. Website, 2001. Retrieved 28. May 2011.
[Coc04]: Alistair Cockburn. Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley Professional, 2004.
[Fow06]: Martin Fowler. Using an agile software process with offshore development. Website, 2006. Retrieved 9. February 2011.
[KPC10]: Mikko Korkala, Minna Pikkarainen, and Kieran Conboy. A case study of customer communication in globally distributed software product development. In Proceedings of the 11th International Conference on Product Focused Software, PROFES ’10, pages 43-46, New York, NY, USA, 2010. ACM.
[Mil08]: Ade Miller. Distributed agile development at microsoft patterns and practices. Website, Article, 2008.
[SW07]: James Shore and Shane Warden. The Art of Agile Development. O’Reilly Media, 2007.

by Kevin Kratzer


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 ( 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.


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:


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.


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.


[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. Retrieved 18. May 2011.
[Ste04]: Christoph Steind, IBM Global Services Application Management Services. Distributed agile. Website, Presentation Slides, 2004. Retrieved 31. May 2011.

by Kevin Kratzer