Personalverantwortung ist genau so groß, wie es sich anhört!

Ich erfahre täglich, wie schwierig eine Zusammenarbeit mit Menschen wird, wenn einer der Personen sich über seine Verantwortung nicht komplett bewußt ist.

Bei Vorgesetzten, man sagt eigentlich deutlich Personalverantwortlichen, ist es so, dass Sie für die, die Ihnen anvertraut sind, verantwortlich sind. Ich mache gerade die Erfahrung, dass es hier schwierig wird, wenn dieser Personalverantwortliche dem selbstorganisierten Team beginnt auf die Idee zu kommen, hier Verantwortung an sein Team abgeben zu wollen. Das ist dann ungefähr so: Karl-Heinz Rummenige sagt: „Liebe Bayern-Mannschaft, ab Morgen bestimmt Ihr, wer in der Mannschaft mitspielt!“ Was würde passieren. Ich glaube, Schalke hätte große Chancen, Meister zu werden. Die Bayern haben dann nämlich ein anderes Problem.

Eigentlich möchte die „dienende Führung“ ja in dieser auf Augenhöhe und Agilität getrimmten Welt Verantwortung ans Team abgeben. Aber ist es wirklich gut, mit der Personalverantwortung anzufangen? Reicht nicht, erst einmal mit der Verantwortung für den Erfolg der Arbeit des Teams, bevor man das Allerheiligste des Personalverantwortlichen preisgibt. Man müsste ja auch das Salär des Personalverantwortlichen dem Team geben, oder?

„Tasso“ Anastasios Psarros, Rob van Lanen und Rini van Solingen sagen in „Scrum für Manager“ den Managern: „Sie sollen überdurchschnittlichen Mitarbeitern helfen, sich weiterzuentwickeln und Sie sollten unterdurchschnittlichen Mitarbeitern helfen, besser zu werden oder diese entlassen.“

Das erklärt in einem Satz Personalverantwortung in der heutigen Zeit. Eigentlich einfach.

Boris Grundl und Bodo Schäfer sagen in „Leading Simple“: „Wenn du jemanden nicht führen kannst, dann musst du dich trennen.“ In dem Satz steckt die komplette Macht dieser Verantwortung für Personal. Trennen heißt bei Bayern-Spielern verkaufen. Dabei wird keiner wirklich arm. In der alltäglichen Arbeitswelt heißt trennen oft, auf Dauer die Existenzgrundlage entziehen. Diese Verantwortung an seine Mitarbeiter im Team abgeben ist verlockend aber verantwortungslos.

Erst wenn das Team für alle, auch seine Personalverantwortlichen, verantwortlich wird, könnte daraus ein Schuh werden. Ich persönlich mag an der Stelle aber noch den Unternehmer, den Chef, den Visionär, der die Richtung vorgibt UND dafür die Verantwortung übernimmt.

Die Verantwortung ans Team zu übergeben, sorgt auf Dauer für ein Hauen und Stechen.

Ihr glaubt das nicht? Das glaube das für Euch mit! 😉

Klick auf,

Jörg

Große, teure Features einschätzen und seinlassen ODER kleine, günstige, Versuche und machen

Schätzt bitte, was dieses Feature kostet?

Am Nachmittag darf ich an einem Meeting teilnehmen. Die Produktmanager und das ideale Scrumteam treffen sich zu einer ersten Einschätzung für ein Feature. Weil ein Kollege und ich Dienstleistungen rund um ähnliche Programmfeatures anbieten, dürfen wir teilnehmen.

Die Produktmanager meinen, dass das Feature doch gar nicht so kompliziert sei. Auf einige goldene Henkel und Schnörkel kann ja sogar verzichtet werden.

Das Scrumteam macht klar, dass auch ein einfaches Feature durch automatisierte Tests dauerhaft qualitätsgesichert sein muss. Generell ist die Umsetzung aber machbar.

Diese und viele andere Argumente werden ausgetauscht. Richtiges, uneingeschränktes, Vertrauen in die beiderseitigen Argumente spüre ich nicht.

Das Team schätzt: Es dauert nur 2 bis 3 Sprints, bis das Feature in der Minimallösung umgesetzt ist… leider schon zu teuer. Und im Backlog des Scrumteams schafft es das Feature dann doch sicher nicht so weit nach oben. Verschenkte Zeit.

Dieses Meeting hat das beiderseitige Vertrauen und den Respekt meiner Meinung nach nicht gestärkt. Ich gehe enttäuscht mit meinem Kollegen aus dem Meeting zurück zu meinen Dienstleistungen. Heute ist früh Feierabend…

Linda Rising schlägt vor: Schnelle, kleine, günstige Versuche machen

In den Zug nach Düsseldorf. LEAN_DUS mit Vortrag von Linda Rising. Gastgeber für die Veranstaltung ist sipgate . Wie immer dort, macht sich die firmeneigene Küche sehr viel Mühe, die Veranstaltungsteilnehmer mit kleinen, leckeren Happen zu verwöhnen. Kleine, leckere Happen zum Probieren… das passt schon zum Vortragsthema.

Nachdem 5 sipgate-Mitarbeiter gemeinsam 10 Experimente vorstellen, die es vom Versuch in den Firmenalltag geschafft haben (z.B. Retrospektiven, Pairing, Peer-Feedback, OPEN-Friday, Link zum Vortrag folgt, wenn er zur Verfügung steht) beginnt diese bemerkenswerte, ältere Dame aus den Staaten mit dem Vortrag. Wie in den hervorragenden Videos im Netz.

Linda Rising erklärt, dass es eigentlich keine Experimente sind, die wir bei der Softwareentwicklung machen (experiments), sondern Versuche (trials or tinker). Wissenschaftliche Experimente würden Probe, Gegenprobe, viele Wiederholungen, viel Dokumentation und Aufzeichnung und das saubere erheben von Daten bedeuten. Dafür ist in unserem Geschäft tatsächlich aber kein Geld da. Stattdessen probieren wir etwas aus: „Lass uns ausprobieren, ob wir mit Pairprogramming weiterkommen?“ Wenn der Versuch erfolgreich ist, macht man weiter und versucht weitere kleine Schritte. Wenn nicht, läßt man es sein.

Es ist viel mehr, als der letzte zusammenfassende Abschnitt: Linda nimmt mich eine Stunde lang mit, erzählt Geschichten, macht Witze, erklärt Denkfehler, gibt Buchtipps. Weil Sie so gut ist im Vortrag, fällt es mir nicht schwer, dem englischen Vortrag zu folgen (Sobald der Vortrag im Internet zur Verfügung steht, verlinke ich hier)

Fazit des Vortrages ist folgendes Vorgehensmuster (Linda ist Profi für Patterns): Kleine, schnelle, und günstige Versuche. Wenn es funktioniert: gut. Wenn es scheitert: egal.

Wenn wir in unseren Sprint-Planungen so kleine Versuche ausprobieren, dass wir nach jedem Sprint Erfolg oder Misserfolg erkennen können, arbeiten wir genau nach diesem Muster.

Kleine, schnelle und günstige Versuche machen und iterativ in die richtige Richtung fortbewegen ist besser als große, teure Features einschätzen und dann sein lassen.

Vielleicht kann ich das Pattern von Linda, schnelle, kleine, günstige Iterationen – das einfache, aber grundlegende Prinzip von agiler Softwareentwicklung – wieder zurück in die Gedanken der Kollegen bringen.

Danke, Linda! Danke, sipgate! Danke LEAN_DUS!