Archiv der Kategorie: CIO Topics

Product Owner optimiert eure Engpässe

Das ist Teil 2 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

flask-304943_1280Wenn wir Software entwickeln, dann erstellen wir – wenn auch virtuell – ein Produkt. Produktentwicklung respektive der dafür eingesetzte Prozess wird immer einen oder mehrere Engpässe haben. Besonders Lean Management bzw. das darauf basierende Kanban zielen auf die Optimierung solcher Durchsatzprobleme ab (vgl. Theory of Constraints).

An allen Softwareprodukten, an denen ich mitentwickelt habe, war ein Engpass im Bereich der Entwicklung. Ideen und Wünsche haben die Kunden, Projektmanager und Product Owner viele. Natürlich können sie diese schneller formulieren als die Entwickler sie implementieren können.

Deshalb ist es wichtig genau diesen Abschnitt des Entwicklungsprozesses optimal auszulasten. Alternativ könnte der Engpass durch massive Aufstockung der Mitarbeiter vollständig aufgelöst werden, aber das ist allein aus Kostengründen unrealistisch.

 

Vorbereitung ist alles

Deshalb gilt: Je besser die Vorarbeitet ist, d.h. Wunsch-Features durchdacht, formuliert und präpariert werden, desto weniger Zeit muss der Entwickler dafür aufwenden. Unternehmen sprechen typischerweise auch vom Anforderungsmanagement. In einem späteren Beitrag werde ich die Einzelschritte und die Rollen in einem Softwareentwicklungsprozess beleuchten. Es gilt das Gleiche wie beim Essen: Je besser die Nahrung im Mund vorgekaut wird, desto einfach kann der Magen sie verdauen. Das heißt nicht, dass nicht weiter der Entwickler einbezogen werden soll oder dass weniger miteinander geredet werden soll, aber meiner Erfahrung nach werden immer wieder wenig durchdachte Anwendungsszenarien den Entwicklern über den Zaun geworfen. Im Sinne von “die werden dann schon mal machen”. Wird dann seitens der Entwickler nachgefragt, wundert sich der fachliche Verantwortliche gerne mal “was denn daran nicht klar sei”. In dem Zuge sei auf die Wichtigkeit einer gemeinsamen Sprache hingewiesen. Wie gesagt ist die Kommunikation wichtig und die Fachexperten können nicht an alles denken. Manches wissen sie auch nicht. Viele Probleme können aber im Vorfeld durchaus vermieden werden. Statt nach Lösungen zu suchen, kann es oft sinnvoller sein die tatsächliche Ursache des Problems zu untersuchen. Wo genau funktioniert der Geschäftsprozess nicht?

 

Evolvierbarkeit

Darüber hinaus muss jedem Produktverantwortlichen klar sein, dass eine Änderung nachweislich teurer wird, je später selbige erfolgt. Das betrifft die sogenannte Evolvierbarkeit. Obwohl Software nicht wie ein Auto verschleißt oder für Änderungen physikalisch auseinander gebaut werden muss, kosten späte Korrekturen mehr als frühe.

 

Schnelles Feedback

Bei Scrum und Kanban macht es sich ebenfalls bemerkbar, wie schnell erledigte User Stories vom Product Owner abgenommen werden. Ich habe für die Projekte, in denen ich Scrum Master bin, mit dem PO vereinbart, dass spätestens am Vormittag des Folgetages das Feedback kommen muss, ob die User Story korrekt umgesetzt wurde. Mir ist unter anderem von Microsoft bekannt, die nach einer Einführung einer 4-Stunden-Abnahmefrist der Durchsatz der tatsächlich abgeschlossenen Aufgaben signifikant gesteigert wurde.

 

Leerlauf vermeiden

Zu guter Letzt gibt es noch den Fall, dass die Arbeit so gut läuft, dass neue Wünsche schneller umgesetzt werden können als erwartet. Dann sollten die nächsten ToDos vorbereitet sein, damit die Software Ingenieure nicht Leerlauf haben.

 

Fazit

Der Entwicklungsprozess sollte auf die Engpässe zugeschnitten sein. Häufig ist das die Entwicklung. Diesem Engpass muss sich der Rest des Prozesses unterordnen. Das Prinzip ist seit langem bekannt, wissenschaftlich belegt und kann eine erhebliche Beschleunigung der Produktentwicklung bewirken.

Advertisements

Product Owner lasst eure Entwickler den Tunnel

Das ist Teil 1 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

 

Ideal zeigt der Firm ‘The Social Network’ welche Umgebung Entwickler benötigen: Den sogenannten “Tunnel”.

 

Gemeint ist damit die Möglichkeit konzentriert ohne Unterbrechung an dem (Software-)Produkt arbeiten zu können. Wenngleich agile Methoden wie Scrum und Kanban sehr stark Interaktion und Kommunikation (vgl. Agiles Manifest) fördern, fällt mir immer wieder auf, dass zwar nicht insgesamt zu viel, dafür aber zu häufig miteinander gesprochen wird. Statt dedizierte Gesprächstermine zu nutzen, ruft der Product Owner teilweise mehrfach am Tag den Entwicklern an, um sich z.B. Feedback zu Ideen oder neuen User Stories zu holen.

Das wirkt dann natürlich sehr flexibel im Sinne von frei von Bürokratie und klingt auf Anhieb sehr “kommunikativ”, jedoch sehe ich auch die Nachteile, die nach meiner Ansicht stark überwiegen: Der Entwickler wird kontinuierlich aus dem Tunnel gerissen. Gerade in kleinen und mittelständischen Unternehmen (KMUs) ist die Begründung die, dass genau die statischen Reglements von Konzernen vermieden werden wollen oder aber dass ohnehin nur wenige Entwickler zur Verfügung stehen, um den PO gedanklich zu unterstützen. Das sind alles nachvollziehbare Gründe, jedoch spricht aus meiner Sicht nichts dagegen zu sagen: Wir reservieren täglich von 16.30-17 Uhr dediziert Zeit für den Product Owner und seine Fragen weg. In Scrum gibt es sogar ein dediziertes Meeting während der Iteration dafür: Das Backlog Grooming. Dieses kann im Übrigen auch mehrfach während eines Sprints angesetzt werden.

Wie viel Zeit kleine Ablenkungen kosten, belegen neben Studien (von denen ich an dieser Stelle keine heraussuchen will) auch die eigenen Erfahrungen. E-Mail Eingang, Messenger Nachricht oder nur schnell im Internet was nachgeschaut und schon ist man aus dem Fokus und dem Gedankengang draußen. Das ist unabhängig vom Entwicklerberuf, das ist einfach menschlich. Je nachdem welche Studie gerade wieder veröffentlicht wird, lese ich Zeitangaben zw. 10 und 30 Minuten, die benötigt werden, um wieder an der gleichen Stelle mit der gleichen Konzentration weiterzuarbeiten.

Der geneigte Product Owner kann das einfach nachvollziehen, indem er sich an seine Schulzeit erinnert. Wenn er als Schüler eine mathematische Aufgabe rechnen muss, deren Lösung durch verschiedene Rechenschritte und Umformungen sich auf über 2 DIN A4 Seiten erstreckt und er Mitten drin von einem Mitschüler 5 Minuten mit einem völlig anderen Thema abgelenkt wird, dann muss er nach dem Gespräch erst nochmal seinen Gedankengang verfolgen, um die Rechnung weiterführen zu können.

Schlanke Prozesse sind gute Prozesse oder warum wir Kanban einführen

In unserer IT Administration führen wir regelmäßige Retrospektiven durch. Das ermöglichte es uns Kategorien von Problem zu identifizieren, wie sie auf dem Bild zu sehen sind.

2015-03-04 18.36.43

  • Weniger wichtige Aufgaben wurden zuerst erledigt (Priorisierung)
  • Vermeintlich kurze Projekte haben sich stark in die Länge gezogen
  • Aufgaben wurden nicht vollständig erledigt
  • Zuständigkeiten / Ansprechpartner waren nicht klar
  • Aktuelle Projektstände waren nicht transparent
  • Aufgaben blieben bei Externen hängen bzw. blockierten uns
  • Engpässe / Verzögerungen machten uns das Leben schwer
  • Planung war schwierig
  • Häufiges “auf einen Stand bringen” und mehrfaches Besprechen gleicher Punkte

Die Systemadministration ist von Natur aus ein stark vom Tagesgeschäft abhängiges Umfeld mit viel Klein-Klein-Arbeit. Der Anwender ruft an, meldet PC Probleme (Spezifisches hört man selten), der Kollege unterbricht seine eigentliche Tätigkeit wie z.B. die Vorbereitung einer größeren Umstellung und kümmert sich um die Nöten des besorgten Anrufers. Kaum zurück und wieder in die Umstellung vertieft, kommt eine E-Mail, dass die Druckertoner leer sind. Erneut gilt es die aktuelle Arbeit zu unterbrechen.

Darüber hinaus laufen natürlich immer Projekte mit anderen Abteilungen oder Externen (Telekommunikationsanbieter, Dienstleister, etc.), die voran getrieben werden müssen. Selbst der Entwickler-Kollege aus der selben Abteilung ruft an und möchte einen neuen Testserver aufgesetzt bekommen – am besten vorgestern versteht sich.

Kurzum: Ein reges Tagesgeschäft parallel zu großen Projekten und das alles im Umfeld von unterschiedlichen Stakeholdern. So wie es auch in Marketingabteilungen oder Zentralen der Fall ist.

Nüchtern betrachtet handelt es sich um eine Warteschlangensystem. Da Menschen nicht gut darin sind viele Dinge parallel zu machen, vermuten wir hierin eine der Ursachen: Zu viele Dinge werden gleichzeitig erledigt. Außerdem stehen wir Dritten skeptisch gegenüber, welche uns rein gefühlsmäßig ausbremsen. Bei den Telekommunikationsanbietern können wir indes von einer Tatsache sprechen…Darüber hinaus meinen wir diverse weitere Hindernisse erkannt zu haben, die den Arbeitsfluss immer wieder stören.

Um weil wir uns gerne verbessern möchten, eine zu große Umstellung auf einmal eher scheuen und der Evidenz der Vermutung den Vortritt geben möchten, haben wir uns entschieden Kanban einzuführen. Auf einen Nenner gebracht liegen dem 3 Prinzipien und 5 Praktiken zu Grunde.

Prinzipien:

  • Starte mit dem, was du jetzt machst
  • Verfolge inkrementelle, evolutionäre Veränderungen
  • Respektiere initiale Prozesse, Rollen, Verantwortlichkeiten und Job-Titel

Praktiken:

  • Mache Arbeit sichtbar
  • Limitiere den WIP
  • Manage den Arbeitsfluss
  • Mach Prozess-Regeln explizit
  • Führe gemeinschaftliche Verbesserungen durch (basierend auf Modellen)

Alle Regeln werden penibel eingehalten, jedoch ist die erste Regel alle Regeln abzuschaffen, die nicht mehr funktionieren.

Über die ersten Ergebnisse werde ich demnächst berichten. Falls jemand schon gute Erfahrungen primär im Administrationsumfeld gemacht hat, dann würde ich mich über Input freuen. Gerne auch aus der Softwareentwicklung.

Es gibt keine passive Kaizen-Kultur

Es braucht keine Retrospektiven und dedizierte Kaizen Phasen; schließlich hat das vorher auch alles geklappt und die Verbesserungen haben sich genauso eingestellt.

Aussagen wie diese hört jeder Change Agent früher oder später. Ich will gar nicht abstreiten, dass in jedem Unternehmen mehr oder weniger kontinuierlich optimiert wird. Jedoch geht durch das passive Verhalten viel Potential verloren. Das kann jeder ganz einfach kontrollieren. Der geneigte Leser soll dazu für einen kurzen Zeitraum – beispielsweise 2 Monate – jede Idee protokollieren, welche von Kollegen mit “das müssen wir mal machen” oder “das sollten wir demnächst angehen” kommentiert wird. Im Anschluss ist zu prüfen, was tatsächlich umgesetzt wurde. Ich wäre überrascht, wenn bereits 5% fertig sind. Wohlgemerkt fertig umgesetzt, nicht nur angefangen und wieder liegen gelassen. Ganz im Sinne von stop starting, start finishing. Bereits die Definition von Kaizen drückt das aus:

“Kaizen […] bezeichnet ein methodisches Konzept, in deren Zentrum das Streben nach kontinuierlicher und unendlicher Verbesserung steht.”Wikipedia

Es handelt sich um ein methodisches Konzept. Eine Methode ist ein systematisches Verfahren. Laissez faire im Kontext von Verbesserungen kann aber nicht systematisch sein. Passive Kaizen-Kultur ist also ein Widerspruch.

Ein klarer Indikator für ungenutztes Potential, ist das wiederholte Auftreten des gleichen Problems. Der erste Gedanke, der einem dann kommt, ist: Mist, das wollten wir doch mal machen (siehe Aussage oben). Das können häufig kleine Dinge wie eine fehlende Fahrzeugpoolverwaltung oder eine Verwaltung für die ohnehin nicht gerade reichlichen Besprechungsräume sein. Aber auch komplexere Themen wie die hohe Informationsflut im Zeitalter der Wissensarbeit. Schon mal über eine SharePoint Dokumentenbibliothek oder ein Wikisystem nachgedacht? Und wenn ja, auch realisiert?

Unabhängig von den Implementations-Phasen solcher Ideen/Lösungen, gehören zu einer soliden Kaizen-Kultur auch Retrospektiven. Selbstverständlich werden hier wieder Stimmen laut, die behaupten, dass ich mir doch keine Zeit reservieren muss, in welcher ich reflektiere und nach Verbesserungsmöglichkeiten suche. Das ist leider eine ähnliche Floskel wie:

Wir brauchen keine Mitarbeitergespräche. Wir reden regelmäßig miteinander.

Wer sich aber mit den Themen intensiv beschäftigt und ganz darauf einlässt, stellt einen großen Unterschied fest. Persönlich habe ich sogar den Eindruck, dass durch kurze, oberflächliche Problemanalyse Lösungen entwickelt werden, die das Symptom kaschieren, nicht aber aber die Ursache beheben. Als Change Agent hat sich in dem Fall die sokratische Methode bewährt. Stelle solange W-Fragen (Warum, Wer, Was) bis – wie Goethe sagt – des Pudels Kern gefunden ist.

Der Leser kann sich dazu kurz in Erinnerung rufen wie es bei der Zulassungsstelle bei einer Ummeldung abläuft. An dem einen Schalter beantragt man die Anmeldung. Mit dem Papier geht man an den Schalter neben an. Natürlich muss dort wieder angestanden werden. Nach einer meist längeren Wartezeit wird dort das alte Schild vernichtet und das neue ausgegeben. Damit läuft man wieder an den ersten Schalter und nach noch längerer Wartezeit erhält man dann endlich die Papiere.

Wenn ich jetzt danach frage, wie sich der Prozess optimieren lässt, dann kommt ohne lange Überlegung die Antwort: Na indem am Schalter schneller gearbeitet oder mehr Personal eingestellt wird. Überstunden wären ebenfalls möglich. Das sind zwar alles Optionen, allerdings lange nicht die besten, da diese nur sehr beschränkt skalieren und teuer sind. Vielleicht ist das der Grund, warum bis heute die meisten Kfz Halter sich einen halben Tag Urlaub für das Ummelden nehmen müssen. Eine mathematisch nachweislich bessere Antwort gibt es hier.

Fazit

Keine Frage: Es braucht kleine, kontinuierliche Verbesserungen, damit die Unternehmen diese verdauen können. Evolution statt Revolution (manchmal auch letzteres!). Aber Evolution im Schneckentempo gleicht eher einem Rückschritt, weil die anderen schneller voran kommen. Wer jeden Tag 30 Minuten ins Fitnessstudio geht und sonntags ruht, hat am Ende der Woche auch 3 Stunden trainiert. Und genauso wie Trainings als feste Termine eingeplant werden müssen, bedarf es auch fester Zeiten für Retrospektiven und die Umsetzung der daraus resultierenden Ergebnisse.

Und wenn der Leser immer noch motiviert ist, dann kann er gerne einen Kommentar hinterlassen, ob in seinem Unternehmen bereits Kaizen an der Tagesordnung ist oder nicht und warum respektive warum nicht.

Aus der Praxis – Wie sich unser Unternehmen durch Social Media verändert hat

Social Media ist nur ein Trend

Ich bin vor einigen Monaten aus unserer Social Media Gruppe (meine früheren Berichte zu unserer Arbeit) ausgetreten. Nicht weil ich darin keinen Sinn mehr gesehen oder weil ich nichts mehr hätte beisteuern können. Vielmehr liegen meine Stärken mehr darin Ideen zu entwickeln und einzuführen, als diese bis zum Schluss zu begleiten. Schluss bedeutet hierbei bis die letzten Kollegen „überzeugt“ wurden. Die Autorinnen Rising Linda und Mary Lynn sprechen in ihrem tollen Buch Fearless Change von sogenannten “Innovators” und “Early Adopters”  (einen Einführungs-Podcast dazu gibt es hier). Mit Laggers werden übrigens Persönlichkeitstypen bezeichnet, die nicht zu überzeugen sind. Dazwischen reihen sich die Early Majority und Late Majority ein.

Nachdem vor kurzem die Gruppe überein kam sich aufzulösen, sprach mich eine Kollegin an. Sie ist der Meinung, dass viele Ideen respektive Ansätze dabei sind, bei denen es sich lohnt diese weiterzuführen. Zum Beispiel unsere Textwerkstätten. Sie wollte wissen, wie ich über die Entscheidung denke und ob ich einen Vorschlag hätte, um die Gruppe neu auszurichten. Vor allem da sich die bisherigen Ergebnisse sehen lassen konnten und sie die Art der interdisziplinären Kollaboration im Vergleich zur (homogenen) Abteilungsarbeit spannend fand.

Nun wird der ein oder andere Leser vermutlich denken: Das war doch klar. Social Media und Unternehmen passen nicht zusammen. Das ist ein vorübergehender Trend, den jeder früher oder später abhaken muss!

Halte an deinen Zielen fest, bleibe dabei aber flexibel

Mein Sicht darauf war dann doch eine andere, was ich meiner Kollegin wie folgt erklärt habe: Das Ende der Social Media Gruppe ist lediglich dem Namen und der Beschränkung auf eine festgelegte Personengruppe geschuldet. Die Idee dahinter hat längst bei uns Wurzeln geschlagen. Denn inzwischen machen wir unternehmensweite Open Spaces, bei denen die “Lehrer” und “Schüler” Rollen kontinuierlich wechseln und die Agenda von allen Mitarbeitern mitbestimmt wird. Am Vormittag erzählt noch der Kollege aus Berlin umfassend über ein neues Produkt und die Kollegin aus Nürnberg hört zu, am Nachmittag werden die Rollen getauscht und die Kollegin referiert über Werkstoffe und deren Einsatzszenarien.

Die Meetings unserer Marketing- & Einkaufs-Abteilung sind inzwischen für alle geöffnet. Durch gezielte Einladungen abteilungsfremder Kollegen soll das gefördert werden. Themen- und Projektvorschläge werden in den Wochen zuvor von allen Mitarbeitern im Wiki zusammengetragen. Jedem „Stakeholder“ ist freigestellt Input zu liefern.

Ein weiteres Beispiel ist unser Arbeitsplatztausch, bei dem jeder Mitarbeiter mindestens 1x jährlich in eine andere Abteilung wechselt, um über den eigenen Tellerrand hinaus zu schauen. Und natürlich schreibt der Kollege seinen Erfahrungsbericht in unseren Corporate Blog. Stephan ist übrigens kein Mitglied der Social Media Gruppe! Damit ist er einer von vielen, die bereits gebloggt haben.

Mir fallen auf Anhieb noch viele weitere Ausprägungen ein, doch unser Erfolg zeigt sich meiner Meinung nach am besten darin, dass ich kürzlich beim Vorbeigehen nicht umhin kam zu hören, wie der Einkaufsleiter in Nöttingen am Telefon einer Kollegin aus Frankfurt wie selbstverständlich mitteilte: “Das kannst du alles im Wiki nachlesen und dann ggf. ergänzen”. Dass der Einkaufsleiter noch ein paar Wochen zuvor seine Mitarbeiterin – selbige ist Teil der Social Media Gruppe und daher bestens geschult im Umgang mit dem Wiki – gefragt hat wie der Inhalt einzupflegen ist, brachte mich dann doch zum Schmunzeln. Mit einem Video zur Integration der Wiki-Inhalte in unser Warenwirtschaftssystem habe ich die Vernetzung bei uns bereits illustriert.

Neben einigen weiteren Beispielen wies ich meine Kollegin noch darauf hin, dass sie selbst erst kürzlich gegenüber dem Vorgesetzten den Wunsch geäußert hat in ihrer Abteilung regelmäßige Retrospektiven zur Verbesserung der Prozesse umzusetzen. Ebenfalls ein Ansatz, den wir bei der Social Media Gruppe einsetzten.

tree-200795_1280

Quelle: http://pixabay.com/de/baum-struktur-netzwerke-internet-200795/

Fazit:

Nur diejenigen, die Social Media nicht auf Werkzeuge wie Facebook und Twitter reduzieren, sondern die Ansätze und Gedanken dahinter verstehen, können das der Sache inhärente Potential nutzen. Die Schulungs-Agenda sollte eben nicht mehr nur vom Abteilungsleiter definiert oder Geschäftsprozesse durch die Geschäftsleitung festgelegt werden. Stattdessen muss sich eine Kultur etablieren, bei der die Fähigkeiten aller genutzt werden und das Wissen der Masse kontinuierlich geteilt wird. Dadurch entsteht eine Lernkultur, bei der Informationen nach Belieben beigesteuert und herausgezogen werden können. Social Media ist insofern auch keine neue Idee, jedoch sind inzwischen viele digitale – teils populäre, teils weniger bekannte – Werkzeuge auf dem Markt. Mit dem inzwischen signifikanten und noch weiter steigenden Anteil der sogenannten Wissensarbeit ist nicht mehr die Frage, ob man auf den Zug aufspringen sollte. Die Herausforderung liegt darin die passenden Werkzeuge zu evaluieren und eine entsprechende Unternehmenskultur zu etablieren. Denn wer nicht mit der Zeit geht, geht mit der Zeit.

Wie stehts bei euch um Change Management, Social Media und Innovationen? Welche Werkzeuge nutzt ihr? Seid ihr schon auf einem guten Weg oder springt ihr gar nicht auf den Zug auf?

Programmieren – aber bitte nur von 8-17 Uhr

Zu meinem letzten Blogbeitrag Was ist denn bitte ein C# Experte gab es auf Twitter noch eine Diskussion darüber, ob der Job eines Entwicklers ein 8-17 Uhr Beruf ist. Dieser Beitrag soll eher dem Gespräch dienen, weil Twitter dazu nicht geeignet ist. Ich kann mir vorstellen, dass es hierzu bei 5 Personen 6 Meinungen geben wird. Konsequenterweise wird es deshalb in Betrieben auch häufig zu Problemen kommen, wenn völlig unterschiedliche Meinungen und Ansätze herrschen. Ich sage dazu:

Entwickeln ist keine 8-17 Uhr Tätigkeit.

Was ich aber damit meine: Es sollte keine feste Grenzen geben, da ich als Entwickler nicht auf Knopfdruck kreativ sein kann. Ein Maler kann genauso wenig immer von Montags bis Freitags von 8-17 Uhr Bilder kreieren. Ich treffe damit keinerlei Aussage darüber, ob mehr als 8 Stunden gearbeitet werden sollen. Oder weniger. Vielmehr glaube ich:

Nur Ergebnisse sind entscheidend, nicht die aufgebrachte Zeit

In dem Sinne: Work smart, not hard. Ich bin auf eure Meinungen gespannt!

Tipps zum Customer Relationship Management in kleinen und mittleren Unternehmen

Mit folgendem Webcast möchte ich kleine und mittlere Unternehmen (KMU) einen groben Überblick geben, was es bei der Auswahl von Customer Relationship Management (CRM) Systemen zu beachten gilt. In 20 Minuten mache ich eine kurze Analyse und erkläre den unterschied von funktionalen und nicht-funktionalen Anforderungen. Dabei ist es wichtig zu wissen, dass die nicht-funktionalen zwar nicht sichtbar sind, aber durchaus teuer werden können. Am Schluss nenne ich dann einige Produkte, die sich primär in interne und externe Lösungen (Stichwort Cloud) kategorisieren lassen. Bei der Auswahl wird dann der Rückschluss auf die Anforderungsanalyse gezogen.

 

Hier geht es zum Video. Wer sich fragt, welches Programm ich zur Aufbereitung verwende. Es handelt sich um den MindManager der Firma MindJet.

CRM

Hier sind noch weiterführende Informationen:

%d Bloggern gefällt das: