Kann ein Autor, Support und Vermarkter von Website-Inhalten Teil eines Scrum-Teams sein?

Wir prüfen endlich die Verwendung von Scrum für eines der Produkte oder und versuchen herauszufinden, was wir mit all den Leuten im Team machen sollen. Wir haben folgende Personen:

  • Entwickler
  • Tester
  • Kundendienst
  • Content Writer (nichttechnische Website-Texter)
  • Designer
  • AdWords-Vermarkter
  • Produktmanager

Wir wissen, dass wir Entwickler, Tester und einen Designer im Scrum-Team haben werden. Wir wissen, dass der Produktmanager in die Rolle eines Product Owners wechseln wird, und wir wissen, dass jemand aus dem Team ein Scrum Master sein wird.

Aber wo kommen Support, Content-Autoren und Vermarkter ins Team? Dies sind alles Leute, die sich diesem Produkt verschrieben haben und derzeit Teil des Teams in seiner Pre-Scrum-Konfiguration sind.

Können diese Leute Teil des Scrum-Teams sein? Warum oder warum nicht?

Antworten (2)

Wie bei allen agilen Dingen kommt es darauf an.

Ein Scrum-Team hat zwei oft widersprüchliche Ziele.

  1. Ein vertikaler Bereich der Organisation, der unabhängig funktionierende, getestete Software veröffentlichen kann. Dies erfordert oft ein breites Spektrum an Fähigkeiten.
  2. Funktionsübergreifendes „no roles“-Team. Scrum-Team-Individuen sollen auch mehr als nur „ihren Job“ machen können. Jeder kann eine Geschichte nehmen, jeder kann testen usw.

Bei dieser bestehenden Dichotomie kommt es also zunächst darauf an, welche Priorität Ihre Organisation in Bezug auf die oben genannten Punkte hat.

Aus meiner Erfahrung würde ich folgendes tun:

Kundensupport: Wenn Ihr Unternehmen groß genug ist, um einen Kundensupport zu haben, der so mit der Entwicklung interagiert, dann sind Sie wahrscheinlich groß genug, um ein Product Owner Team (POT) zu haben. Wo das Scrum-Team die Lieferung des priorisierten Backlogs besitzt, ist der POT die Erstellung des Backlogs. Das Scrum Team liefert ein Produkt, der POT liefert ein Backlog. Indem der Kundensupport in das Product Owner Team aufgenommen wird, können sie das Design von vornherein mitbestimmen. Da ich bereits zuvor in dieser Funktion war, konnte ich helfen, Kundenprobleme abzuwenden, indem ich praktische Erfahrung zur Verfügung stellte. Ich habe vor einiger Zeit in meinem Blog darüber geschrieben und eine ganze Diskussion darüber geführt, wie man gut geformte Backlogs und Product-Owner-Teams erstellt

Inhaltsschreiber: Ich gehe davon aus, dass dies anders ist als bei Dokumentationsschreibern. Wenn das Produkt ohne die Arbeit des Content Writers nicht ausgeliefert werden kann, müssen sie im Scrum-Team sein, auch wenn sie keine andere Arbeit (Codierung, Tests) erledigen können. Dies liegt daran, dass "Fertig" sie erfordert. Die Alternative besteht darin, sie zu einem Teil des Extend Scrum Teams zu machen. Dies ist das Konzept von Mitwirkenden, die nicht in jedem Sprint benötigt werden. Ein Datenbankmitarbeiter wird möglicherweise nur alle paar Sprints benötigt, sodass er im erweiterten Team sitzt und oft eine Ressource für mehr als ein Team ist. Wenn der Content Writer nicht in jedem Sprint benötigt wird, versuchen Sie dies.

Vermarkter : Product Owner Team. Gleiches Konzept wie beim Kundensupport.

Interessant. Wir dachten eigentlich, dass eine Support-Person eine gute Bestellung machen würde. In unserer aktuellen Pre-Scrum-Konfiguration arbeiten sie bereits eng mit dem Produktmanager zusammen, um Funktionen basierend auf Support-Interaktionen mit Benutzern zu besprechen und zu priorisieren. Es hört sich so an, als wollten Sie vorschlagen, dass wir weitermachen, was für sie bereits gut funktioniert.
Die Inhaltsautoren sind nicht nur Dokumentationsautoren. Sie können helpscout-Dokumente in der öffentlichen Wissensdatenbank für Benutzer aktualisieren, aber sie schreiben auch Inhalte für die Website, was oft ein Verständnis der Funktionen erfordert, die kürzlich vom Scrum-Team erstellt wurden. Wir dachten, ein Verteidigungsministerium könnte die Kopie auch auf der Website haben, aber wir können uns auch vorstellen, dass dies eine separate Einheit sein könnte, die mit dem Marketing verbunden ist. Wenn DoD Hilfedokumente einbezieht, dann denke ich, dass dies ein stärkeres Argument dafür ist, sie in das eigentliche Scrum-Team aufzunehmen.
Wenn Ihr Produktmanager keine Zeit findet, der Product Owner zu sein, dann wäre ein technisch versierter Mitarbeiter des Kundendienstes eine hervorragende Bestellung. Sie sind bereits daran gewöhnt, eine Stimme des Kunden zu sein. Basierend auf dem, was Sie für Inhaltsautoren beschreiben, würde ich sie auch in das Team aufnehmen. Könnte versuchen, ihnen ein Cross-Training im Test zu geben, um ihnen zu helfen, kooperativer zu sein.

Ich würde sagen, dass Sie all diese Leute wahrscheinlich nicht in dasselbe Team stecken sollten. Obwohl es ein interessantes Experiment wäre.

Ich muss mir Ihr Produkt- und Team-Setup ein wenig vorstellen, aber normalerweise habe ich festgestellt, dass Sie Folgendes erhalten:

Entwickler – Sie möchten, dass sie Funktionen für Ihr Produkt implementieren

Dies ist das Rückgrat Ihres Scrum-Teams, weil Sie Scrum eingeführt haben, um es entweder daran zu hindern, das zu tun, was es heute für gut hält, oder um einen übermäßig langen Wasserfallprozess zu verkürzen

Tester – Sie möchten, dass diese Typen Ihr Akzeptanztest für die Funktionen sind

Sie können Tester in ein Scrum-Team stecken, und viele Leute tun dies. Aber ich finde, es bewegt sie weg von der Rolle der „Akzeptanz von Features“ hin zu einer Testautomatisierungsrolle. Dies setzt den PO unter Druck, detaillierte Spezifikationen zu schreiben, anstatt sich auf Tests zu verlassen, um Probleme aufzuspüren und sie als Fehler zu melden

Designer – Sie möchten, dass diese Typen Ihnen ihre coolen Designs verkaufen

Sie können diese Leute ins Team stecken, „Seite X entwerfen“ ist eine nette Scrum-fähige Aufgabe

Produktmanager – Sie möchten, dass dieser Typ sich überlegt, wie das Produkt verbessert werden kann

Sie sollten sie als Product Owner ins Team aufnehmen

Support - Sie möchten, dass diese Leute die Kunden zufrieden stellen

Ich würde diese Typen nicht ins Scrum-Team stecken. Ich glaube nicht, dass Sie Kunden sagen können, dass sie warten sollen, bis ihre Hilfeanfrage in den Rückstand kommt und priorisiert wird, und wenn Sie dies tun würden, bräuchten Sie ein Team, das dies gut erledigt.

Inhaltsautoren – Sie möchten den Inhalt Ihrer Website aktualisieren

Ich würde sie nicht ins Scrum-Team stecken. Eines der Features Ihres Produkts sollte die „Content-Management-Oberfläche“ sein. Sobald dies abgeschlossen ist, sollten die Content-Autoren in der Lage sein, damit ihre Arbeit zu erledigen, unabhängig vom Scrum.

Es wäre großartig, wenn Webentwicklungs-Frameworks Möglichkeiten enthalten würden, Inhalte einfach vom eigentlichen Code zu trennen, aber so etwas ist mir noch nicht begegnet. Soweit ich unsere Unternehmenskultur kenne, würde die Implementierung einer solchen Funktion nicht als wertvoll empfunden, da sie sehr benutzerorientiert ist.
Content Management ist eine ziemlich grundlegende Funktion, WordPress, Sitecore, Sharepoint
Stimmt .... aber wir verwenden Java und Google App Engine und nichts, was mit diesen Dingen gut zusammenspielt und umgekehrt ... Dies sind auch Apps, keine Blogs oder Marketing-Websites.
Kann ein Autor, Support und Vermarkter von Website-Inhalten Teil eines Scrum-Teams sein?
AntwortenHierDatenschutz-Bestimmungen1y, 0v