ennovate.de


Zelos

Das ist 'ennovate'

  • 15 Jahre Erfahrung in professioneller Softwareentwicklung für unternehmenskritische Anwendungen
  • 15 Jahre Erfahrung in professioneller Softwareentwicklung unter Einsatz einer adäquaten Projektmanagementmethodik
  • 15 Jahre Erfahrung in professioneller Softwareentwicklung inkl. aller Höhen und Tiefen
  • 15 Jahre Erfahrung in professioneller Softwareentwicklung und es gibt immer wieder viel zu Lernen
  • 15 Jahre Erfahrung in professioneller und erfolgreicher ​Softwareentwicklung

Erfolgreich

Was bedeutet "erfolgreich"? Erfolgreich im Vergleich mit den Annahmen als das Projekt beantragt bzw. initiiert wurde? Erfolgreich, dass die Anwendung produktiv gesetzt wurde? Erfolgreich, dass die Anwendung jetzt Kundennutzen stiftet...obwohl sie Kosten und Termine sprengte? Das lässt sich daraus nicht entnehmen. Wann ist ein Projekt erfolgreich? Hält das Projekt die klassischen Constraints Zeit, Kosten und Umfang ein, so ist es trotzdem gescheitert wenn es keiner benutzt/kauft, etc.. Ein Projekt kann allerdings auch erfolgreich sein obwohl es abgebrochen wurde bzw. nie einen Cent verdient hat...das hängt davon ab wie die gewonnenen Erfahrungen im Unternehmen verarbeitet und verwendet werden und natürlich von der Unternehmenskultur.

Die Projekt-DNA

Jedes Projekt ist spezifisch und hat seine eigene Projekt-DNA:
Es gibt jede Menge Stellschrauben an denen man drehen kann bzw. muss um ein Projekt zum Erfolg zu führen. Gerade IT-Projekte verfügen über eine enorme Komplexität, sodaß ein Einzelner gar nicht in der Lage ist alles zu überblicken bzw. alle Stellschrauben alleine richtig zu justieren. IT-Projekte sind komplexe Systeme und aus diesem Grund muß man systemisch Denken.

Das große Problem

Immer und immer wieder sind die Anforderungen an das "Produkt" bzw. die Software das große Problem: "der Kunde weiß nicht was er will", "schon wieder alles geändert, wir drehen uns nur im Kreis", "das funktioniert nicht so wie damals geplant", "die Anforderung sind doch wesentlich komplexer, wir brauchen mehr Zeit", "alles unkoordiniert, die rechte Hand weiß nicht was die linke Hand macht", "das Management unterstützt uns nicht". Oder aber die entwickelten Features stiften keinen Nutzen: "das können wir nicht verwenden, wir brauchen was anderes", "im alten System war das aber anders" und so weiter und so fort.

Das eigentliche Problem sind allerdings nicht die Anforderungen sondern der Softwareentwicklungsprozeß.

Produktmanagement

Gerade wenn die Anforderungen nicht stabil sind bzw. der Markt sehr dynamisch ist muss man strategisch Denken und die high-level Ziele bestimmen und daraus dann zur gegebenen Zeit die Details (Anforderungen), d.h. die Produktfeatures, ableiten. Der Markt, also die Bedürfnisse des Kunden, müssen stetig mit dem Produkt bzw. der Produkt-Road-Map, abgeglichen werden. Es ist also wichtig dass man den Markt kennt und entsprechend handelt (outside-in). Und nicht technologiegetrieben einfach "drauf los rennt" und dann merkt: "das will ja keiner" (inside-out). Gerade in der Anfangsphase des Produktlebenszyklus ist das Produktmanagement - und damit die Rolle des Product Owners - von sehr großer Bedeutung:

Projektmanagement

Projektmanagement ist die Klammer die einen Rahmen bildet und die Arbeit des Systems (das Projekt) strukturiert. Gibt es diese Klammer nicht so bilden sich im System Krebsgeschwüre, die sich unkontrolliert ausbreiten, lebenswichtige Elemente des Systems befallen und letzten Endes zu dessen Tod führen. Diese Metapher soll verdeutlichen, dass sobald das Projekt bzw. der Softwareentwicklungsprozess nicht beherrscht wird alles aus dem Ruder läuft. Fehlt die Richtung wohin die Reise gehen soll, so werden die Anforderungen immer unklarer und die Codebasis verschlechtert sich zunehmend. Software-Entropie (u.a. Technical Debt) entsteht und beschleunigt den Verfall des Codes. Jegliche Art von Änderungen/Anpassungen und Erweiterungen sind nur mit großen Anstrengungen zu bewältigen. Ebenfalls schwellen die Testaufwände deutlich an, wobei die vielen Seiteneffekte von Änderungen gar nicht alle vorhergesehen bzw. getestet werden können. Die Qualität der Software nimmt stetig ab. Letzten Endes werden die Aufwände so groß, das das Projekt gestoppt oder die Software oder Teile davon neu implementiert werden müssen. In der Endphase kommen dann die "Todesmärsche", es ist nur noch möglich die Meilensteine durch exzessive Mehrarbeit zu halten: die Ressourcen werden verbrannt.

Agilität

Das agile Mindset ist selbstverständlich nicht bei jedem vorhanden und muss erst noch geformt werden. Menschen ändern sich allerdings nur zu einem gewissen Grad. Von daher sollte man schon von Beginn an versuchen die passende Mannschaft zusammenzustellen: "Getting the right people". Elemente mit der Einstellung: "ich bin die Nummer 1" kann man aus agilen Projekten getrost entfernen. Die entstehende Lücke wird vom Team, das erst danach entstehen kann, mehr als ausgefüllt.

Veränderung

Leadership

Je mehr man sich in Richtung Agilität bewegt desto mehr entfernt man sich von dem klassischen Modell des Projektmanagers. Der Projektmanager und seine Kumpanen (die TPLs, etc.) sind ja die, die alles per "command&control" planen, überwachen und steuern. Funktioniert aber nicht in einem dynamischen Umfeld in dem es keinen "perfekten Plan" geben kann. Deswegen muss es in einem agilen Umfeld mehrere "Projektmanager" geben um die Komplexität zu beherrschen: "divide&conquer". Es geht weg vom klassischen Projektmanager hin zum Servant Leader. Ein Wandel also, der natürlich auf Widerstände stößt.

Selbstorganisation

Und da wären wir dann angelangt - das Ende der Reise zur Agilität: die Selbstorganisation. Und um das in einem Projekt hinzukriegen, das ist wahrlich nicht einfach! Diese Selbstorganisation bezieht sich aber nicht auf des Entwicklungsteam allein, sondern auf das Projekt als Ganzes, das System mit all seinen Beteiligten.

Die 'ennovate' Leistungen

  • Interim
  • Coaching

Interim

Ihnen fehlt momentan eine erfahrene Ressource zur Besetzung einer wichtigen Rolle in Ihrem Softwareentwicklungsprojekt? Sie suchen einen:
  • Teamlead
  • Scrum Master oder ähnliches
  • jemanden der Struktur und Ruhe in das Projekt bringt
Dann sprechen Sie mich an!

Das 'ennovate' Coaching

Hauptziel des Coachings ist es die Kompetenz in der Durchführung von IT-Entwicklungsprojekten zu steigern. Im Vordergrund stehen hierbei die Managementaspekte. Da eine gewisse techniches Expertise ebenfalls nötig ist werden diese Aspekte ebenfalls in das Coaching integriert.

Zielgruppe
  • Startups, mittelständische Unternehmen
  • Mitarbeiter denen jetzt mehr Verantwortung zugetragen wird (Projektleiter, Scrum Master, Product Owner, etc.)
  • alle die, die nicht die gleichen Fehler machen wollen, die schon so oft zuvor gemacht wurden
  • Menschen mit Lust auf Neues

für Einzelpersonen oder Organisationen/Projekte
beides ist möglich

Schwerpunkte & Ziele
werden von Ihnen vorgegeben bzw. definieren wir gemeinsam

Leistungsspektrum

  • Projektmanagement (Methodiken, Praktiken, Tools)
  • technische IT Entwicklung (Architektur, Design, Praktiken)
  • Know-how Transfer aus der Praxis
  • Teamentwicklung
  • Management Know-how
  • Marketing Know-how
  • insbesondere Produktmanagement Know-how
...das sind nur einige Punkte

Ablauf
jedes Coaching ist individuell und somit ergibt sich immer ein eigener, individueller Ablauf passend zu Ihren Zielen/Wünschen & natürlich Ihrem Terminkalender

Dauer
Sie entscheiden

Kosten
ergeben sich aus dem Erstgespräch: "Money is what you pay and value is what you get!"