Alle Artikel in der Kategorie “Allgemein

Kommentare 0

UI/UX Entwickler (m/w) für Angular SPA – Stuttgart ab 01.2019 Vollzeit mit 40% Vor-Ort

Wir entwickeln in zwei Scrum Teams Web-Applikationen für Automotive-Dienstleistungen eines OEM. Unsere Kunden nutzen die Dienste mobile als auch auf dem Desktop. Hast Du Erfahrung wie ein User-Interface aufgebaut sein muss? Kannst Du uns bei der Umsetzung neuer Features mit der richtigen User Experience helfen? Idealerweise beherrschst Du Angular, Typescript und kennst Dich in CSS aus. Unsere Apps (SPAs) sind schon produktiv, wir sind also im DevOp’s Mode. Wir nutzen eine Cloud-Container Infrastruktur und bauen Microservices im Backend.
Melde Dich gern bei mir – ich bin auch selbst in den Teams aktiv und kann so auch etwas zum realen Projekt aus der Praxis erzählen. Die Zusammenarbeit haben wir abwechselnd eine Woche (Mo-Do) Vor-Ort und eine Woche remote organisiert.
Janko Böhm: +49.175.93.68.111 Tel/WhatsApp; janko.boehm@methodenfabrik.de

Kommentare 0

Scrum Master & Team Coach in 45257 Essen – Teilzeit möglich

Ein Software Entwicklungsteam in Essen sucht einen neuen Scrum Master, da dieser zum Jahreswechsel das Team verlässt. Wenn Du jetzt schon Zeit hast, kannst Du direkt starten und die Zeit bis zum Jahreswechsel als Übergabephase nutzen.
Das Team ist nicht ganz unerfahren, möchte auf den Facilitator aber nicht verzichten. Technisch ist das Team gut aufgestellt, braucht aber einen verständnisvollen Coach, der bei Klippen im persönlichen Umgang einfühlsam unterstützt.
Auch wenn Du in der Rolle des Scrum Masters noch nicht so lang arbeitest, aber agile Prinzipien kennst, Scrum Praktiken Dir nicht fremd sind und soziale Skills im Umgang mit Menschen Deine Stärke ist, könnte das Deine Herausforderung sein.
Melde Dich gern bei mir, Janko Böhm +49.175.93.68.111 oder janko.boehm@methodenfabrik.de

Kommentare 0

Technology Lead als Leitwolf für ein Dev-Team in Berlin

Du kennst die neusten Entwicklungen im Bereich Web Development und weißt wie man robuste, skalierbare Software Architektur baut?
Triffst Du auch gern technische Entscheidungen, argumentierst und verteidigst diese? Das ganze aber nicht nur theoretisch, sondern entwickelst auch gern noch selbst guten Code?
Da haben wir eine Herausforderung, bei der Du neben dem reinen Code schreiben auch Deine technischen und kommunikativen Stärken einbringen kannst.
Wir arbeiten in einem verteilten Umfeld mit mehreren Teams und bauen Web Services sowie Web Anwendungen. Deine Kenntnisse insbesondere in JavaScript (HTML, CSS Frameworks), WebAPIs (REST), TypeScript wollen wir nutzen um gute, stabile und skalierbare Produkte zu bauen. Wir erweitern Microservices-Architekturen in einer AWS Cloud für Applikationen und Services die schon produktiv sind. Uns fehlt aber noch ein Leitwolf der nah am Team ist und technisch dem Produkt Struktur und Richtung gibt.
Janko Böhm: +49.175.93.68.111 janko.boehm@methodenfabrik.de

Kommentare 0

Wir suchen: Product Owner Support – Story Editor in 71636 Ludwigsburg


Wir suchen nach Unterstützung für unseren PO. Wir haben zwei Team die jeweils eine iOS App entwickeln. Dazu brauchen wir viele kleine gut geschriebene User Stories für unsere Entwickler-Teams. Leider hat unser PO nicht genügend Zeit um diese immer selbst aus zu formulieren und in’s Jira zu bringen. Kannst Du uns auf freiberuflicher Basis unterstützen? Vollzeit – oder auch nicht, hast Du Lust auf kreative Leute in zwei jungen Teams mit viel Raum für Deine Persönlichkeit? Wir sprechen Deutsch.

Kommentare 0

Agile Transformation Navigator – Mit Augenmaß die richtige Dosis zwischen Speed und Reifegrad

Agilität erscheint manchmal als die Antwort auf alle Probleme in der Produktentwicklung. Wenn dann noch agile Produktentwicklungsprozesse so verstanden und gelebt werden dass keine Planung und keine klare Ausrichtung auf ein gemeinsames Ziel mehr stattfinden muss – denn wir sind ja agil, kann das auch schnell schief gehen.

In dem Post des Transformation Navigators möchte ich 2 Dimensionen (Speed und Reifegrad) aufspannen. Innerhalb der zwei Dimensionen bestimmen wir zum einen die Position des Teams und zum anderen die Position des Auftrags bzw. des zu erzeugenden Produkts. Eine räumliche Nähe zeigt dann an, dass das Team mit den passenden Werkzeugen, Praktiken und Prinzipien das Produkt erstellt. Wenn beide Punkte weiter auseinanderfallen wird ein Weg sichtbar den entweder das Produkt zum Team, oder das Team auf das Produkt hin zurücklegen sollte.

Suchen wir uns die richtigen Produkte und Aufträge für das bestehende Team?

Haben wir das richtige Team mit den richtigen Werkzeugen für die Aufgabe?

Das Paper der „Agile Transformation Navigator“ spannt dazu die Landkarte auf und setzt das Boot „Team“ wie auch das Boot „Produkt-Ziel“ auf das Wasser. Wie lang ist die Stecke zum paddeln?

Download – Agile Transformation Navigator

Kommentare 0

Agile Coach – Wir suchen Dich für Automotive Projekt in Stuttgart

Wir suchen zur Unterstützung von 3 agilen Team mit „starken Persönlichkeiten“ einen erfahrenen Coach der agile Werte stärkt, für die Einhaltung und Durchführung der Zeremonien  sorgt und dem Team hilft, sich auf den Kundennutzen zu konzentrieren.

Die Teams bauen an der Integration von Cloud Diensten wie AWS und IBM in die Konzern-Infrastruktur. Innovative Applikationen und neue Dienst nutzen diese Lösungen am Automotive – Standort Stuttgart.

Zusammen mit Ihnen/Dir möchten wir die Teams noch effektiver machen. Wir wollen agile Werte hochhalten und die Gruppe von Leuten zu erfolgreichen Teams machen.

Wir haben Unterstützung aus dem Management und Freiheiten zu Gestalten.  Interesse?

Janko Böhm  

Kommentare 0

Kosten der Projekt Gesundheit

Unternehmer treffen Entscheidungen auf Basis von Daten. Diesem Grundsatz wollte ich ebenso bei der Auswertung der Projekt-Gesundheit folgen. Entscheidungen über Maßnahmen sollen auf Datenbasis getroffen werden und Kosten dem Nutzen gegenübergestellt werden.

Als Ergebnis lagen mir aber nur die Handzeichen der Teammitglieder vor.

Kent Schwaber hat das Modell Evidence-Based Management entwickelt, die eine Datenbasis schafft um Entscheidungen nach Wertschöpfung zu treffen. Donald G. Reinertsen argumentiert 2009 im Buch Product Development Flow auch für einen Daten-basierten Ansatz zur Priorisierung nach Wert, dem Profit aus dem Produkt.

Eine wichtige Aussage von beiden dazu ist, die Entscheidungen auf Kennzahlen zu begründen die auch genau diese Wertschöpfung direkt ausdrücken. Kent Schwaber nennt das „evidence“. Wenn Unternehmen die gute bzw. korrekte Umsetzung von Scrum Praktiken und Zeremonien im Unternehmen messen, ist das eine Stellvertreter-KPI: „cirumstanced evidence“. Kent definiert den Agility Index in Punkten, der einen Reifegrad aus verschiedenen Bereichen verrechnet. Dieser Index kann über die Zeit gemessen werden und zeigt einen Trend. Ebenso können die aufgewendeten Kosten je Agility Index Punkt ausgewiesen werden. Ebenso dient der Index als Vergleichsgröße zwischen Unternehmen und in der Branche.

Diese sinngemäß gleiche Aussage der Unterscheidung von Stellvertreter KPIs von „echten“ KPIs drück Donald Reinerts auch aus. Er spricht dabei von „proxy variable“. Reinertsen nutzt als KPI den Profit des entwickelten Produkts über dessen Lebenszyklus: den „Life Cycle Profit“.

Seit einiger Zeit sind die Indikatoren des Produkt-Erfolgs auf denen Evidence-Based Management basiert, auch öffentlich zugänglich:

  1. Produkt Kosten Verhältnis
  2. Mitarbeiter Zufriedenheit
  3. Kundenzufriedenheit
  4. Umsatz je Mitarbeiter
  5. Gesamtanzahl von Fehlern
  6. Auslieferungsfrequenz
  7. Stabilität der Lieferungen bzw. Produkt-Inkrement
  8. Dauer einer Iteration
  9. Anzahl der Produktinstallationen
  10. Anzahl der Produkt-Nutzung
  11. Innovationsrate

Es werden die Bereiche Mitarbeiter, Kunden, Produkt, Kosten und Innovation berücksichtigt. Genaueres auf Scrum.org 

Diese Ideen habe ich aufgegriffen, um den Spotify Health Check Approach von Henrik Kniberg und Kristian Lindwall auszuwerten. Wir haben im Projekt das Assessment im Zuge unserer letzten Retrospective durchgeführt. Dazu hat jedes Teammitglied in den 12 Bereichen sein voting wie folgt abgegeben   „grün“ alles OK, „gelb“ könnte verbessert werden, „rot“ starker Handlungsbedarf. Diese votes habe ich gezählt.

Die Wertungen habe ich als Handlungsdruck in Zahlen ausgedrückt:  Grün = 0 (kein Handlungsdruck), Gelb = 1, Rot = 3 (hoher Druck, mehr als doppelt so hoch als bei einer Meldung für gelb)

Ausmultipliziert ergibt sich so je Bereich eine Kennzahl „Handlungsdruck“ die über die Zeit zu einem Trend führt.

In der Sektion „Mission“ hatten wir 15 grün und 3 gelb Meldungen. Das Führt zu einem Health-Index im Bereich Mission von 3   ( 15×0 + 3×1 + 0x3 ). Normiert auf 18 Teilnehmer zu Mission Health  0,17

Anders ausgedrückt weichen wir im Bereich „Mission“ um 17 Punkte vom Ideal-Zustand Null (kein Handlungsdruck) ab.

Maßnahmen welche wir im Team ergreifen, die zu einer Veränderung der Kennzahl führen, können wir in Euro ausdrücken. Wenn wir diese Kosten zur Veränderung des Health-Index ins Verhältnis setzen lassen sich die Kosten eines Health-Index Punkts errechnen.

Für das gesamte Produkt-Entwicklungsteam ergibt sich ein Health Index aus der Summe der Sektionen-Einzelwerte. Ich unterstelle dabei, dass alle Kriterien gleichberechtigt sind.

Dieser Health Index kann nun mit anderen Produktentwicklungs-Teams verglichen werden. Ebenso können wir so die Kosten der Verbesserung je Health Index-Punkt zwischen den Produkt-Teams vergleichen. Bei welchem Team ist eine Verbesserung billiger bzw. teurer – so können wir nach dem Warum fragen.

Kommentare 0

Gesundheit agiler Projekt & Teams

In Retrospectives wird der zurückliegende Sprint im Team besprochen. Gute Ideen und Praktiken werden gesammelt und im Team besprochen wir daraus noch mehr Nutzen gezogen werden kann. Ebenso kommen Punkte zur Sprache die weniger gut gelungen und verbesserungsfähig sind.

Das zugrundeliegende Vorgehen haben Henrik Kniberg und Kristian Lindwall hier ausführlich beschrieben. Ich habe noch die Kategorie „Feedback“ ergänzt und auf Deutsch erstellt. Das Ganze ist ein praktisches Werkzeug für die Phase „Gather Data“ der Retrospective.

Ablauf

  1. Der Coach oder Scrum Master stellt den Gesundheitscheck im Team vor
    • Ziel : Breites Spektrum in der Retro abdecken und Trends erkennen
    • Vorgehen
    • Kategorien
      1. Support : Bekommen wir die Hilfe die wir brauchen?
      2. Teamwork :   Funktioniert unser Team?
      3. Delivering Value : Bauen wir das Richtige?
      4. Einfache Lieferung : Können wir continous delivery ?
      5. Code Base :  Haben wir eine gesunde Source Code Base ?
      6. Lernen : Praktizieren wir  cross functional learing?
      7. Mission :  Haben wir einen gemeinsamen Fokus ?
      8. Selbstbestimmtheit :  Leben wir das starke agile self-empowered team?
      9. Speed : Liefern wir schnell?
      10. Abläufe :  Arbeiten wir effizient mit abgestimmtem Vorgehen?
      11. Feedback : Nutzen wir Feedback zur Verbesserung?
      12. Fun  :  Haben wir auch Spaß an der Sache?
  2. Jedes Team-Mitglied erhält 3 Ampel-Karten oder die Bewertung erfolgt über die Handzeichen.
  3. Für jede Kategorie wird die Bewertung im Team erfragt – alle zur gleichen Zeit – wie beim Planning Poker. Die Anzahl der Nennungen je Kategorie wird auf einem Board gesammelt.
  4. Schwerpunkte werden sichtbar und können in der weiteren Retrospective mit Maßnahmen unterlegt werden.

Download der Karten

Sample

 

Kommentare 0

Das Ende eines Agilen Projekts finden

Kosten-Nutzen Break-Even in agilen Projekten

Das richtige Ende eines Projekts zu finden ist nicht immer so einfach. Der Vertrag beschreibt noch viele Elemente und das Budget ist auch noch nicht aufgebraucht. Das Team macht einen guten Fortschritt – warum aufhören?

Die Agile Idee stellt den Nutzen für den Kunden in den Mittelpunkt aller Entscheidungen. Elemente mit einem hohen Nutzen werden zuerst umgesetzt. Das heißt aber auch, das Elemente mit geringerem Nutzen später umgesetzt werden.

Das Agile Projektteam ist über die Projektlaufzeit konstant und damit sind die Kosten auch in jeder gleich langen Iteration ebenso konstant.

Das heißt dann, dass in den früheren Iterationen mehr Wertschöpfung je eingesetzter Mittel erzeugt wird.

Wenn man nun den geschaffenen Wert und die dafür eingesetzten Mittel über die Projektlaufzeit gegenüber stellt, ergibt sich eine abflachende Kurve der Wertschöpfung zu konstant wachsenden Kosten. Beides trifft sich in einem Punkt. Ab diesem Punkt – dem Kosten-Nutzen Break Even – übersteigen die Kosten den geschaffenen Wertbeitrag in der Iteration.

An diesem Punkt sollte sich der Kunde und das Projektteam bzw. der Dienstleister die Frage stellen: Können wir in einem anderen Umfeld der Organisation einen größeren Nutzen schaffen oder sollten wir den Projektumfang nach Vertrag erfüllen?

Wenn der Vertrag es vorsieht, hat der Auftraggeber den Vorteil nicht zu viel für weniger werthaltige Elemente zu zahlen. Der Auftraggeber hat einen Antrieb den Dienstleister nicht „aus-zupressen“ und Scope in die bewusst offen gehaltenen Use Cases zu interpretieren.

Das Team kann mehr Wertschöpfung für die Organisation schaffen und das Messen der Erfüllung aller vertraglich zugesicherten Bausteine tritt hinter die Frage der Wertschöpfung für den Kunden.

Eine Herausforderung bei der praktischen Umsetzung ist es, die passende Einheit zu finden, mit der Kosten und Nutzen zueinander in Beziehung gesetzt werden. Ebenso erfordert die Umsetzung den Willen aller, diese Idee in die Verträge einfließen zu lassen.

Wo liegt in Ihrem Projekt dieser Punkt?  Arbeiten Sie links oder schon rechts dieses Punktes?

Kommentare 0

Haben wir im Projektmanagement seit F. W. Taylor vor 100 Jahren wirklich alles Falsch gemacht – Ist Agilität die Antwort?

Kann ein plan-orientiertes Projektmanagement unter bestimmten Umständen mein modernes Unternehmen wettbewerbsfähig halten?

In den Produktionsstraßen der großen Automobilhersteller läuft ein ausgetüftelter Ablauf von einzelnen Arbeitsschritten an verschiedenen Stationen des Produktionsbandes. Die Handgriffe der Mitarbeiter und die Arbeitsschritte der Roboter sind bis auf Sekunden optimiert. Da nicht nur ein Fahrzeug in der einen Ausstattung über das Band läuft gibt es viele Varianten, Sonderfälle und Bedingungen. Der Plan ist aufwendig zu erstellen und bei Änderungen an den Parametern muss kostenintensiv ein neuer Plan erstellt werden. Das Vorhaben ist dennoch wirtschaftlich.

Ein Projekt wurde bisher auch als ein solches komplexes Gebilde gesehen, das optimiert werden musste. Wenn die Parameter stabil bleiben, ist diese Art der Durchführung optimal.  Es kann auf geringste Produktionszeit oder minimale Personalkosten, minimale Überkopfarbeiten oder einem Mix daraus optimiert werden.

Die Abarbeitung dieses optimalen Plans erfordert es, dass sich alle Beteiligten an die Absprachen halten. Entscheidungen vorhersagbar und wiederholbar getroffen werden – es also Sicherheit gibt. Wenn diese Kriterien mit hohem Maße zutreffen, ist das Vorhaben planbar und das Optimum der Abfolge von Arbeitsschritten kann mathematisch optimiert werden.

Je nach Umfeld bietet es sich an, eine den Bedingungen entsprechende Methodik zur Umsetzung des Projekts zu wählen. Kann ich auf optimale Kosten und Zeit mathematisch exakt planen oder sollte ich besser ein flexibleres Modell nutzen?

Ralph D. Stacey ist Professor für Management an der Hertfordshire Business School und hat dazu ein Modell, die „Stacy Matrix“ publiziert. Das ist eine Hilfestellung zur Auswahl der passenden Projektmanagementmethode.

Je mehr Sicherheit über das Lieferergebnis „Was vorhanden ist und je mehr Sicherheit bei der Frage nach dem „Wie“ existiert, umso sicherer können wir uns auf einen optimierten Plan verlassen. Dieser muss dann auch nicht ständig verändert werden – es bleibt das „Wie“ und das „Was“ konstant.

Im Scrum Framework definiert das Projekt-Team zusammen mit dem Kundenvertreter (Product Owner) für eine kurze Zeit diesen Umfang fix (Sprint Backlog). Es werden keine Änderungen daran zugelassen. Jetzt kann das Team die Arbeiten an diesem kleinen Teil optimieren. Änderungen beziehen sich immer auf den Product Backlog – aber nie auf den Sprint.  Das Scrum Team arbeitet somit also immer in linken unteren Teil (simple) der Stacy Matrix.

Quelle: https://www.linkedin.com/pulse/complexity-why-your-software-project-needs-scrum-christiaan-verwijs/

Darstellung von Christiaan Verwijs

Eine Produktionsstraße der Automobilhersteller ist kompliziert. Viele Einzelteile müssen sich zum Ganzen fügen – aber das ist vorhersagbar. Allerdings kommt jetzt der Faktor Mensch dazu. Der Mensch ist nicht vorhersagbar. Jedes System das den Mensch mit einschließt, ist damit auch nicht mehr vorhersagbar. Reicht die Stabilität der zwei Achsen mit diesen Projekt­beteiligten nun für mein Projekt aus, um das Modell links unten „Simple“ zu wählen?

Unser Irrtum in den letzten Jahrzehnten war dabei nur, dass die Projektleiter, Kunden, Einkaufsabteilungen und letztlich die Unternehmensvertreter davon ausgegangen sind, dass der Bereich links unten im Stacy Diagramm wirklich für ein ganzes Projekt existiert.

Automobilhersteller gehen vom großen detailreichem Plan weg. Audi setzt auf flexible Produktionsinseln und Daimler auf eine Schwarmorganisation. Diese Unternehmen haben erkannt, dass der Kunde mit seinen wechselnden Anforderungen Teil des Systems ist. So gut mein Plan heute auch ist – morgen muss ich mit meiner komplizierten Produktion, flexibel auf neue Informationen und neue Prioritäten reagieren können.

Reine Plan getriebene Projektmanagement Modelle haben hier einen Nachteil gegenüber hybriden oder rein agilen Modellen. Sowohl in der Produktion als auch in Softwareprojekten müssen wir die komplizierten großen Vorhaben in solche Teile schneiden, die in die linke untere Ecke „hineinpassen“. Zwischen diesen Teilen gibt es dann Platz mit der Komplexität umzugehen. Antworten auf Umgang mit Komplexität hat z.B. Niels Pfläging in seinem Buch Komplexithoden  gegeben.

Danke für das Review des Posts an Matthias Kupka