Wie sich unsere Softwareentwicklung entwickelt

Lange ist es her, zu lange, da habe ich einen Einblick in die Entwicklungsarbeit bei Digitec Galaxus gegeben. Vielleicht erinnert sich der geneigte Leser an den Artikel:

Seither ist einige Zeit ins Land gegangen und die Entwicklungsabteilung hat sich von fünf Scrum-Teams auf aktuell zwölf Teams vergrössert. Das bringt einige Problemstellungen mit sich, die man sorgfältig angehen muss. Womit wir bei den vielseitigen Herausforderungen angekommen sind, die sich uns aktuell stellen. Und die vermutlich auch nicht kleiner werden in den nächsten Jahren.

Durch die schnelle Entwicklung der Entwicklungsabteilung hat sich durch die sich entwickelnde Schwerfälligkeit mit dem Wachstum der Entwicklung das Bedürfnis entwickelt, die Entwicklung weiterzuentwickeln. (Logisch! Fast schon ein Topos.)

Die Herausforderungen

• Im letzten Jahr Wachstum von fünf auf aktuell zwölf Scrum Teams
• Eine weiteres Wachstum der Entwicklungsabteilung steht in den nächsten Jahren an
• Viele neue Mitarbeiter erfordern einen strukturierten Know-How-Aufbau
• Erhöhte Anforderungen an die Reaktionszeiten der Applikation (Performance matters)
• Sicherstellung der Skalierbarkeit für eine weitere Vervielfachung der Bestellungen und der Benutzerinteraktionen
• Die Komplexität durch klare Module (Bounded Contexts) und sauberen Schnittstellen transparent machen
• Die Verschiebung der gesamten Lösung in die Cloud

Komplexität beherrschbar machen

Mit der Komplexität ist es kompliziert. «Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple», sagte Steve Jobs. Abläufe und Probleme einfacher zu machen, erfordert nicht nur technisches Wissen, sondern detaillierte Kenntnisse der Geschäftsprozesse. Wenn ein System unsinnig aufgeteilt wird, erhöht man damit die Komplexität unnötig, anstatt sie zu beherrschen. Modularisierung ist gut, aber kein Allheilmittel: auch wenn man sinnvolle Module erstellt, wird damit die Gesamtkomplexität der Lösung nicht reduziert. Sie wird einfach in die Schnittstellen zwischen den Systemen verlagert. Im Idealfall gibt es wenige, möglichst stabile Schnittstellen. So kann sich ein Team auf die Arbeit in einem einzelnen Modul konzentrieren und muss sich nicht um den Rest der Applikation kümmern.

Die Komplexität kann nur reduziert werden, wenn auch die Anforderungen und die Fähigkeiten des Systems reduziert werden. Somit ist es nicht das primäre Ziel, die Komplexität zu reduzieren, sondern sie zu beherrschen.

Und wie macht man Komplexität besser beherrschbar?

Die Theorie dazu:

• Durch Partitionierung. Indem man das Gesamtsystem in verschiedene Teilsysteme aufteilt und diese über klare, möglichst einfache Schnittstellen, untereinander kommunizieren lässt.
• Durch eine klare Hierarchie der Teilsysteme untereinander, damit das Gesamtsystem überblickt werden kann und klare Abhängigkeiten und Schnittstellen bestehen. Damit wird es auch ermöglicht, klar zu priorisieren.
• Unabhängigkeit der einzelnen Teilsysteme, damit man sich dort mehrheitlich nur auf den Zuständigkeitsbereich eines Teilsystems kümmern kann.

Was ich dabei wichtig finde:

• Unnötige Prozesse und Arbeitsschritte, die keinen Mehrwert für den Kunden bringen, weglassen. Das ist klar der wichtigste Punkt. Man kann auch einfache Dinge beliebig kompliziert und bürokratisch machen.
• Den Fokus auf den Kunden legen. Bringt es für den Kunden einen Nutzen? Und ist der Nutzen verhältnismässig?
• Womit wir bei der Priorisierung sind, und für eine sinnvolle Priorisierung braucht es eine klare Strategie und Vision.
• Jeder einzelne kann mithelfen, indem er bei komplizierten Prozessen reklamiert und relevante Probleme offen anspricht, aber auch keine neuen irrelevanten Probleme sucht.
• Flache Hierarchien und eine teamorientierte Arbeitsweise.
• Kompetenzen sollen so weit wie möglich in die Teams delegiert werden.
• Es muss im Zweifelsfall möglich sein, klare Entscheidungen herbeizuführen. Auch wenn vielleicht nicht alle einig sind. Sonst blockiert man sich ewig, man kann schliesslich fast jedes Problem unterschiedlich lösen.
• Sei konstruktiv und optimistisch, denn Probleme sind da, um gelöst zu werden. Und die Lösungen bringen neue Probleme ans Licht. Damit beginnt der Kreislauf und Traum eines jeden Ingenieurs ;-)

Wie gehen wir mit den Herausforderungen um?

Hier nun eine kleine Übersicht, was in den letzten fünfzehn Monaten passiert ist. Und was wir uns vorgenommen haben, um unsere Entwicklungsabteilung zu entwickeln.

Spezialisierung nach Domäne

Die Scrum-Teams wurden klar einer Domäne zugeordnet – also einem definierten Geschäftsbereich wie zum Beispiel Logistik, Produktmanagement oder Onlineshop. Jedes Team kann sich so auf diesen Bereich spezialisieren und mit der steigenden Tiefe des Wissens und der einzelnen Prozesse immer elegantere und bessere Lösungen entwickeln. Der Geschäftsbereich wird üblicherweise durch eine Abteilung repräsentiert. Das Entwicklungsteam arbeitet so nah wie möglich mit diesem zusammen, damit man möglichst gut herausfindet, wie man mit den aktuellen Möglichkeiten den grössten Mehrwert für den Kunden generieren kann. Es ist uns ebenfalls sehr wichtig, dass ein Team möglichst stabil ist. Im Idealfall ist ein Team so gut eingespielt, dass es im Flow ist.

Interdisziplinäre Teams

In einem Team arbeiten nicht mehr nur Softwareentwickler, sondern ein Team soll immer alle Kompetenzen vereinen, die in der Domäne oder der Subdomäne notwendig sind. In einem Onlineshop-Team arbeiten also zum Beispiel Interaction Designer und Frontend-Entwickler mit. Je nach Kontext wird auch ein Requirements Engineerin, Business-Intelligence-Spezialist oder System Engineer als Unterstützung beigezogen. Damit sollen die Schnittstellen reduziert und die Kommunikationswege verkürzt werden: Das Team soll eigenverantwortlich ohne Hindernisse arbeiten können und nicht durch unnötige Abhängigkeiten gebremst werden.

Coaching neuer Teams

Damit die Teams möglichst stabil sind und sich die Zusammensetzung nicht dauernd ändert, werden neue Teams mehrheitlich aus neuen Mitarbeitern gebildet. Damit der Knowhow-Aufbau trotzdem schnell geht, werden diese sowohl fachlich als auch methodisch durch einen Coach begleitet: Ein mit unserer Umgebung vertrauter Softwareentwickler begleitet ein neues Team für eine gewisse Zeit und steht für Fragen zur Verfügung. Auf der methodischen Seite arbeitet ein Coach im Bereich Scrum und agiler Softwareentwicklung mit dem gesamten Team.

Kompetenzen und Eigenverantwortung in den Teams

Damit jeder einzelne Mitarbeiter unternehmerisch mitarbeiten kann, ist es notwendig, dass die relevanten Informationen frei zugänglich sind. Das bedeutet, dass wir praktisch keine Informationen mehr haben, die nicht für alle Mitarbeiter zugänglich sind. Seien es unsere Strategie, Mission und Vision oder die Resultate von Mitarbeiterumfragen. Damit kann jeder prüfen, ob das, was gemacht werden soll, auch im Einklang der Unternehmensstrategie ist. Es ist wichtig, dass jeder weiss, was wir gegenüber dem Kunden für eine Leistung erbringen wollen. Unser Nutzenversprechen ist öffentlich und transparent, damit auch jeder Kunde unsere Leistung an unserem Anspruch messen kann.

Cloudstrategie

Auf Grund der technologischen Fortschritte sind wir zur Meinung gelangt, dass sich die Zukunft vollständig in der Cloud abspielen wird. Schon heute werden neue Features zuerst oder sogar exklusiv in der Cloud angeboten. Mit den Milliardeninvestitionen in die verschiedenen Cloud-Plattformen, wird sich dies weiter beschleunigen. Und um diese auch zu nutzen, setzen wir nicht nur auf einen Anbieter, sondern auf mehrere. Entscheidend ist die Flexibilität und die Innovation, die man durch die Möglichkeiten der Cloud gewinnt. Daher werden neue Services nur noch in der Cloud entwickelt. Auch wenn wir einen Bereich überarbeiten, wird soweit möglich alles auf die jeweils optimale Cloud-Plattform verschoben. Aktuell haben wir bereits einzelne Services auf der Google Cloud Platform, auf Microsoft Azure und dazu noch Elastic im Einsatz. Dazu werden alle Teile der Applikation, die noch nicht angepasst wurden, weiterhin On-Premise in unseren Dual Datacenter betrieben. Mehr hybrid geht nicht. Was auch begründet, warum DevOps viel wichtiger geworden ist und in Zukunft noch wichtiger wird. Denn in der Cloud wird die Infrastruktur ein Teil der Applikation.

Mehr Änderungen fallen mir gerade nicht mehr ein. Und so oder so ist der Text nun langsam aber sicher zu lange geworden. So schliesse ich damit meinen Beitrag ab und nehme mir vor, das Publikationsintervall zu verkürzen, damit es nicht mehr länger als ein Jahr geht. So steigt auch die Chance, dass ich nicht vergessen habe, was wir alles verändert haben.

Mehr über unsere Softwareentwicklung

Du willst mit uns entwickeln?

Wir möchten noch schneller entwickeln. Wenn dich unsere Vision überzeugt, dann sind hier vielseitige Stellenangebote bei uns in der Entwicklungsabteilung zu finden. Und natürlich bieten sich auch sonst viele Herausforderungen beim Wachstum.