Agil arbeiten im SAP Umfeld

Wir arbeiten in vier Stufen in unseren Projekten / mit agilen Projektmanagement - wir bringen Sie schneller ans Ziel ! Versprochen !

Stufe 1: Der Aufbau agiler Teams

Vom Team Building in unserem digitalen Zeitalter, von agilen Teams bis zum SAP-Berater, dem Superstar, der endlich teamfähig wird und die agilen Werte versteht und aktiv in einem Scrum Team lebt. Wir schaffen Grundlagen, einen gemeinsamen Kalender und gemeinsame Regeln.

Stufe 2: Teams weiterentwickeln

Es erfolgt ein zielgerichteter schneller Kompetenzaufbau, Weiterbildung mit echten Learnings, ein mit den Teams, ein weiter abgestimmtes Regelwerk "Working Agreements" und praxiserprobte Praktiken für fortgeschrittene Teams und die Mitarbeiter in den Teams.

Stufe 3: Mit weltweit verteilten Teams und online arbeiten

Nicht erst seit COVID-19 in 2020 arbeiten wir mit weltweit verteilten Teams in allen Rollen und Prozessen. Mit Skype oder Zoom in Breakout Sessions, einem Collaboration Tool zum Beispiel DEON und echten „Deep Work Zeiten“, am Sprint Backlog arbeiten, effektive Refinements, Reviews und Retrospektiven gestalten!

Wir vermitteln unserer gelebten Praxis der agilen Coachings und der Projekt Management Erfahrung der letzten 20 Jahre durch unsere agilen Coaches, die alle Rollen Ihres Projekts auch übernehmen können.

Stufe 4: Echte Werte mit dem Value Stream Management schaffen „Values statt Story Points“

Jetzt kommt noch Kanban mit den besonderen Kanban Metriken ins Spiel. Mit Ihren Teams und den Kanban Metriken bauen wir für die Softwareentwicklung den Value Flow auf und entwickeln ihn kontinuierlich weiter.

Frage: Nutzen wir Scrum oder Kanban?  Antwort: Das gibt es für uns nicht! Wir nutzen Lean Kanban zur Ergänzung, arbeiten auch sehr oft mit einem Kanban-Board.

Frage: Wie agile ist unsere Methode? Antwort: Wir erstellen für Sie einen Agile Health Check!

Effektive Kanban Flußkonzepte helfen Ihren Teams weiterzukommen.

Unser Value Stream Management gibt Antworten zu den folgenden Themen:

  • Wie lange dauert es, bis wir neue Funktionen, eine neue Anwendung liefern können?
  • Wie lange arbeiten wir aktiv an ihnen [SAGAS, EPICs und STORYs]?
  • Neue Arbeiten beginnen, bevor die laufenden Arbeiten abgeschlossen sind
  • Deployments Rate (noch) zu niedrig
  • Consultants und Ressourcen richtig einsetzen
  • Keine Transparenz des gelieferten Kundenwerts
  • Technische Schulden sind nicht sichtbar

Nur so können wir die Deadlines unsere Release Pläne im Projekt einhalten. Story Points oder Schätzungen in Tagen oder in T-Shirt Sizes sind was für das interne Team und nicht tauglich für die Kommunikation mit dem Kunden und Stakeholder. Auch in der Kommunikation im Projekt mit dem Projektleiter oder dem gesamten Projektmanagement sind meistens die Metriken aus Kanban wie Durchfluß, Leadtime usw. effektiver und aussagekräftiger als Points und Velocity.

Unsere guten Praktiken bringen den Erfolg, die Steigerung der Velocity, Ihrer Teams ...

Good Practice 1 - Unsere erprobten Methoden aus vielen internationalen Projekten = Design User Stories:

Der aktuelle Scrum Guide definiert die fertige User Story, die „Done" ist wie folgt: „Entwicklungsteams liefern jeden Sprint ein Inkrement an Produktfunktionalität. Dieses Inkrement ist vollständig verwendbar, so dass der Product Owner sich jederzeit dazu entscheiden kann, es zu releasen.“

Der immer noch gegenwärtige Gedanke, wir entwickeln Software, paßt nicht in unsere neue Welt. Unsere Führung unser Grundverständnis sagt "Wir haben eine Standard Software gekauft, die wir nun modifikationsfrei an unsere Bedürfnisse anpassen sollten. Wir entwickeln die Software nicht neu".

Unsere „Design User Idee“ im SAP-ERP trifft deshalb nicht die Vorgaben des Scrum Guide.

Eine „Design User Story“ hat exakt definierte Akzeptanz-Kriterien nach WRICEF (workflows, reports, interfaces, conversions, enhancements and forms) und immer einen Prototype zum Ergebnis, um Kundenfeedback zu bekommen.

Ein für uns mächtiges Mittel, ein Werkzeug im Projekt des Risikomanagements, um Risiken zu reduzieren und das innerhalb eines zwei Wochen Sprints.

Design Dokumente, Power Points, Word Dokumente oder ähnliches passen nicht zu diesem Gedanken. Damit bekommen wir kein Kundenfeedback.

WRICEF kommt aus dem Solution Manager und beschreibt die modifikationsfreie Weiterentwicklung des Standards (Workflows, Reports, Interfaces, Conversions, Enhancements and Forms und natürlich die Methoden)

Eine agile Methode für Scrum Master nicht ganz nach dem Scrum Guide aber zur perfekten Risikoreduzierung und zur Risikominimierung.

Erstellen Sie noch heute mit Ihrem Scrum Master und Ihren agilen Führungskräften, den Experten, auch den Projektmanagern die erste S/4HANA Design User Story zur Umsetzung im nächsten Sprint. Ihre Einführung oder S/4 HANA Einführung wird zum Erfolg. Achten Sie bei der agilen Projektplanung mit Design Storys auf das Kundenfeedback. Nur mit einem einmaligen "live" gezeigten Prototype endet im Scrum Review die Abnahme der Anforderung. Nur so bekommen wir ein Kundenfeedback. Die Durchführung und Moderation des Events Review geht nur mit Live Demos.

Agilität live erlebt, heißt Live Demo im Scrum Review.

 

Good Practice 2 - Unsere erprobten Methoden aus vielen internationalen SAP ERP Projekten, aus unserem Projektmanagement mit professionellen Consultants in den Projektteams!

Aus Produkt Owner (kurz PDO) wird das PDO Team oder das PDO Tandem

Nochmal einen Blick auf den Scrum Guide und vielen Empfehlungen im Internet auf die Kompetenzen des PDO's.

"Es kann nur einen geben!" Geht im beschriebenen Umfeld, in unserer agilen Projektarbeit nie oder fast nie!

Der PDO ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht. Das ist eine große Herausforderung. Der Product Owner ist die einzige Person, die für das Management des Product Backlogs verantwortlich ist.“

ERP und S/4HANA sind unserer Meinung nach zu komplex, um mit einem PDO zu arbeiten. Alle unsere Kunden arbeiten mit einem eingespielten PDO Team. Oft einem Spezialisten PDO IT genannt und einem Profi für die Business Seite PDO BIZ genannt. Eingespielt und ohne Hierarchien coachen wir beide,

damit sie: 

  • Ziele und Missionen optimal erreichen
  • den Wert der Arbeit optimieren, die das Entwicklungsteam erledigt
  • Sicherstellen, dass das Entwicklungsteam die Product-Backlog-Einträge versteht.

 Es gilt modifikationsfrei Ihre Standardsoftware optimal an Ihre Anforderungen anzupassen, wir coachen Ihre erfahrenen PDO Teams, Tandem genannt, dazu in Ihren kreativen Projekten.

Es gibt viele weitere wichtige Praxiserfahrungen, die wir durch den „Inspect und Adapt“ Gedanken gelernt haben und in unseren Coachings und Projekten immer weeiterentwickeln.

 

Der agile Festpreis „Scrum mit externen Partnern geht nicht!“ = Unser "Lean Procurement"!

In großen Projekten versucht man oft, externe Partner, externe Profis mit Spezial Know-How für Ihre Geschäftsprozesse und Ihre Module, für Ihre Meilensteine einzukaufen und bindet diese in das Projekt mit ein. Für die Dauer des Projektes entstehen dann weitere Teams mit definierten Arbeitsweisen / Arbeitspaketen und vorgegebener Flexibilität.

Wenn die Einkäufer oder Einkaufsleiter, die die Verträge mit den externen Partnern, externen Dienstleistern, den externen Software-Entwicklern oder den externen Agenturen schließen, auf einfachste Zertifizierungen blicken, die man bereits nach 2 Tagen bekommt und diese externen Partner,  externen Consultants auch noch auswählen, mit dem klassischen Projektmanagement verwechseln, den Begriff Lean zusammen mit Fortschritt noch nie gehört haben, nun glauben, sie kommen mit den bisherigen Musterverträgen und Einstellungen weiter, dann haben sie mit dem oben genannten Argument „Scrum mit externen Partnern geht nicht“ vollkommen recht. sie brauchen nicht weiterzulesen.

Wer glaubt, Werkverträge mit dem günstigsten Anbieter nach ein zwei oberflächlichen Workshops schließen zu müssen, der sollte jede Art der intelligenten flexiblen Zusammenarbeit die Visionen und Strategien verfolgt einfach vergessen.

Das funktioniert in unserer neuen Welt nicht. Nicht die billigsten Partner mit ein, zwei PSM Schulungen, die aus You-Tube Videos das "Planning" kennen, steigern die Velocity, sondern die, die Werte, eine offene Kommunikation, wirklich mit seinen Teams verinnerlichen und verstanden haben liefern Mehrwerte. Die Anbieter die die agilen Prinzipien, die Grundlagen, das Manifest und positiven Werte leben und Spaß daran haben werden "in budget" wertvolle innovationen mit entsprechenden Skills und der Scrum-Methode liefern und in allen Projektphasen, über die Sprints echte Mehrwerte liefern. 

Sprechen Sie mit uns!

Eine gemeinsame Sprache, Teamentwicklung, Grundverständnis des agilen Manifests, Kenntnisse aus der Skalierung, Kenntnisse der Selbstorganisation und eine Risikoteilung bei Konzeption in der Anfangsphase agiler Projekte sind ein wichtiger Baustein in Ihrem ganzheitlichen agilen Festpreisprojekt.

Unsere Coaches und Berater stehen mit vielen guten erfolgreichen Ideen und ihrer Expertise für die Daily Scrums, die Artefakte, das Board, zur Verfügung.

Erreichen Sie Ihre ERP und S/4 HANA Projektziele in kleinen Iterationen, Ihre Software und Konzept Umsetzung, durch unsere hilfreichen und praxisbewährten "Good Practies", die auf dem richtigen Mindset aufbauen und auf Selbstorganisation setzen.

Wir haben viele Jahre selbst als SD-Berater, APO und BI-Berater, wir kennen die klassischen, traditionellen, damals auch effizienten Projektmanagement Methoden und Vorgehensmodelle rund um die Standard-Software, NetWeaver, die Technologie, wir arbeiten für den Mittelstand als auch für international tätige Konzerne.

Wir sprechen die Sprache der Führungskräfte, der globalen Scrum-Teams und vermitteln das agile Mindset.

Unser Workshop zum agilen Festpreis dauert in der Regel 2 Tage. Wir gestalten passen diesen Workshop exakt auf Ihre Situation und Rahmenbedingung an und finden je nach Implementierungsvorgaben, Komplexität und Implementierungskonzepten den Berater mit der richtigen Berufserfahrung.

Er gibt Ihnen vor dem geplanten Projektstart, vor der Lieferantenauswahl einen Einblick in unser zusammenhängendes Beratungsangebot und Organisationsentwicklung. 

Vergesst die perfekte Dokumentation!

Funktionierende Software ist wichtiger als umfassende Dokumentation

Bei oberflächlicher Betrachtung der vier Werte, der Grundsätze des Agilen Manifets könnte man bei der zweiten Zeile auf den Gedanken kommen, wir verzichten auf alle Dokumentationen und liefern nur noch funktionierende Software sowie funktionierende Prozesse.

So ganz stimmt das allerdings nicht, denn wenn wir weiterlesen im Agilen Manifest erfahren wir dann doch, dass die Dokumentation wichtig ist nur wir eine funktionierende Software als wichtiger betrachten.

Die Wahrheit liegt nach meinem Verständnis in der Mitte.

Wir eliminieren unsere Regeln von gestern:

In unseren Wasserfall Projekten und länderspezifischen Roll-Outs haben wir nacch alten Projektstrukturplänen dokumentiert, dokumentiert und dokumentiert. Für jeden Customizing Schritt, selbst im Grundcustomizing gab es eine Dokumentation. So richtig spannend wurde es, wenn wir über ein eigenes ABAP Programm einen Prozess erweitern oder anpassen mussten. Wir mussten eine sogenannte Anbau Doku (Add-on) anlegen, versionieren, das Add-On beantragen und auf vielen Seiten das Design mit Visio Charts beschreiben, im zweiten Teil wurde dann der ABAP Code, die technische Dokumentation in das Word Dokument reinkopiert und beschrieben. Der glasklare, sich eigentlich selbst erklärende ABAP Quellcode mußte nochmal Schritt für Schritt erklärt werden. 

Natürlich brauchen wir eine entsprechende Dokumentation.

Die Prozesse die, die Arbeitsergebnisse die wir dokumentieren entstehen in unserer neuen agilen Welt durch erzählen, aufmalen, Sticky Notes in mehreren Farben um diese zu erklären könnten wir Karteikarten nutzen, wir verlinken unsere Notizen, wir malen Bildchen, wir machen Fotos und verlinken diesse oder dokumentieren zum Beispiel über ein entsprechendes Video.

Wie im Urlaub, über unsere Urlaubsbilder und Urlaubsvideos kommt die Erinnerung zurück. Jeff Patton nennt das den „Urlaubsfaktor der Dokumentation“.

Gute Dokumentationen sind wie Urlaubsfotos, wir sehen sie an und erinnern uns genau was wir gemacht haben.

Versucht nie mehr die perfekte Dokumentationen zu erstellen. Hören Sie einfach damit auf Word Dokumente anzulegen, Hardcopies der Masken reinzukopieren und diese Feld für Feld mit gelben Hinweisen zu erklären und das Sprint-Ziel im Sprint Planning davon abhängig machen.

Beginnt zu schreiben und zu malen, geht in den Austausch mit Euren Team Mitgliedern, benutzt Worte, Bilder, Fotos, Skizzen um Schritt für Schritt zu einem gemeinsamen Verständnis zu kommen, dokumentiert selbstorganisiert den Projektverlauf.

Wir sprechen in der agilen Software und Prozess Entwicklung von Geschichten (=Stories). Wir drücken mit diesen Geschichten aus, wie wir einen Prozess nutzen werden. Wir tauschen uns aus und ergänzen die Geschichten um Bilder, Skizzen und wieder Bilder.

Fordern Sie unser Angebot für Ihre Implementierung an und lernen Sie unsere Vorgehensweise basierend auf den neuesten Erkenntnissen an!

Fordern Sie unser Angebot für Ihre Geschäftsführung, für Ihre Auftraggeber, für Ihre Produktentwicklung, für Ihre Projektmitarbeiter, für die agile Organisationsentwicklung, für Ihre Scrum-Projekt, für Ihre agile Transformation und für Ihre Fachbereiche an, wir sind Management 3.0 Co-Owner und coachen nach diesen Methoden von Jurgen Appelo.