How our software development is developing

It’s been ages since I gave you an insight into the development work at Digitec Galaxus AG – too long ago, in fact. Perhaps you remember this article:

Some time has passed since then and in the meantime the development department has expanded from five to twelve scrum teams. This brings with it its own problems that have to be carefully addressed. Various challenges arise from that, and we don’t think these will reduce in the coming years.

As a result of the swift growth of the development department, we noticed growing inertia linked with the company’s growth and saw growing need for development to develop further. (That sounds logical… or like a tongue twister. You decide.)

The challenges

• Over the last year, our scrum teams have grown from five to twelve.
• We’re anticipating further growth in the development department in the next few years.
• Many new members of staff require structured training.
• There are increased demands on reaction times to application (performance matters).
• We have to ensure scalability so we can up orders and user interaction.
• We have to make complexity transparent with clear modules (bounded contexts) and clean interfaces.

• The whole solution has to be transferred to the Cloud.

  Making complexity manageable

  It goes without saying that complexity is complicated. «Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple,» as Steve Jobs succinctly put it. Simplifying processes and problems requires not only technical knowledge but also detailed understanding of business procedures.

If a system is divided up in a strange manner, you just make the whole process unnecessarily more complicated. Instead, you could split it in such a way that you stay on top of things. Modularisation is good, but it’s not a cure-all. Creating purposeful modules doesn’t automatically remove complexity from the equation. It just transfers complexity to the interfaces between the systems.

In an ideal world, there would only be a few interfaces that would be as stable as possible. This would let teams concentrate on the work in one single module, rather than having to worry about the rest of the application.

Complexity can only be reduced when the requirements and capabilities of the system are reduced. Consequently, the primary goal isn’t to reduce complexity but to keep it under control.

How do you make it easier to keep control of complexity?

The theory:

• Partitioning involves splitting the whole system into various subsystems and having these communicate with each other using clear and simple interfaces.
• A clear hierarchy of the subsystems lets you review the whole system and gives clear dependencies and interfaces. This also makes it easier to correctly prioritise.

• Independence of individual subsystems allows you to focus on the responsibility of each of these systems.

  What I think are the important takeaways:

• We should remove any unnecessary processes and tasks that don’t add any value for the customer. After all, easy things can also be made complicated and bureaucratic. That is the definitely the most important point.
• We should bring the focus back to the customer. We need to ask if it benefits the customer and if so, if the the benefit is comparative.
• We need to look at our prioritisation process and ensure it has a clear strategy and vision.
• Everyone can contribute by complaining about complicated processes and discussing relevant problems in the open. But it is important that we don’t go looking for irrelevant problems.
• Flat hierarchies and team-oriented processes are essential.
• Responsibilities should be delegated amongst teams as much as possible.
• We should be able to make clear decisions in cases of doubt, even if not everyone is in agreement on a certain topic. Otherwise we could get stuck for ages, as there isn’t just one answer to any problem.

• We need take a constructive and optimistic approach and think about problems as being there to be solved. Even solutions can bring new problems to light. This is every engineer’s dream – it’s what makes them tick ;-).

  How do we deal with challenges?

  Here is a quick look at what happened at Digitec Galaxus AG in the last 15 months. You also get a sneak preview of what we have planned to further grow our development department.

  Specialisation according to domain

  The scrum teams were given a specific domain – in other words, a specific business area, such as logistics, product management or the online shop. This meant each team could specialise in their domain and develop improved and more elegant solutions thanks to a greater depth of knowledge. Each business area is normally represented by a department. The development teams work as closely as they can with the relevant departments to find out how to generate the most added value for customers with the current options. It’s also very important for us to have the most stable teams possible. Ideally, teams should work so well together that they’re in the zone.

  Interdisciplinary teams

  Our teams are no longer comprised of just software developers. We think it is important to combine all of the skills needed in the domain or subdomain. For instance, our online shop team includes interaction designers and front-end developers. Depending on the context, there may also be a requirements engineer, business intelligence specialist or systems engineer. The purpose is to reduce interfaces and shorten communication paths. A set-up like this should let teams work independently and stop them being held up by any obstacles.

  Coaching new teams

  On the whole, we build new teams from new members of staff. This stops the team makeup forever changing and ensures greater stability. To get staff trained and up to speed quickly, we give them a coach who covers specialist knowledge and methodology. Each new team is assigned a software developer who knows our environment inside out. They stay with the team for a set amount of time so they can answer any questions. A coach also focuses on the methodical side with the whole team when they’re working on scrum and agile software development.

  Skills and individual responsibility in teams

  It’s vital that every member of staff has the relevant information at their fingertips so they can work as enterprisingly as possible. This means that there is almost no company information that isn’t available to employees, be it our strategy, mission and vision or the results of staff surveys. This lets everyone check that what is supposed to be done is, in fact, in line with the company strategy. We think all our staff should know what kind of service we want to offer our customers. Our value proposition is public and transparent, meaning every customer can see how we measure up when it comes to performance versus promise.

  Cloud strategy

  Advances in technology have led us to the conclusion that the future lies completely in the cloud. Even today, new features are first or exclusively offered in the Cloud. With the multibillion investment in various Cloud platforms, this is set to further pick up pace. We won’t be relying on one sole provider to use Cloud services but on several. The deciding factors for us are the flexibility and innovation you get from the Cloud. That’s why new services will only be developed there. This will also be the case for overhauled business areas. We’ll be moving them as much as possible to the best Cloud platforms. At the moment, we have a few services on the Google Cloud Platform, Microsoft Azure and Elastic. Any parts of the application that haven’t been adapted will still run on our dual data centres on the premises. It doesn’t get more hybrid than that. This is yet further justification for the increasing importance of DevOps and why it is only set to get more important in future. After all, in the Cloud, infrastructure will be part of the application.

  I can’t think of any more changes at the moment, which probably means this article is already too long. With that, I had best sign off and try not to leave you waiting too long for the next update – well, not for a year. At least if I do that, I’ll be less likely to forget what has changed.

  Find out more about our software development

Want to join us as a developer?

We want to be able to develop even faster. If you like the sound of our vision, you may be interested in one of the jobs in our development department. It goes without saying that growth comes with an array of challenges. But if you’re the right fit, we know you’ll want to roll up your sleeves and get stuck in.