Cookies? Ja, auch wir haben welche. Mehr dazu gibts in der Datenschutzerklärung.

28. Apr 2020

Marc Thomann

Software Engineer

Seit der Gründung im 1983 hat Edorex schon manchen Trend kommen und auch wieder gehen sehen. Einige davon haben wir mitgemacht, andere eben nicht. Ein Trend, welcher uns in grossem Ausmass tangiert, obwohl wir ihn nicht mitmachen, ist Near- und Offshoring. Als KMU setzen wir auf Swissness und entwickeln alle unsere Lösungen in unseren Büros in Ostermundigen oder direkt bei den Kunden vor Ort (natürlich von der aktuellen Situation abgesehen).

Die Einflüsse von Near- und Offshoring sind trotzdem spürbar. Der Preisdruck ist gross und wird es auch bleiben. Wir bezahlen für unsere Member schweizerische Löhne und auch die anderen hiesigen Leistungen haben ihren Preis.

Also müssen wir bereit sein, uns zu bewegen, ständig alles zu hinterfragen und zu optimieren. Wir wollen unseren leistungsstarken Motor so einsetzen, dass wir möglichst ohne Reibungsverluste und mit hoher Effizienz die Projekte abwickeln können und in der Lage sind, uns am Markt zu behaupten.

2013 die Einführung von Scrum

Es ist schon einige Jahr her, die Edorex arbeitet nach RUP, die meisten Kunden wohl eher nach Wasserfall. Das (alte) Vorgehen mit Pflichtenheft und dann 9 Monate entwickeln im stillen Kämmerlein führte immer häufiger zu unbefriedigenden Ergebnissen. Mit dem agilen Vorgehen glaubten wir, einen möglichen Lösungsansatz für die Zukunft gefunden zu haben, und der wohl wichtigste Wandel der Edorex in den letzten Jahren begann.

«In Amerika arbeitet man schon lange mit Scrum, das müssen wir auch machen»
«Lasst uns mal Scrum probieren»
«Chömet mir mache mau öpis agils»

6 Member starten zusammen das Unterfangen PMBox – ein Experiment, um ein Projekt nach Scrum abzuwickeln. Wir lesen den Scrum Guide, erstellen unsere ersten User Stories und unser erstes Backlog. Und wir lernen in Retros ständig alles zu reflektieren und daraus Potential für weitere Verbesserungen abzuleiten. Das Experiment PMBox wird zu einem Erfolg.

2014 Edorex goes Agile

Die Erkenntnisse beginnen nach und nach die Firma zu beeinflussen. Was in einem kleinen Team entstanden ist, wird auf einmal in die gesamte Firma getragen.

«Wieso machen wir nicht alle Projekte nach Scrum»
«Ah i wetti wider äs Projekt wi PMBox»
«Chömet mir mache mau ä Retro»

Ja, wir wollen uns verändern. Die GL beschliesst, dass wir die Agilität in der gesamten Firma einführen wollen – «Edorex goes Agile».

Wir starten das Projekt EGA «Edorex goes Agile» – und die Transformation beginnt. Wir definieren als erstes ein Agiles Manifest mit Werten und Prinzipien, definieren mit Atlas unsere eigene konkrete Implementation von Scrum und machen unzählige Retros. Wir merken relativ schnell, dass dies nicht ganz so einfach werden dürfte und ein grosser Kulturwandel mit sich bringen wird.

2015 agiler Strategieprozess

Ja, die Einführung von Agilität bringt einiges an kulturellen Problemen mit sich. Nach x Jahren mit klaren Vorgaben soll auf einmal jeder noch mehr mitdenken und die Firma mitgestalten. Jeder soll akzeptieren, dass Hierarchien verschmelzen und man einander sagt, wenn etwas nicht passt? Das ist viel einfacher gesagt als getan.

Im Jahr 2015 haben wir uns im Strategieteam entschieden, dass wir nur vorankommen, wenn wir Agilität vorleben. Wir haben damit begonnen, alle unsere Edorex-internen Aufwände als User Stories (Jira Tasks) sichtbar zu machen und haben den gesamten Strategieprozess «agilisiert». Neu ist nicht mehr nur ein Strategieteam zusammen mit GL und VR zuständig, wir sind eine Gruppe von 12 Personen, welche zusammen die Vision und Strategie für die nächsten Jahre definiert. Wir leben vor, was Agilität heisst und damit steigt auch die Akzeptanz!

2016 Fokus, Fokus, Fokus – der Blueprint wird geboren

«Wir machen irgendwie alles»
«Wir haben keine klare Identität»

Mit der firmenweiten Einführung der Agilität stieg auch das Bewusstsein für unsere Qualitäten. Aber auch die Erkenntnis, dass wir noch sehr viel Potential besitzen. Mit jeder Retro und jedem neuen Durchgang, um die Firma weiter zu optimieren, wurde uns mehr bewusst, dass wir besser Experten in wenigen Sachen sind, anstatt viele Sachen mittelmässig zu beherrschen.

So haben wir am Strategie-Workshop 2016 einige wichtige, aber nicht ganz einfache Entscheidungen getroffen:

  • Wir machen keine Java Projekte mehr
  • Wir machen keine Access Projekte mehr
  • Wir wollen uns auf einen Kern von Technologien konzentrieren
  • Wir wollen Experten sein, in dem was wir tun
  • Wir wollen in allen Projekten nach Scrum arbeiten

Aber warum eigentlich?

  • Wir können gezielt Know-How aufbauen
  • Wir können uns als Firma stetig verbessern
  • Wir können gemeinsam voranschreiten
  • Wir reduzieren Abhängigkeiten von Einzelpersonen
  • Wir können Redundanzen vermeiden
  • Wir werden richtig gut in den was wir machen
  • Unsere Verkäufer wissen genau, was sie verkaufen
  • Bewerber für eine Arbeitsstelle wissen, worauf sie sich einlassen

Aber wie wollen wir das Ding benennen? Wie machen wir das greifbar? Wie kommunizieren wir darüber?

Der Blueprint wurde geboren. Er definiert die Art und Weise, wie und womit unsere Lösungen entstehen. Der Blueprint ist für uns alle verbindlich. Das Bild ist eine Momentaufnahme vom Januar 2020 – er ist einer laufenden Weiterentwicklung unterworfen, neue Erkenntnisse aus den Projekten, unseren Communities und dem Markt werden aufgenommen und führen in allen Bereichen zu einer regelmässigen Aktualisierung.

2017 Organisation mit fixen Teams

Fokus auf Technologie und Vorgehen ist gut für den Verkauf oder für das einzelne Projekt, aber was machen wir, um die gesamte Organisation auf ein nächstes Level zu bringen?

Im 2017 haben wir uns entschieden, in Zukunft mit fixen Teams zu arbeiten und die Projekte zu den Teams zu bringen und nicht mehr wie bisher, das Team um ein Projekt herum jedes Mal neu zu formieren. Dies hat den Vorteil, dass wir gemeinsam ein Projekt von der Offerte bis und mit Wartung planen und durchführen können und somit das Know-How und die Verantwortung auf mehrere Schultern verteilt ist.

Mehr dazu in einem eigenen Blogbeitrag: Wie funktioniert die Organisation mit fixen Teams?

Durch diesen Entscheid kamen auf einmal viel mehr Edorex-Member mit allen Prozessen in Kontakt als zuvor. Und da mittlerweile das Streben nach Verbesserung in vielen Köpfen bereits fix verankert war, konnten wir auch neues Optimierungspotential aufdecken.

2020 Blueprint ist alles

Mittlerweile bezeichnen wir unseren Blueprint als Werkzeugkasten für all unsere Prozesse und Abläufe im Rahmen der Software-Entwicklung. Es betrifft alles von Akquise, zur Umsetzung bis und mit Wartung. Potential schlummert überall und besonders auf den Schnittstellen zwischen den einzelnen Personengruppen konnten und können wir viel optimieren.

Der Blueprint ist längst nicht mehr nur technisch.

  • Wir bauen damit Brücken und optimieren Schnittstellen
  • Wir sind damit Full-Stack Member und Mitunternehmer
  • Wir werden und sind Experten in dem was wir machen
  • Wir vermeiden Redundanzen und sind dadurch effizient
  • Wir haben Spass damit

Als Edorex haben wir eine grosse Transformation hinter uns (und optimieren weiter). Wir sind Kunden- und Kundenprodukt-orientiert und bauen als fixe Teams Domain-Know-How auf. Wir werden zu Partnern für unsere Kunden und hinterfragen bereits in frühem Stadium einer Software-Entwicklung viele Punkte. Dies führt zu besseren Produkten, welche in kurzer Zeit am Markt sind.

Wir haben gelernt über unseren Entwicklerhorizont zu schauen und eine Sprache zu sprechen, welche alle Projektinvolvierten verstehen. Dies führt dazu, dass wenige Missverständnisse entstehen und die Wege sehr kurz sind. Langfristig steigt das Vertrauen und alle arbeiten zusammen an der nächsten Erfolgsstory.

Der Blueprint ist alles – er ist unsere Antwort auf Near- und Offshoring.

zum Blog

Kontakt aufnehmen