Product Management
Social Commerce kommt (langsam)
0Seit Jahren wird das Thema Social Commerce gehypt, vornehmlich von Agenturen. Statt zunächst an ihren Grundleistungen zu arbeiten, sind aus meiner Sicht zu viele eCommerce Neulinge/ Follower zu früh auf diesen Zug aufgesprungen und haben ihre knappen zeitlichen und monetären Ressourcen in diese neuen Formen der “Freundschaftswerbung” gesteckt.
Jetzt kommt der SC-Zug lansam in Fahrt. Bewusst wurde es mir gerade wieder als ich auf der Design-Plattform monoqi.com ein cooles Fahrrad entdeckte, das nicht nur preisreduziert € 635, sondern um weitere € 31,75 günstiger zu haben ist, wenn man den Kauf bei FB liked.
Nicht erwartungskonform ist der Prozess: Als Nutzer gehe ich davon aus, dass ich im/ nach Kauf das Produkt like. Es muss jedoch vor der Bestellung geliked werden.
Die größere (analytische und technische) Herausforderung aus Anbietersicht liegt sicher darin, den Betrag für das Liken optimal zu berechnen und entsprechend produkt- und zielgruppenbezogen dynamisch anzupassen.
Was sollte ein Scrum Master wirklich können
0Boris Gloger kommt in seinem Artikel auf einen neuralgischen Punkte, der allzu häufig nicht genügend beachtet oder gar falsch verstanden wird. Ja, es ist richtig, dass der Scrum Master “sein” Team beschützen und äußere Einflüsse abwehren soll. Es ist aber genau so richtig und wichtig, dass der Scrum Master “sein” Team führt, es in die Richtung steuert, die für die Zielerreichung – Commitement einhalten und kontinuierliche Verbesserung – notwendig ist.
Boris Gloger bringt es wie folgt auf den Punkt:
“… vielen scheint immer noch nicht klar zu sein, dass ein ScrumMaster eine Führungspersönlichkeit ist. Eine Person, die ein Scrum-Team führt. Seine Hauptaufgabe ist in erster Linie die Produktivitätssteigerung des Scrum-Teams. Aber wie kann er das erreichen, wenn er dieses Team nicht führt, wenn er keine Rahmenbedingungen setzt, wenn er mit dem Scrum-Team keine Ziele definiert …”
Quelle: http://borisgloger.com/2013/02/18/der-scrummaster-der-besser-keiner-sein-sollte/
—-
Der ScrumMaster, der besser keiner sein sollte
Wir haben hier schon oft über die Aufgaben des ScrumMasters geschrieben. Was mir aber in den letzten Monaten bei Gesprächen mit Kunden und Kollegen, mit anderen Consultants, ja selbst bei Blog-Beiträgen anderer Scrummies auffällt: Vielen scheint immer noch nicht klar zu sein, dass ein ScrumMaster eine Führungspersönlichkeit ist. Eine Person, die ein Scrum-Team führt. Seine Hauptaufgabe ist in erster Linie die Produktivitätssteigerung des Scrum-Teams. Aber wie kann er das erreichen, wenn er dieses Team nicht führt, wenn er keine Rahmenbedingungen setzt, wenn er mit dem Scrum-Team keine Ziele definiert und sich nicht darüber im Klaren ist, wohin er selbst will?
Mir ist vollkommen klar, dass die meisten Organisationen, die sich mit Scrum beschäftigen, noch nicht genau wissen, was ein ScrumMaster wirklich ist. Aber wie sollen sie es auch lernen, wenn die ScrumMaster selbst das nicht wissen und leben?
ScrumMaster sind konstruktiv, nicht destruktiv
Hey, der Job ist beinhart! Ja wirklich, denn ein ScrumMaster muss positiv sein, motivieren und vor allem muss er Zuversicht ausstrahlen. ScrumMaster, die die Bedeutung ihrer Rolle noch nicht verstanden haben, erkennt man unter anderem daran, dass sie anfangen, wie kleine Kinder zu nörgeln und darüber zu jammern, wie schlecht die Organisation zu ihnen und ihren Teams ist. Ich kann noch verstehen, dass ein ScrumMaster nicht immer gut drauf ist, das wäre zu viel verlangt. Wenn er aber destruktiv wird, möglicherweise aus Frustration, dann sollte er Urlaub machen. Am besten gleich sechs Wochen am Stück, nachdenken und sich einen Coach suchen, der ihm bei der Selbstreflexion hilft. Denn er muss für sich Gewissheit schaffen, ob er nur “fertig” ist, weil der Job echt anstrengend war, oder ob er möglichweise gerade seine eigentliche Aufgabe aus den Augen verloren hat.
Ein Resultat dieses Denkprozesses kann sein: Man hat einfach keine Lust mehr dazu hat, ScrumMaster zu sein. Genauso wie ich nach sieben Jahren als Wochenend-Krankenpfleger für mich entschied: “Aus! Keine Bettpfannen mehr ausleeren!” Von heute auf morgen war Schluss mit dem Job. Und ich hatte ihn sehr gerne gemacht. Aber wenn man morgens aufsteht und sich ständig selbst sagen hört: “Das geht nicht, weil, … hier komme ich nicht weiter, weil die anderen, …. das haben wir versucht, das funktioniert nicht …” – dann ist man negativ unterwegs, selbst wenn man es nicht einmal so meint. Ich meine nicht, den Tag an dem man einfach mal mit dem falschen Fuß aufgestanden ist. Das ist völlig ok. Ich meine den Tag, an dem dir klar wird: “Jetzt ist es zum Routinenörgeln geworden.”
Denn das Problem ist: Das Scrum-Team bekommt es mit. Die destruktive Haltung wirkt sich sofort aus.
Ein anderes Ergebnis des inneren Dialoges kann sein, dass man sich aufmachen will, um die hohe Kunst der Führung ohne Macht zu erlernen. Ich muss es hier noch einmal betonen: Der ScrumMaster führt ein Scrum-Team an. Dann wird ihm hoffentlich klar: Er steht dem Management gegenüber dafür gerade, wenn das Scrum-Team nicht besser liefert. Sich hinter den Impediments zu verstecken und zu sagen: “Die Organisation lässt mich nicht, ich hab ja schon alles versucht” – sorry, das habe ich schon viel zu oft gehört. Zumal es ja die Aufgabe ist, die Impediments zu beseitigen. Davon darf man sich nicht einfach abbringen lassen. Die NASA hat einen Leitspruch: “Scheitern ist keine Option!” Ich hätte keine Verfahren für funktionierende Sprint Plannings, Daily Scrums, Massen-Sprint Plannings, Retrospektiven usw. entwickelt, wenn ich zufrieden damit gewesen wäre, dass unsere Meetings halt langweilig und unproduktiv waren, oder meine Teams keinen Spaß hatten.
Oft war der Schlüssel zur Lösung der Fragestellung, die mich tagelang frustrierte, mit anderen zu reden, stundenlang zuhause darüber zu sprechen und meinen Frust seitenweise in meinem Journal runterzuschreiben. Und kaum schaut man von außen drauf, vielleicht mit der Hilfe eines Coaches oder im Gespräch mit einem anderen ScrumMaster, kommt oft die Lösung, ganz nebenbei. Der ScrumMaster, der gerade noch verzweifelt war, sieht: “Es gibt ja doch noch viele Möglichkeiten.”
Um das aber zu können, braucht es das innerliche Commitment des ScrumMasters, die Rolle in ihrer Gänze zu leben.
Als die Führungsrolle von heute, die Scrum-Teams trotz der umgebenden Organisation produktiver macht. Dazu braucht ihr Führungs-, und Coachingskills, methodisches Verständnis zum Lean Product Development, Fachkenntnis über den technischen Hintergrund eurer Teams und eine ganze Menge Mut zur Selbstreflexion. All das erlernt man nicht über Nacht. Es dauert 10.000 Stunden, etwas wirklich meisterhaft zu beherrschen. Dazu ist kontinuierliches Arbeiten an euren ScrumMaster Skills notwendig. Doch all das könnt ihr euch schenken, wenn ihr den Kern nicht leben wollt: ein Scrum-Team trotz der Widerstände, die leider unvermeidlich sind und dazugehören wie der Kater zur durchzechten Ballnacht, erfolgreich zu machen.
Für viele bor!sgloger Consultants, ScrumMaster und Trainer liegt die Befriedigung trotz aller Widerstände darin, die selbst gesteckten Ziele zu erreichen. Das geht nie auf die einfache Tour. Wir müssen, obwohl unsere Kunden mit uns den Weg gehen wollen, am Widerstand entlang arbeiten, ihn nutzen und dabei nicht den Mut verlieren. Glaubt mir, wir haben oft stundenlang über den Wahnsinn, den wir in einigen Projekten gesehen habe, den Kopf geschüttelt und gemeckert. Aber nicht vor unseren Kunden und wir haben unsere momentane Demotivation nicht vor ihnen gezeigt. Die Aufgabe als Consultant ist ähnlich der des ScrumMasters: Zuversicht ausstrahlen, selbst dann, wenn gerade niemand mehr an den Erfolg glaubt. Das ist unser Job und auch der eines ScrumMasters. Diese Art der Führung kann man lernen, aber nicht über Nacht und nicht ohne Hilfe des eigenen Vorgesetzten oder eines Coachs.
Immer aber gilt, dass ihr euren Job zunächst als das verstehen müsst, was er im Grunde ist: Der ScrumMaster ist ein Veränderer ohne Macht, der nur durch die Kraft seiner Überzeugung die anderen ansteckt, dabei mitzumachen. Wir finden diesen Job bereichernd und sinnvoll. Wir wünschen Euch viel Freude und Erfüllung dabei.
Agile Product Ownership in a Nutshell
0Über Agile Learning Labs bin ich vor Kurzem auf dieses Video von Henrik Kniberg gestoßen, der in 15 Minuten sehr anschaulich erklärt, wie agile Projekt aus Sicht des Product Owners funktionieren. M.E. ist das Video eines der besten, das ich zum Thema bisher gesehen habe, deswegen kann ich nur jedem empfehlen, sich die Zeit zu nehmen und es anzuschauen. Trotzdem will ich hier mal die wichtigsten Punkte kurz zusammen fassen:
- eine der wichtigsten Aufgaben des POs ist es, zu entscheiden, welche Anforderungen nicht umgesetzt werden / nicht ins Backlog kommen
- Welche Korrelation gibt es zwischen Story Value und Story Size? Keine! Größer heißt nicht automatisch wertvoller oder besser
- Am Anfang eines Projekts werden die Schätzungen im Hinblick auf Wert und Größe einer Story überwiegend daneben liegen. Das ist aber deshalb nicht so schlimm, weil eine kontinuierliche Kommunikation zwischen PO, Stakeholdern und dem Team die Schätzungen immer besser werden lassen. Product Ownerhip bedeutet in erster Linie also Kommunikation
Henrik erläutert im Video sehr schön, dass Software-Projekte immer mit verschiedenen Kompromissen verbunden sind und es letztlich immer darum geht, die richtige Balance zu finden:
1. Kompromiss zwischen Knowledge Value und Customer Value:
Jedes Projekt birgt am Anfang verschiedene Risiken:
- Business Risk: entwickeln wir das Richtige?
- Social Risk: ist das Team in der Lage, das Projekt erfolgreich durchzuführen?
- Technical Risk: entwickeln wir auf Basis der richtigen Technologie?
- Cost and Schedule Risk: können wir das Projekt mit einem vertretbaren Aufwand und innerhalb einer bestimmten Zeit umsetzen?
Wissen kann als das Gegenteil von Risiko angesehen werden, d.h. dass am Anfang eine Projekts, wenn das Risiko hoch ist, der Fokus auf Wissensgenerierung liegen muss. Deshalb sollte man sich zu Beginn z.B. auf User Interface Prototypen und die technische Architektur konzentrieren. Diese sind zwar aus Sicht der Stakeholder nicht unbedingt wertvoll (oder zumindest ist der Wert für Stakeholder schwer nachvollziehbar), aber vor dem Hintergrund der Risikominimierung extrem hilfreich. Je geringer das Risiko wird, desto größer wird der Customer Value, den das Team durch die Umsetzung von User Stories generiert.
2. Kompromiss zwischen langfristigem und kurzfristigem Denken: Was sollen wir als nächstes bauen?
Hier läuft alles darauf hinaus die Balance zwischen Firefighting und Fireprevention zu finden.
3. Kompromiss zwischen den verschiedenen Sichtweisen der unterschiedlichen Rollen auf das Projekt
Der Schwerpunkt des POs liegt auf der Frage, ob das richtige Produkt entwickelt wird (Building the right thing?) Das Team fokussiert sich in der Regel eher auf die Frage, ob das Produkt in der richtigen Art und Weise entwickelt wird (Building the thing right?). Und der Scrum Master (und natürlich auch die Stakeholder) hat den Fokus auf der Geschwindigkeit (Building it fast?)
4. Kompromiss zwischen neuer Entwicklung eines neuen Produkts (oder Produktfeatures) und Optimierung des “alten” Produkts (oder Produktfeatures)
Wie gesagt, das Video ist absolut sehenswert, allein schon wegen des schönen Satzes am Ende:
If your organization doesn’t like truth and honesty it probably won’t like agile.
Explizit personalisierte Filter
0MyToys hat eine Funktionalität eingeführt, über die die Filter explizit personalisiert werden können. Dabei können grob die Eigenschaften des Kindes in Form von “Geschlecht” und “Alter” angegeben und gespeichert werden. Der Filter wird dann automatisch in jeder Kategorie angezeigt, so dass die persönliche Einschränkung des Sortiments auf jedes Sortiment angewendet wird, ohne dass erneut Filtereinstellungen vorgenommen werden müssen. Die Einstellungen werden im Cookie bzw. für angemeldete User im Profil gespeichert.
Diese Funktionalität ist besonders für Shops mit großen heterogenen Sortimenten geeignet, bspw. für Otto, Amazon oder auch Anbieter wie Zalando. Auf deren Zielgruppen übertragen könnten Kriterien wie “Marke”, “Farbe”, “Passform” oder auch “Größe” für unterschiedliche Sortimente angegeben werden. Durch die Möglichkeit mehr als einen persönlichen Filter anzulegen können verschiedene Szenarien abgedeckt werden, zum Beispiel die Eigenschaften verschiedener Personen oder auch Anlässe. In Summe also ein leicht zu bedienendes Feature mit hohem Kundennutzen. Voraussetzung für einen zuverlässigen Einsatz sind natürlich umfangreiche und konsistent gepflegte Produktdaten/-attribute.
Learnings aus der Scrum-Einführung bei amazon.com
0Im Blog ‘The Agile Excecutive’ von Israel Gat und Michael Coté berichtet Alan Atlas als Scrum Coach über seine Erfahrungen und Erkenntnis bei der Einführung von Scrum bei amazon US (Scrum at Amazon):
“Agile practices were present at Amazon.com as early as 1999, but it wasn’t until the years 2004 – 2009 that widespread adoption of Scrum occurred throughout Amazon’s development organizations. Amazon.com’s unplanned, decentralized Scrum transformation is of interest because it is different from the current orthodoxy regarding enterprise Scrum transitions, and its strengths and weaknesses reveal some fundamental lessons that can be applied to other enterprise Scrum transitions.
Here are the major forces that played in the transition.
Permission
Teams (including local management, of course) at Amazon have historically been given wide latitude to solve their problems (coupled with responsibility to do so without waiting for outside help) and are usually not overburdened with detailed prescriptive practices promulgated by centralized corporate sources. The emphasis is on creating, delivering, and operating excellent software in as streamlined and process-light a way as possible. Teams at Amazon have permission to choose.
Teams
The corporate culture at Amazon.com has always been surprisingly consistent with and friendly towards Agile practices. The 2 Pizza Team concept has been written about many times over the years (click here), and a close look shows that a 2 Pizza Team is basically a Scrum team without the Scrum. Teams at Amazon, especially 2 Pizza Teams, are stable and long-lived. Usually a development team reports to a single direct manager.
Knowledge
All it took to light the fire was someone who was willing to spend a little time educating interested parties about Scrum. Teams who learned about Scrum were able to make local decisions to implement it. Results were demonstrated that kindled interest in other teams.
Impetus
Over time, an email-based Scrum community formed. Scrum Master training was provided on an occasional basis by someone who simply wanted to do so. Basic Scrum education continued on an ad hoc and voluntary basis. Eventually enough teams had adopted Scrum that a need was seen and a position of Scrum Trainer/Coach was created. Having a full-time Trainer and Coach available made adoption easier and improved the quality of scrum implementations. By mid-2008 the community was able to support an Open Space Scrum Gathering within the company.
What was (and one assumes is still) missing was higher level engagement at the organization and enterprise levels. No executive support for Scrum ever emerged, and the transition was therefore limited primarily to the team level, with many organizational impediments still in place.
The success of Scrum at Amazon validates one easy, frictionless way to begin a Scrum transition.
Establish stable teams
Make Agile and Scrum information widely and easily available
Give permission to adopt Scrum
The advantage of this approach is that it requires a minimum of enterprise-wide planning and it allows teams to select Scrum, rather than mandating it. All of the rest of an enterprise Scrum transition can be accomplished by simply responding to impediments as raised by the teams and providing management support for change. Based on experience, the impediments raised will include demand (pull) for coaching, scaling, training, organizational change, a Transition Team, PMO changes, and all of the other aspects of an enterprise transition that many organizations labor so mightily to plan and control. Leadership for this kind of transition can only be Servant Leadership from the C-level, which is exactly the right kind for an Agile initiative, isn’t it?
The only impediment to Scrum adoption at Amazon was lack of knowledge. Teams were in place, and permission was part of the culture. When knowledge was provided, teams adopted Scrum. The strength of this process was based on the fact that only teams that were interested in trying Scrum actually tried it. There was no mandate or plan or schedule for this uptake. Nobody was forced to use Scrum. Teams made an independent, informed decision to try to solve some of their problems. Lean and Agile thinkers will recognize that this as a pull-based incremental approach and not a plan-driven, command and control, push-based approach.
What about the things that didn’t happen at Amazon? The transition stalled at the team level due to failure to engage either middle or upper management in a meaningful way. Both of those groups are required to bring a transition to its full potential. Training for middle managers, in particular, is crucial, but will usually reach them only with executive sponsorship. A Transition Team is crucial when organizational and enterprise-wide impediments begin to be unearthed. Support from a source of advanced knowledge and experience (trainer/coach) is key.
Was Scrum good or bad overall for Amazon? There is only spotty, anecdotal data to report. Certainly there are many stories of teams that used Scrum very successfully. The Amazon S3 project, which not only delivered on time after about 15 months of work, but nearly achieved the unusual result of having the entire development team take a week’s vacation leading up to the launch day. It was not the crunch-time, last minute, panic-drenched effort that is common with projects of this scope and complexity. There was the team that “hasn’t been able to deliver any software for 8 months” that, sure enough, delivered some software a month later at the end of their first sprint. Another team reported that their internal customers came to them some time after the team had adopted Scrum, asking that they implement a whole list of random features. “We know these aren’t your responsibility, but you’re the only team that is able to respond to our requests.” Finally, there was the platform team that had literally dozens of internal customers. When that team adopted Scrum, they organized their customers into a customer council of sorts and let them simply decide each month what the team would work on, for the good of all, in order of value to Amazon overall. But even if none of these anecdotes were available to tell, the mere fact that teams opted on their own to adopt Scrum implies that something about Scrum helped them be more successful and more satisfied professionally. If that were not true, then they would not have stayed with it at all, right?”
Neil Perkin: The Rise Of Product Management
0What is a good pithy description for the role of a Product Manager?
A product manager in the digital space is someone who really owns the whole process of creating and executing products that audiences love.
Know-how: Agile vs. Wasserfall (Live-Session)
0Autor: Martin Seibert
Live+Sessions+zur+Online-Beratung
Martin stellt Ergebnisse einer umfangreichen Studie aus 2010 vor, die bekannte Thesen zu den Vorteilen agiler Methoden bestätigen und konkretisieren.
Es ist allerdings keine Schwarzweiß-Malerei: auch der Wasserfallansatz wird unter definierten Bedinungen empfohlen.
Arbeitsweisen im Interaction Design
0Autor: Jonas Löwgren
Der schwedische Professor erläutert in seiner Key Note der Interaction 12 die kreative und nur teilweise planbare Arbeitsweise erfolgreichen Interaction Designs. Ein Grund mehr sich agilen Vorgehensweisen anzuschließen. http://tiny.cc/wpbicw
Eigenschaften eines Online-Product Managers bei Google
0Assem ist Online-Produktmanager bei Google. Gemäß seinen Erfahrungen zeichnet sich ein PM im Online-Service-Bereich durch folgende drei Product Manager Skills aus:
1. Leidenschaft für Technologie: Damit ist das starke Bedürfnis, neue Technologien auf ihre Anwendungsmöglichkeiten hin zu untersuchen gemeint.
2. Unternehmerfähigkeiten: Damit sind im Kern nicht die notwendigen (lernbaren) betriebswirtschaftlichen Fähigkeiten gemeint, sondern der unbedingte Wille, ein relevantes Produkt zu schaffen und am Markt erfolgreich zu machen.
3. Kommunikationsfähigkeit: Damit ist nicht nur die Fähigkeit, sondern auch das Interesse gemeint, sich mit den verschiedenen an der Produktentwicklung beteiligten Personen und Disziplinen zu beschäftigen, ihre Blickwinkel einzunehmen und ihre Kritik aufzunehmen.
Inwieweit diese Eigenschaften erlernbar sind, lässt Assem offen. Auf jeden Fall lassen sie sich im Rahmen des Recruitings relativ gut überprüfen und stiften damit ggf. einen Beitrag auf den Suche nach (potenziallen) Product Manager.
Nutzer werden immer ungeduldiger – Ladezeit wird zunehmend wichtiger
1Die folgende Infografik zeigt – wenn auch leicht polemisch – interessante Statistiken rund um das Thema Performance.



