Recipe for successful software development

Good solutions can only be developed in a good team

I am convinced that good solutions can only be created in a well-functioning team. Other factors also influence the quality of the solution. But when a team works well, it has the power to shape its environment and find the best solution for the given situation.

For me, the following values have become central in software development:

• cross-functionality

• self-organisation

• iteration

• increment

• integration

I was allowed to get to know most of these values via the Scrum framework. In my experience these values can improve the software development in the whole noticeably, for example by higher quality or by better target achievement.

In the next sections I would like to illustrate these values and principles in more detail.

Cross-functional, interdisciplinary, cross-disciplinary – holistic

A key to agile projects is understanding and applying cross-functionality. At the beginning of the project, we define a team that has the necessary knowledge to implement the requirements of the software system to be built. I would like to underline this at the beginning of the project. Because all too often the disciplines and thus the project members are distributed over the project duration. This creates an artificial waterfall model and separates the project members from each other.

As an example, I can mention the conception phase of a project. Usually only people from the fields of business, conception and design are involved. With a project manager, on the other hand, who has an understanding of cross-functionality, frontend and backend developers already accompany this conception phase.

Involving developers from the start

I radically recommend starting with a cross-functional team. Even if you have the feeling that the backend developers can't contribute anything yet. If we strive for the principle Deliver working software frequently...Working software is the primary measure of progress (Agile Manifesto, Principles), then backend developers have a lot to do right from the start:

• Setup Continuous Delivery and Deployment

• Clarifications with IT

• Core domain peel out, implement and more

Of course, it makes no sense to start with a cross-functional team if the „why“ and the „what“ are not yet sufficiently defined. The product backlog should be filled with the first, most important product backlog entries.

Domain-driven Design

The principles of domain-driven design (DDD) also apply here. In DDD, the experts work closely with the developers. Together they define a language that describes their domain and is reflected in the software. This is nothing new, but is always a challenge when it comes to implementation. The technical expert can, for example, write, prepare and carry out tests. And best of all, continuously: requirement for requirement, sprint for sprint.

Learning from each other

Another factor that comes into play is mutual learning from each other. This learning process is often forgotten. It only works if the cross-functional team can work together and learn from each other right from the start. This is a prerequisite if you want to have a high performing team.

Principle to remember:

Start with a cross-functional team.

Self-organized, autonomous, independent – mutually complementary

Another key in agile projects is the ability of the team to organize itself. By this I mean how stable/resilient and independent a team is.

A central question: Does the team continue to function even if the release manager, the architect or the Scrum Master are missing? Has the team distributed the project knowledge widely and communicated it well?

Or even more important: Can the team solve interpersonal problems independently by presenting the difficult points honestly and openly? Is there a culture of mutual respect and genuine appreciation (keyword: Psychological Safety)? How well do the team members complement each other? How high is the willingness of each member to acquire further knowledge so that the team as a whole can become more resilient (T-Shaped Professionals)?

The role of the Scrum Masters – empower, not command

The Scrum Master is particularly in demand for the development of this self-organization capability. He is the master for the establishment of a self-organized team. Not by giving orders, but by empowering each individual to contribute to the team. Depending on the maturity of the team, the Scrum Master must more or less accompany it in this topic.

The terms enabling and accompanying are to be emphasized. The Scrum Master has no power over the team. He cannot command. The goal is not to do things the way he thinks they should be done. The team should find this out for itself and improve itself in its self-organisation. The Scrum Master tickles the self-organization out of every single team member. He challenges the team with specific questions.

The retrospective meetings – improving bit by bit

How does the team learn to become more self-organized? For example, by regularly looking back, inspecting, pausing and defining joint actions to improve cooperation. We call these joint retrospective meetings retrospective meetings. They strongly promote the idea of Continuous Improvement.

Retrospective meetings are often criticized: they are useless and you can discuss things directly in the team and make improvements. I agree with that. This is the ideal situation, or rather the goal, that a team achieves such a maturity and moves in the direction of a high performing team. But experience shows that this is not always the case. These regular retrospective meetings can help a team to improve. Step by step, sprint by sprint.

The Scrum values play a central role for the success of retrospective meetings. If the team members are not willing to internalize and live values such as courage, respect or openness, then retrospective meetings do not bring much. So Scrum in its entirety is never really brought to life.

Principle to remember:

Encourage value-based self-organisation in the team.

Iterative, Incremental – Feedback-driven

For me, the term iterative is based on a deeper understanding of the future. It means: I admit to myself that we don't know everything at the moment. For me, it has to do with humility, accepting that I cannot foresee everything. If we proceed iteratively, we show the courage to implement a first working solution with the aim of actively seeking feedback from the end user. In short iterations we want to provide the end users with a first working software that they can touch. This way we can strengthen the trust in the development team.

Delivering a working software early on

Let me emphasize again: functioning software. Sometimes there is the misunderstanding that you can deliver half-finished software with Scrum & Co. But that's not the idea at all. It's about being able to deliver functioning software as early as possible, i.e. to go the whole way through the software production process with all parties involved, including quality assurance and operation right into the production environment.

The idea is not to have all imaginable features ready with the first version, but only the two, three most important ones. For the following versions, we consider the feedback received from the end users and reprioritize our product backlog accordingly. This way you can prevent the waste of features.

Increasing the added value of the product from iteration to iteration

This philosophy is also known from the lean production corner: You try not to create any waste. Or to put it another way: to be as efficient as possible. You don't need a huge backlog to start development. It is sufficient to describe the first most important product backlog entries for the next two to three sprints in detail. The entries that follow later can also contain only the title. The Product Owner works on the backlog in coordination with the team. It evolves from iteration to iteration.

This continuous and regular maintenance of the backlog, including feedback from outside, sharpen the system to be developed more and more until it ultimately offers real added value for the end user.

Principle to remember:

Work iteratively, incrementally and feedback-driven.

Integrative, binding together – interdependent

For me, being integrative has to do with clear boundaries and clear communication. Components in the system are defined with clear responsibilities, so that they have only one task if possible. The elaboration of these clear responsibilities is the basis so that the system can exhibit a high degree of cohesion and loose coupling.

How well this definition of responsibilities has succeeded can often only be seen when implementing consistent user stories. Then the technical aspects, rules and processes come to light, and the components must function interdependently. This means that the different components in the system are interdependent and must be able to communicate with each other in a technically correct way.

Clear boundaries and responsibilities in the system and in the team

The clearer one can draw these limits of responsibility for the respective domain, the less dependent they are on each other. This means that a component can still work even if other components fail. The non-functioning components in the system try to restore themselves independently, so that the whole system can offer all the functions again. Here one speaks then of the resilience of a system: How resilient is a system, if individual components fail. And how fast can these be made available again?

In order to find as good responsibility borders as possible, I recommend to proceed also here after the principles of the Domain-driven Design and to make the component cut along the domain.

This idea of clear boundaries and responsibilities is also important for teamwork. The clearer the roles in the team are clarified, the more efficient it is. For me, being integrative – in terms of cooperation – means that as a team member I try to practice empathy and find the right language to be able to communicate honestly, openly and transparently with my other team members.

Principle to remember:

Create clarity about the responsibilities in the system and in the team.

My conclusion

I hope I was able to present the values that drive me in a comprehensible way. Perhaps I also encouraged you to focus on these values in your next project and discuss them in the team.

I myself keep noticing how important it is to talk about how we can better develop software together. In these conversations I learn a bit more about the complex mechanisms of software development and have to correct myself.

I think writing code and developing software is a deeply social art that can develop to its full potential when we better understand how we can do it together. And from my point of view this concerns all levels from the business to the technical to the social.

In this sense, I close with it: Love your teammates and love your code.

Contact for your Digital Solution with Unic

projektanfragen.de@unic.com+49 89 43 77 80 90

Book an appointment

Are you keen too discuss your digital tasks with us? We would be happy to exchange ideas with you: Jörg Nölke and Gerrit Taaks (from left to right).

Contact for your Digital Solution

projektanfragen.ch@unic.com+41 31 560 16 16

Book an appointment

Are you keen to talk about your next project? We will be happy exchange ideas with you: Melanie Klühe, Stefanie Berger, Stephan Handschin and Philippe Surber (clockwise).