Scaling Agile Methods

Using agile methods to develop large systems presents a thorny set of issues. If large teams are to produce lots of software functionality quickly, the agile methods involved must scale to meet the task. After all, a small team could create the software if the functionality to be delivered was small and, conversely, could be delivered given we had the time. Scaling agile teams thus becomes an issue if the only option for meeting a system delivery deadline is to have many developers working concurrently.L'utilisation de m\ue9thodes souples pour le d\ue9veloppement de gros syst\ue8mes soul\ue8ve des questions \ue9pineuses. Lorsque de grandes \ue9quipes sont appel\ue9es \ue0 produire un grand nombre de fonctions logicielles rapidement, les m\ue9thodes souples qu'on utilise pour faire le travail doivent \ueatre mises \ue0 l'\ue9chelle. Apr\ue8s tout, une petite \ue9quipe serait en mesure de cr\ue9er le logiciel si la fonction \ue0 livrer \ue9tait petite, et le logiciel pourrait \ueatre pr\ueat dans les d\ue9lais prescrits si on nous accordait une p\ue9riode suffisamment longue. La mise \ue0 l'\ue9chelle des \ue9quipes \ue0 m\ue9thode souple prend de l'importance lorsque la seule fa\ue7on de respecter les d\ue9lais de livraison d'un syst\ue8me consiste \ue0 y faire travailler un grand nombre de d\ue9veloppeurs en m\ueame temps.NRC publication: Ye

What Is Large in Large-Scale? A Taxonomy of Scale for Agile Software Development

Positive experience of agile development methods in smaller projects has created interest in the applicability of such methods in larger scale projects. However, there is a lack of conceptual clarity regarding what large-scale agile software development is. This inhibits effective collaboration and progress in the research area. In this paper, we suggest a taxonomy of scale for agile software development projects that has the potential to clarify what topics researchers are studying and ease discussion of research priorities.acceptedVersio

Harmonizing software development processes with software development settings – a systematic approach

The software process landscape is rich in complexity and many alternative software development approaches have emerged over the past 40 years. However, no single software development approach is universally implemented and it seems likely that no single approach can be universally useful. One of the primary reasons that no single approach is universally useful is that no two software development settings are identical. We have assembled a team of recognized academics, who together with industrial collaborators, plan to map the complex world of software processes with the context of software development projects. The results of our initial mapping efforts, reported in this paper, demonstrate that although there are challenges in an undertaking such as this, the outcomes are potentially of considerable value to both software researchers and practitioners

IT Innovation Squeeze: Propositions and a Methodology for Deciding to Continue or Decommission Legacy Systems

Part 6: Theory and MethodsInternational audienceOrganizations have been confronted with fast moving developments in the Information Technology (IT) sector over the past decades. Many new technological paradigms have emerged and left a landscape of legacy in which more and more money is spent on maintaining this landscape at the expense of innovating. Especially where business requirements put time pressure on the evolution of the IT landscape the decision whether to continue and maintain legacy systems or to decommission legacy systems in time has become a huge challenge. We formulate a set of propositions influencing the decision to decommission or continue legacy systems. This set of propositions is derived from literature and interviews with high level managers of organizations. Software characteristics, development methods, dependency of systems, lock-in, system complexity, new technologies and system ownership influence the decision whether to decommission or to maintain a system. We conclude this paper by proposing a methodology that helps organizations in finding the right balance between discontinuing and maintaining legacy systems