Sorry, this entry is only available in Deutsch.

Sorry, this entry is only available in Deutsch.

Manage & More, Mentor & Mentee, Motivation and the Motivation Bosom

04.11.08

For half a year, I have been allowed to participate in Manage&More, an activity of unternehmerTUM. My official role is that of a mentor, and a mentee has been assigned to me. Until recently, I never even knew what a mentee was, but now I am a mentee myself, namely in wikipedia. But that is another story.

My mentee’s name is Michael, which incidentally fits perfectly with the headline of this article. Michael is a nice and authentic guy. In former times, I would have characterized him as “a guy you can steal horses with”. We meet every 4-6 weeks and discuss a pre-defined topic. Sometimes one of us reports while the other responds, sometimes the roles are reversed. In this way, we learn a lot from each other. In preparation for our last meeting, Michael sent me an email saying: “Let us talk about motivation!?” That was a topic I found quite attractive. After all, I myself often wonder about the state of my motivation in general and in particular why there are some topics I find it hard to motivate myself for. I prepared for our meeting by - as almost always - looking it up in wikipedia, where I found quite a bit about motivation. When printed it totalled 13 pages and there was hardly anything wrong or really unimportant.

Michael wanted to talk motivation with me because there had been a feedback discussion where some of his peers had criticized him for sometimes clearly showing his lack of motivation for certain topics. This failure, so he was told, de-motivates others. And like all upright people, the first thing he did was to consider himself guilty. But pretending is not his style at all.

The interesting question was: what to do if you have to take part in a discussion about something that seems totally senseless to you. I think this occasionally happens to all of us, probably more often in big organisations than in small ones.

Is the answer that you should pretend, hide your lack of interest, speed things up in order to finish the gruesome discussion as fast as possible, so you can get back to more important and pleasanter jobs? Or should you honestly tell the others that you consider the topic irrelevant and that the project would not benefit from your presence, and then leave the discussion with a friendly: “You can discuss this better without me. Call me when you have finished this topic!”?

Here is another idea: you could take on the unloved topic and ask yourself how to make the topic interesting? This would surely result in good material for the discussion, or else would cause you to modify your own point of view.

If, however, you really believe that something is absolute nonsense, then you should have the courage to say so and to suggest an innovative improvement; even if you are resigned to the power of impersonal autonomous systems and you see no chance to improve matters.

As you can see, the problem is not easily solved. I believe that pretending and keeping up appearances is the worst solution.

Subsequently, we talked about Freud’s ID, EGO and SUPER-EGO and that the three should be “centred”. Then we found that we are both (at least) a class better when motivated for a task and that motivation must come from within. When it is externally supported by material gain or agreed targets, it declines amazingly. This is how we came to “intrinsic” and “extrinsic” motivation, both of which are excellently described in wikipedia under motivation.

Then I told Michael about the “motivation bosom”. This concerns how the performance of employees in an enterprise depends on their collective and individual contentment. Imagine a graph with “total contentment” on the left side of the x-axis and “total discontent” on the right side. The y-axis shows the performance. At the extreme right and extreme left, the performance is zero. Coming from the left, the graph rises, i.e. starting with a high degree of contentment, the performance grows with growing discontent. Then it remains on a plateau for some time before declining in a state of general discontent. As the discontent increases even further, the performance again increases, more steeply than before, until it abruptly falls.

Thus, we have a graph with two humps, which accounts for the name. The left hump on the satisfaction side is a little lower than the right, but a lot broader. The right hump on the dissatisfaction side is narrow, with a very steep decline on the right side (almost vertical). The “motivation bosom” theory says that it is better for an enterprise regarding satisfaction/dissatisfaction to be on the first (left) plateau. Unavoidable changes in the level of satisfaction will not immediately result in a big reduction of performance. Conversely, on the thin right hump, even small changes can lead to an abrupt drop in performance, whether on the right side (collapse due to burnout) or on the left (giving up). To me, it seems that there are companies that try to keep their employees on the narrow right plateau of considerable dissatisfaction in order to have a slightly better performance, attempting to prevent the threatening abrupt fall-off by offering extremely high incomes. This could apply particularly to US companies even though the above theory originated in the USA.

Although I remember the literature on “motivation bosom” well, I found it neither in wikipedia, nor in google (at least not in the German versions). What a surprise that it is still possible not to find a popular theory in the internet! Of course, now I am tempted to do some research and write an article for wikipedia, but I am still primarily a managing director and a few weeks ago  an economically difficult time suddenly started! Writing articles and lecturing, and this blog too, are just a hobby of mine, and so are not top priority. If only I had more time… Which reminds me of a popular song (careful - music): Gene Pitney – If I Only Had Time …

RMD mehr »

Sorry, this entry is only available in Deutsch.

Sorry, this entry is only available in Deutsch.

Well it’s always nice to see my own ideas (visualizing the ProductOwner role) being shared with “greater minds”. Jeff Sutherland wrote about “World’s Best Product Owner: Evil Genius Steve Job” in his blog.

short but mine

We are proud to make a special announcement. Here, according to our researches, is the first and only Scrum Poster in the world. It is offered exclusively in the IF-Blog. It cost our team enough hard work, but now the first version is released for free download in English or German.

How this came about:

Our technology scout, Alexander Maisch (known as Axel) told me a year ago that he had searched in vain for a Scrum Poster. So we decided to produce one ourselves. The boys and girls from InterFace, and local universities (TUM and TEG) got down to work. And now we have done it; the first release stage is there.

Here it is, our definative Scrum Poster as a free Download in German and English!

Naturally, we shall continually enhance it and release the latest version for download after every Sprint!

RMD

Sorry, this entry is only available in Deutsch.

2 von X…

Bisher treffen sich unsere Helden einmal täglich um 13:30 Uhr in einem kurzen (15min), knackigen Meeting namens „Boxenstop“.
Der Scrum Master moderiert und nimmt Probleme auf, um deren Beseitigung er sich für das Team kümmert. (nebenbei schreibt er noch immer fleißig mit, damit er seinen Statusbericht voll bekommt *g*)

Zusätzlich dazu gibt es jeden Morgen ein 30 Minuten Meeting zwischen dem Auftraggeber (den wir später noch als Product Owner kennenlernen werden) und mir.

Durch diese Meetings konnte ich Transparenz und Kommunikation erzeugen – und das Vertrauen in mich als ‚Problem-aus-der-Welt-schaffer’ festigen.
Hauptsächlich kümmerte ich mich zu diesem Zeitpunkt wohl um noch nicht beantwortete eMails, ausstehende Termine zur Klärung von diesem und jenem.. Kleinkram eigentlich, der aber bei den Performern Mehraufwendungen erzeugt hat.

In meinen Besprechungen mit dem Auftraggeber habe ich wiederholt interesse an agilmen Projektmanagement erzeugen können – sowie Informationen aus dem Team und die aktuelle Auslastung an Ihn kommuniziert – so dass er besser in der Lage war Zurufe seitens seines Chefs entsprechend fundiert zu würdigen.

Auch kamen wir in diesen Meetings überein, dass wir uns gegen Arbeitslast ‚von Außen’ entsprechend zügig aufstellen müssen – ein Verfahren zur Bewertung und Einplanung der Zurufaktionen musste her. Wir beschlossen, das Team von störenden Einflüssen abzuschotten..

Spätestens jetzt war selbst mir klar, dass es eine Antwort auf unser(e) Problem(e) gibt.
Aber würde ich Scrum (oder auch nur einige Artefakte) in der vorliegenden Situation etablieren können?

- Wir sind umgeben (und als Team Bestandteil) von klassischen PM Methoden… die meisten davon „Top-Down“ von einer Hauptprojektleitung induziert, welche sogar bis auf Vorgangsebene die Planung vorgibt.
- Es gibt einige Artefakte, die in der Softwareentwicklung einen definitiven Zweck erfüllen.. aber wie sieht zum Beispiel das Product Backlog für ein Organisations-Projekt aus?
- Ein Team von sechs Menschen, die in diversen Projekten mitwirken über ein Scrum Board zu steuern (wichtig: sich selbst steuern zu lassen) und dieses Vorgehen auch noch ‚nach Oben’ hin zu rechtfertigen würde.. schwierig sein.
- Scrum hin oder her, es muss eine Brücke geschlagen werden zwischen agilen Methoden und klassischen Status Reports - meine Aufgabenstellung umfasst nicht nur ergebnisorientierte Projektsteuerung, sondern eben auch transparente Status Berichte ‘nach Oben’
- Die Performer haben keine Erfahrung mit Scrum.

Nach meinen Berichten über agiles Projektmanagement und insbesondere Scrum war mein Auftraggeber von dieser Idee überzeugt. Also einigten wir uns auf einen Versuch.

Und wie das Leben so spielt, kam am gleichen Tag ein Sekundärprojekt auf den Plan in welchem wir eine Ausschreibung vorbereiten sollten.

Also kurzum die Planung mit dem Auftraggeber durchgesprochen, Arbeitspakete erstellt und ab zum Schreibwarenladen. Paketpapier, Post-Its, Moderationskarten, Stifte, Posterkleber und Malerkrepp. Eigentlich kann es jetzt losgehen.

Also alle eingeladen zu einem Termin – zwei Bahnen Paketpapier an die Wand geklebt (und das sogar einigermaßen Waagerecht – ich bin ja so stolz!), mit bunten Karten beschriftet und in Spalten abgeteilt.. Fertig war das Scrum Board (welches fortan auf den Fluren vor meinem Büro für einige Verwunderung sorgen sollte – zumindest die war bereits auf meiner Seite)

(Anmerkung: Dem Scrum interessierten Leser ist bereits in meinem letzten Absatz aufgefallen, dass _ich_ die Arbeitspakete aufgeplant habe.. aber dazu gleich mehr.)

Also findet der Termin statt – zwei Stunden Kick Off für das Sekundärprojekt unter meiner Moderation. Mit gleichzeitiger Vorstellung des Scrum-Boards. Und der Methode. In zwei Stunden? Yeah right. Natürlich gab es so viele Fragen zum weiteren Vorgehen, dass wir den Termin glatt um eine Stunde überzogen haben – und selbst im Anschluss daran war der eigentliche Zweck von buntem Papier an der Wand noch nicht wirklich geklärt.

Jeder legt noch schnell ein Ei… erm – oder nimmt sich ein Kärtchen, klebt sein Namenskürzel als Post-It darauf und eigentlich ist ja jetzt alles klar, oder?
Dann sehen wir uns morgen Mittag wieder zum Boxenstop.

…

Ich rechne es dem Team sehr hoch an, dass sie mich zu diesem Zeitpunkt nicht einfach ‚plattgemacht haben’.. Gründe und Möglichkeiten dafür gäbe es genug.

Am nächsten Tag habe ich herausgefunden was das Problem war.
Die Performer standen bei Kaffee und Schokolade in meinem Büro und konnten mir glaubhaft versichern, dass Sie ja alles mögliche Versucht haben, aber die Aufgabenstellung habe einem kritischen Hinterfragen nicht standgehalten und so wurden die Aufwendungen zumindest dahingehend gering gehalten, dass die Arbeit bis zur weiteren Klärung eingestellt wurde.

Keine User-Story der Welt konnte die Aufgaben so umfassend erklären wie es die Performer untereinander im anschließenden Termin mit wenigen Worten konnten. Zur kurzen Erklärung möchte ich anfügen, dass die User Story im damaligen Fall eher eine Beschreibung des Ergebnistyps war.

Zu meiner Ehrenrettung muss ich sagen, dass ich zu diesem Zeitpunkt eventuell noch nicht einmal daran gedacht hatte, Scrum vollumfänglich einzusetzen – ich wollte lediglich einige Artefakte etablieren, welche die Steuerung leichter machen sollten.

Lessons Learned:
- Die Planung erfolgt im Team. Aus dem Team für das Team. Nur so ist sichergestellt, dass die Arbeitspakete inhaltlich verstanden werden.
- Scrum einzuführen ist entweder ein langsamer, aufbauender Prozess oder
- Ein schneller Prozess mit genügend Zeitinvestment für Vorbereitungen und Erklärungen.
- Kein Scrum Artefakt ist so gut, wie die Summe aus allen - gepaart mit der durchgängigen Anwendung.

Also blieb mir keine andere Wahl.. dem Papier an meiner Wand zufolge würden wir Scrum als Methode einführen. All the way, or no way at all.

To be continued…

Sorry, this entry is only available in Deutsch.