For PONTON, agility is not a buzzword or a fad, but the answer to high complexity in software projects, innovation and addressing the concrete needs of our customers.

Complexity in software projects is primarily characterised by unclear or still unknown requirements at the beginning of the project, as well as by continuously changing framework conditions and priorities. The target image of the desired system can be roughly described at the feature level, but a small-scale, detailed and comprehensive specification of all requirements is deliberately avoided at first, as it is very likely that requirements that are not yet known will be identified in the further course of the project and that requirements and priorities will change. PONTON works in an agile way to

• deal constructively with complexity and innovation,
• achieve Time-To-Market (fast productive results),
• fit for the customer and
• maximise customer value.

We focus on early delivery of software increments, early customer feedback, regular review of processes and ways of working, and transparency of requirements through clear acceptance criteria and priorities.

In such a project, the following principles are essential for sustainable project success:

• Interdisciplinary and cross-functional teams whose members support each other across disciplinary boundaries,
• short iterations with fast feedback cycles to reduce risks from misunderstandings and misinterpretations, and
• regular, joint reflection on working methods  to continuously learn from disruptions and mistakes.

PONTON is used to working with different agile methods, Scrum (https://www.scrum.org), Large Scale Scrum (LeSS, https://less.works), Scaled Agile Framework (SAFe, https://www.scaledagileframework.com) and ScrumBan (https://www.agilealliance.org/scrumban/).

Agile software development according to the Scrum approach

By default, PONTON follows the Scrum approach with bi-weekly sprints. The cross-functional Scrum team should consist of a maximum of 9 people (including the product owner). All necessary competences and resources are combined in the team so that product increments can be defined, developed, tested and delivered in relatively short periods of time (cross-functional team). At the end of a sprint, a potentially deliverable/productive product increment should always be available. For effective teams to be able to do this, at least the roles of software developer (incl. know-how in the area of software architecture), quality assurance expert, Scrum Master and Product Owner must be filled. Optionally, the team is also supported by an Agile Coach. Scrum Master, Product Owner and Quality Assurance Expert are trained and certified at PONTON according to recognised standards.

A detailed description of the Scrum approach can be found in the official Scrum Guide: https://scrumguides.org/scrum-guide.html.

Scaling according to LeSS

LeSS is a process model for the lean scaling of Scrum. With LeSS, a scaling up from one Scrum team to several Scrum teams organised according to LeSS as well as a scaling down from LeSS with several Scrum teams to one Scrum team can be designed organically and easily.

With LeSS, central elements of the Scrum approach remain intact, such as:

– There is only one product owner and one product backlog.

– Teams are cross-functional

– All teams work synchronously in the same sprint rhythm

– Teams work on a common software increment

Based on the approaches adopted from Scrum, LeSS defines additional events and extends the scope of existing Scrum roles. In other words, LeSS is an extension of the roles, events and artefacts of Scrum. The following graphic gives an overview of LeSS:

For further information on LeSS see e.g. https://less.works/less/framework.

DevOps approach as an integral part of the agile approach

PONTON integrates the DevOps approach with the agile approach. In both Scrum and LeSS, the team(s) work on the same product. Fast feedback loops, frequent check-ins and automated tests foster developer collaboration. PONTON teams always implement the principles of Continuous Integration and Continuous Deployment (CI/CD). Finding integration conflicts quickly leads to smaller integration problems and faster solutions. The developers commit their code several times a day. In Scrum or LeSS, the team(s) must be fully integrated into a single code base by the end of the sprint. The more frequently the team/these teams integrate and build their application, the fewer the integration conflicts within or between teams and the faster they are resolved to create an overall robust, scalable delivery environment.

Automated testing is used for collaboration within a team as well as between teams. By describing the desired functionality in automated tests, ambiguities about how the application should work, for example, are eliminated. In this way, members of the team(s) can work more effectively on the same task without having to develop the application in different directions. Furthermore, by running automated tests on each build, a developer (or team) is warned if code changes inadvertently affect someone else’s work.

DevOps extends the idea of cross-functional teams to include the skills needed to deliver the software to a target environment or to put the software into production. Each team must be able to move a product increment into a target environment or into production at any point in time.