Agile in the software development practice

In the mid-1990s, Agile emerged as an alternative to the traditional, plan-driven approach to software development. Agile is meant to better meet customer requirements. When requirements are specified and established in detail at an early stage, in practice, the requirements appear to change over time as both the customer and the developer become aware of new opportunities, needs and/or constraints.

The Agile practice involves lightweight and incremental processes that fully and continuously involve the customer and are adaptable to changing circumstances. In 2001, a group of software engineers formulated the agile manifesto, which lays down deep principles of agile development. Multiple elaborations and specializations of the agile practice exist. Two popular elaborations that capture agile development are Scrum and Extreme Programming (XP).

Scrum is an empirical process model that defines roles and activities in an organizational framework. A Scrum team is largely autonomous and works in iterative steps (sprints) of two to four weeks. XP focuses on close customer-developer relationships and communication in short iterations. Instead of an organizational framework, XP describes practical development activities in some detail, such as pair programming, continuous code review, testing and refactoring.

These two elaborations are extremely good complements to each other. We will further highlight some aspects that would not look out of place on a Definition of Done from a software development team.

Test first

Test First is about getting early feedback on code quality. This principle has a huge positive effect on the quality of the software architecture. It helps to develop software from working to working and to show a qualitatively working result in the sprint review every sprint.

Continuous integration

Continuous integration avoids or detects problems at an early stage. Integration is a "pay now or pay more later" activity. That is, if there is continuous integration in small quantities, there will be no weeks at the end of the journey to integrate the entirety of features, while the sprint deadline has passed in the meantime.

Build in ten minutes

XP requires that code be integrated continuously and that the build should be less than ten minutes. When the build time exceeds ten minutes, developers must ensure that the build time is shortened. Otherwise, developers will be more reluctant to continuously integrate their code. When developers do not continuously integrate their code, they lose feedback and it is more difficult to continue to deliver high-quality software within a sprint.

Refactor for incremental design

Developers often continue to use code that is no longer maintainable because it works. Unfortunately, developers are cautious about modifying this type of code because the consequences are incalculable. By continuing to refactor the code, the code remains maintainable. Unnecessary complexity is avoided, which reduces the costs of correcting errors. After all, errors are noticed more often and/or are easier to solve. There is more time left for building new features, which improves the velocity of the team.

Automated Testing

Applying unit testing has many advantages. For example, it promotes the application of refactoring or continuous integration. The quality of the code is continuously assured, because the unit tests are performed during construction and provides direct feedback to the developer on the quality of the code change.

Roll out daily

Ideally, a situation will arise in which the software adjustments can be rolled out in production on a daily basis. If the code is subject to high-quality and comprehensive automatic testing and manual steps are no longer required to test the code, the code can be rolled out daily in production. This is especially true for web applications, for example. With mission-critical software running on specific hardware, it's not always possible to achieve this, but it's a good goal.

Pair programming

Pair programming increases the number of direct hours to deliver code relative to an individual programmer. On the other hand, the code is of much better quality and contains fewer errors.

Applying pair programming is very suitable for more complex parts of the software. Some parts require different insights and developers from different backgrounds. It also helps to share knowledge within the team, so that there is no individual ownership of parts of the code, but ownership remains with the team.

Informative workspace

Scrum values transparency. It is a pillar of Scrum. The Scrum guide describes having a sprint goal and backlog, but does not prescribe how the information should be shared transparently.

XP requires a team to have an informational workspace so that everyone in the room can see the progress of development. XP teams show the work for the next three months and the next week. It is good practice for Scrum teams to display their work on a physical board in a central place in the workspace.

In conclusion

Agile in Focus is developing an Agile software craftsmanship training. We hope to offer this training in 2022 to software developers who want to design, implement and/or test based on Agile practice.

At Agile in Focus we are committed to help your software development organization to be competitive in a rapidly changing market. We can advise you on these matters.