The term ‘Agile Methods’ has been around for more than a decade, while the underpinning concepts and most of the practices associated with agile software development have been around for much longer. In fact, there is still no complete agreement on what agile software development is, but certainly agile methods aim to answer a need to develop software quickly, in an environment of rapidly changing requirements. The use of iterative development is common to all agile methods and usually there are frequent releases to customers. Close (preferably onsite) collaboration with customers is encouraged and requirements change is an accepted, even welcome, part of the process. Other typical differences with non-agile approaches are the emphasis on small self-organizing teams, the idea of continuous design improvement, test-driven development and continuous integration. Further, knowledge management in agile development tends to be tacit as opposed to being based on comprehensive documentation, face-to-face communication being considered the preferable communication means.
Agile methods are evolving all the time and organizations are recognizing that there are still outstanding issues as well as opportunities to improve how software is built in an agile environment. It was contributions on these issues and new opportunities that were sought for this focus section. For example, safety critical software still needs a rigorous approach, whether or not agile practices are used. Our first paper, ‘Agile Methods for Safety-Critical Open Source Software’ 1, describes experiences in the application of Agile Methods to an open-source software project, delivering a safety critical software product. The authors admit that agile methods are generally assumed not to be appropriate for safety critical software, but using their experiences in development of the Image Guided Surgical Toolkit (IGSTK) go on to offer evidence that disputes this assumption. By first deriving a set of best practices, many of which are specifically related to safety critical needs, the development team under discussion were able to use and augment agile methods for the safety critical needs of the IGSTK. For example, the paper describes additional practices used to manage and trace requirements, the practice of ‘safety-by-design,’ the use of continuous integration and testing facilitated by tool support, and the use of reverse engineering of models and subsequent model checking to validate the software architecture. Overall, the authors claim from their experiences that agile methods, augmented with ‘the right amount of ceremony,’ can indeed be used for developing safety critical software.
Agile methods emphasize working software. Nonetheless, users still expect a high level of usability in software. It is also often the case that user experience design is a separate activity from the development of the software functionality and often conducted by a separate individual or team. Our second paper, ‘User Experience Design and Agile Development: Managing Cooperation through Articulation Work’ 2 considers this situation using an observational study of a mature Scrum team in a large organization. The paper describes observations of two separate teams, one for software development and another for user experience(UX) design. The researchers used their results to arrive at a picture of the interactions between the two groups. The practices used in integrating the work of the two teams are not explained by considering the Scrum processes or the UX design processes and so the authors conclude that they are due to the ‘situated nature’ of the two teams. By this, they mean that what influences and forms the interactions is largely driven by their separate divisional-level commitments. The paper also describes the two teams as working cooperatively rather than collaboratively and that this cooperation is implemented via articulation work, meaning that the developers had additional tasks to ensure that the UX design was completed. Overall, the paper provides an insight into a culture where developers and UX designers work together, adds evidence to support the agile principle of self-organizing teams and recommends the recognition of interaction tasks as valuable work in agile software development.
It is widely recognized that lean manufacturing principles have been highly influential in the evolution of agile software development. Our third paper, ‘Measuring the Flow in Lean Software Development’ 3 considers a case study where Lean Software Development was used. The paper describes the use of cumulative flow diagrams to model flow and detect bottlenecks in the software engineering process. The industrial case study used by the authors allowed them to determine how continuous the requirements flow was in the development process. This was deemed useful for visualizing progress, identifying handover points between phases and to get a picture of inventory levels. The authors show how the flow diagrams and derived measures can be used to increase throughput and reduce lead times for customers as well as to provide a visual means of tracking progress and the status of requirements. The paper goes on to report a positive industrial evaluation in terms of decision support and process improvement.
Thanks are due to the editors of Software Practice and Experience for hosting this focus section and additionally to all who so thoroughly reviewed the submitted papers.