Methodology in myleo / dsc - Extreme Programming and how we live it

When it comes to agile software development, most people immediately think of Scrum as an established process model. Equally important for myleo / dsc, but far less well-known, is so-called Extreme Programming (XP). While Scrum offers very concrete methods and tools, XP, as a problem-oriented and flexible process model, largely dispenses with rigid specifications and relies more on general principles. Therefore, XP and Scrum as agile process models can be combined very well in practice - as is the case at leogistics. The lowest common denominator of all agile process models is the "Agile Manifesto", which was signed by the inventors of all established agile methods:

• Individuals and interactions have priority over processes and tools
• Runnable software takes precedence over extensive documentation
• Collaboration with customers takes precedence over contract negotiations
• Accommodating change takes precedence over strict plan tracking

XP was founded by Kent Beck, Ward Cunningham and Ron Jeffries, who were also the first signatories of the "Agile Manifesto". The experiences from the XP method later became part oft the foundation of agile software development.

What exactly does XP mean and how does it help us in our daily development at myleo / dsc?

"Customers are part of the team"

Recognizing customers as a part of the team is an important tenet of XP. Therefore, for myleo / dsc, both our consultancy and UI/UX team are in daily exchange with our clients. This allows us maximum flexibility to identify new solution requirements at any time and incorporate them into the development, revise existing solutions or even discard obsolete requirements.

Smaller development teams are established within the whole myleo / dsc team. These consist of fixed, non-changing members from the areas of UI/UX design, development and testing according to the Scrum principles and are in very close contact with the consultancy. Our development teams work according to Scrum here, so that at leogistics we use several agile methods at the same time.

To ensure that the overall solution can emerge as if from a single mould, despite the individual development teams, another important XP principle comes into play:

"Collective Ownership".

At leogistics, we consider our self-imposed coding standards in the form of uniform custom controls and holistic development and design guidelines in our daily work. In order to avoid insular knowledge, the architects of the respective development teams in both the frontend and the backend are in a continuous overarching exchange and carry all current key information to their respective teams. In addition, knowledge is widely disseminated in the regular community calls.

“Pair programming" has also become firmly established in the mindset of the myleo / dsc development teams as a method for more complex features and MVPs to avoid insular knowledge. It is important to mention that pair programming is also used across the development teams, so we loosen up the Scrum principle of non-changing members a bit in this respect. Although all members always remain part of their respective teams, they are allowed to meet in cooperation with members from other teams for more complex tasks and develop solutions together. The formation of insular knowledge, especially with new and complex features, is thus counteracted at a very early stage in at myleo / dsc.

Pairing is also an effective method for further establishing the agile mindset in the team. Agile working must be consolidated and further developed again and again. To ensure this, every team member must know what agile working means. Through pairing, the teams in myleo / dsc can support and challenge each other to raise collaboration to a new qualitative level.

Despite all these measures, however, our software is of course never fully optimized and free of bugs, which brings us to another XP principle:

"Refactoring is part of development"

In XP, potential sources of errors and unfavorable coding are refactored during development. The so-called refactoring is part of the daily work of the development teams and is considered necessary in our mindset. It is important here that we always proceed entirely according to the pathfinder principle and that a solution-oriented approach is always in the focus. We also live an open error culture both internally and in communication with our customers.

Of course, quality assurance tests also have a very high priority at myleo / dsc, which brings us to another XP principle:

"Test phases and test depth are part of the agile cycles."

Our development teams generally include members of the testing team, which means that both the writing of automated tests and the depth of testing are integrated into our agile processes. This allows us the highest flexibility in the development of integration tests to also ensure the reliability of newly created features and to detect errors at an early stage. We additionally secure our own developments in the form of custom controls in the UI and services in the backend with unit tests. Writing unit tests is a firmly established part of the development process.

Finally, another important XP principle deals with the complexity and regularity of releases:

"Releases are a management decision, not a developer decision".

We currently publish our myleo / dsc releases every 14 days, although we still see potential for optimization here and are aiming for feature-driven batch releases in the future. However, the principle already applies that our development teams only develop and provide the solutions. When these are released is not a decision of the respective development teams but lies only in the management's decision to update the whole solution at the currently specified interval.

In conclusion, it can be said that the path for myleo / dsc towards an agile development method with the help of Scrum and XP was sometimes rocky. But the constant desire to improve and the incredible team spirit from the management right down to the development teams brought us to where we are today with the help of Scrum and XP:

“How consistently leogistics lives agile software development is very rare to observe on the market.”

We hear this and similar statements again and again from new colleagues from internal and external development. It is particularly noteworthy here that most of the development teams at myleo / dsc work almost exclusively remotely. Particularly in agile software development, this creates special challenges and, according to popular opinion, it is still considered disadvantageous or even impossible to reconcile work from the home office and agile software development. Even the "Agile Manifesto" states: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. With myleo / dsc, leogistics proves time and again that effective agile working is also possible remotely.

Despite the very successful use of agile methods, we at myleo / dsc continue to strive to professionalize our processes on an ongoing base. Especially in the context of complex software with several teams, project management is a great challenge. A general overview of the teams and processes involved can be obtained by looking at the Scaled Agile Framework (SAFe), for example. There, Scrum and XP are firmly linked together for larger projects to form a solution that is called ScrumXP in SAFe. Scrum provides the guidelines for the team and XP the technical method.

Finally, it remains to be mentioned that XP encompasses many more principles, but here we have focused on the core aspects that are currently relevant for leogistics. However, it is also true that we are in an ongoing transformation regarding to the methods and principles of XP used, which will ultimately remain one of the most important keys to successful agile working at myleo / dsc in the future.