Verwandelt Scrum aktive Entwickler in passive Entwickler?

Ich bin ein Webentwickler, der in einem Team von drei Entwicklern und einem Designer arbeitet. Es ist nun ungefähr fünf Monate her, dass wir die agile Scrum-Softwareentwicklungsmethode implementiert haben. Aber ich habe ein komisches Gefühl, dass ich nur auf dieser Seite teilen wollte.

Ein wichtiger Faktor im menschlichen Leben ist der Entscheidungsprozess. Es gibt jedoch einen großen Unterschied bei den Entscheidungen, die Sie treffen. Einige Entscheidungen sind nur das Ergebnis einer internen oder externen Kraft, während andere Entscheidungen vollständig auf Ihrem freien Willen beruhen, und einige Entscheidungen sind einfach etwas dazwischen. Je mehr Entscheidungsfreiheit Sie haben, desto selbstbestimmter wird Ihre Arbeit. Dies scheint eine Regel zu sein. Weil wir dazu neigen, unser Leben selbst zu gestalten.

Es gibt einen großen Unterschied, ob Sie entscheiden, was zu tun ist oder was zu tun ist .

Vor dem Scrum hatte ich das Gefühl, mehr Freiheit bei der Entscheidungsfindung zu haben, die sich auf Entwicklung, Analyse, Priorisierung der Implementierung usw. bezog. Ich hatte eher das Gefühl, zu entscheiden, was ich tue .

Aufgrund der Scrum-Methodik kommen viele Entscheidungen jetzt einfach vom Produktbesitzer. Er priorisiert PBIs , analysiert, wie die Software funktionieren soll, manchmal auch, wie die Benutzeroberfläche und die Funktionalität implementiert werden sollen. Ich weiß, dass dies Teil der Scrum-Methodik ist, und ich weiß auch, dass dies in Zukunft zu besseren Produktverkäufen führen kann. Jetzt habe ich jedoch das Gefühl, dass mir immer gesagt wird, dass ich etwas tun soll, anstatt mich dafür zu entscheiden, etwas zu tun . Dieses Syndrom hat mich jetzt passiver gegenüber der Arbeit gemacht.

1. Ich neige dazu, weniger zu suchen, um eine bessere Lösung, Herangehensweise oder Technik zu finden
2. Ich wache morgens nicht auf und erwarte eine angenehme Arbeit. Ich fühle mich vielmehr gezwungen zu arbeiten, um zu leben
3. Ich habe mehr Hunger danach, nach der Arbeit an meinen eigenen Hobbyprojekten zu arbeiten
4. Ich werde das Team nicht mehr dazu drängen, auf das höhere technologische Niveau zu gelangen
5. Ich verbringe jetzt mehr Zeit mit Abendessen oder Tee und habe weniger Lust, wieder an die Arbeit zu gehen
6. Ich bin jetzt bereit, mehr für die Arbeit zu tun, damit ich nach Hause kommen kann

Das große Problem ist, dass ich dieses Verhalten auch bei meinen Kollegen sehe und diagnostiziere. Ist es das Ergebnis von Gedränge? Hat Scrum wirklich das Gefühl, dass das Entwicklerteam keine Rolle bei der Gestaltung der Gesamtsoftware spielt, und macht es so passiv für das Projekt? Wie kann ich dieses Gefühl überwinden?

Jetzt habe ich jedoch das Gefühl, dass mir immer gesagt wird, dass ich etwas tun soll, anstatt mich dafür zu entscheiden, etwas zu tun.

Dies ist ein ernstzunehmender Hinweis darauf, dass etwas von den Gleisen geraten ist. Ein agiles Projekt sollte sich nicht so anfühlen. Diese Rhetorik "Menschen über Prozesse" sollte beinhalten "wir zwingen unsere Leute nicht, Dinge zu tun, die scheiße sind". Hier sind ein paar Ideen:

Machst du "scrum but"? Das heißt, teils Gedränge, teils etwas anderes. (zB: "Wir machen Scrum, aber alle unsere Geschichten müssen von unserem PMO stammen, nicht von einem Produktbesitzer.") Heutzutage wird viel verrückter Mist Scrum genannt.

Sind Sie persönlich nicht in den Prozess involviert, in dem Sie sein sollten? Ich habe eine Reihe von Leuten gekannt, die sich über den Inhalt von Geschichten aufregen, und es stellt sich heraus, dass sie sich erst dann einmischen, wenn die Geschichte im Sprint-Backlog ist. Sprechen Sie frühzeitig mit dem Product Owner in der Entwicklung der Story, und holen Sie sich Ihr Feedback. (Als PO haben sie das letzte Wort, aber das bedeutet nicht, dass sie es alleine tun müssen.)

In Scrum soll das Team den Prozess besitzen, und es wird erwartet, dass sich der Prozess im Laufe der Zeit ändert, um den Anforderungen des Teams zu entsprechen. Bringen Sie Ihre Bedenken in der Retrospektive zum Ausdruck. Wenn Sie eine Prozessoptimierung vorschlagen können, erleichtert dies in der Regel den Verkauf für einige Teams.

Ihr Problem ist nicht Scrum (und wie Jarrod Roberson in den Kommentaren erwähnte, ist es nicht Scrum, was Sie beschreiben) - es ist das Mikromanagement des Product Owners und die mangelnde Durchsetzungskraft Ihres (und Ihres Teams) .

"Aufgrund der Scrum-Methodik kommen viele Entscheidungen jetzt einfach vom Product Owner. Er priorisiert PBIs und analysiert, wie Software funktionieren sollte, manchmal sogar, wie UI und Funktionalität implementiert werden sollten. Ich weiß, dass dies Teil der Scrum-Methodik ist."

Du liegst falsch. Schon ein kurzer Blick auf die Wikipedia-Seite für Scrum zeigt: "Das Team, eine funktionsübergreifende Gruppe, die die eigentliche Analyse, das Design, die Implementierung, die Tests usw. durchführt." Sehen? Der Product Owner sagt Ihnen, was zu tun ist, aber es liegt am Team, zu entscheiden, wie dies geschehen soll.

Sie sind für die Implementierung verantwortlich, daher sollten Sie entscheiden, wie die Anwendung implementiert werden soll. Hören Sie sich die Meinung des Produktbesitzers an, aber die endgültige Entscheidung liegt bei Ihnen (oder dem Team).

BTW Mikro nicht aktive Entwickler in passive Entwickler wenden.

Was Sie beschreiben, ist NICHT SCRUM

Ihr Product Owner ist überfordert, wenn er Ihnen erklärt, wie Sie Ihre Arbeit technisch erledigen können, und darum geht es bei SCRUM überhaupt nicht.

Bei SCRUM geht es darum, den Entwicklern die Freiheit zu geben, sich auf Entwicklungsprobleme zu konzentrieren, und sie zu befähigen , selbst zu bestimmen, wie lange die Dinge dauern und wie sie zu tun sind.

Bei SCRUM geht es um die Zusammenarbeit, für die Sprint-Planungstreffen vorgesehen sind, um die Zusammenarbeit zwischen allen Beteiligten zu fördern. Produktbesitzer, Entwickler und Tester.

Ja, der Produktbesitzer sollte den Funktionen Priorität einräumen, was zuerst gemäß den Kundenanforderungen geliefert werden muss, aber die Entwickler sollten das Engineering und Design übernehmen, nicht der Produktbesitzer.

Ich bin nicht damit einverstanden, dass Entwickler GUIs und Workflows entwerfen sollten, es sei denn, sie sind speziell dafür beauftragt und geschult, mit den Kunden zusammenzuarbeiten und die Funktionalität direkt mit den Kunden auszutauschen. Vom Programmierer erstellte GUIs, die in einem Vakuum erstellt wurden, erfüllen selten die Kundenanforderungen.

Bei SCRUM geht es darum, einen leichten Prozess zu entwickeln, der im agilen Manifest vorhersehbar und wiederholbar ist.

Es macht mich traurig, Geschichten zu hören, dass sehr gute Dinge so pervers sind.

Ich vermute, vor Scrum haben alle nur das getan, was sie wollten: yippee ki-yay mf'er . Ihre Benutzer sind Ihre Wohltäter und sie treiben die Geschichte voran und bezahlen die Rechnungen. Der Product Owner sorgt dafür, dass die Story fertig wird. Wie auch immer, Ihre Gruppe kam zu dem Schluss, dass der Product Owner Ihnen sagen sollte, wie Sie programmieren sollen.

Sie möchten Code schreiben oder nette kleine Apps erstellen, die Sie für cool halten? "Ich möchte zuerst Feature A und nicht B spielen, damit ich meine Wahlfreiheit behalten kann." Finden Sie einen anderen Wohltäter und keine neue Entwicklungsmethode.

Sie sind im Titel des Projektbesitzers gefangen oder so. Wenn Sie einen triftigen Grund haben, der Geschichte nicht zuzustimmen, sagen Sie etwas und argumentieren Sie. Sie können nicht immer gewinnen. Es ist ihre Aufgabe, zu den Benutzern zurückzukehren und ihnen mitzuteilen, dass es ein gültiges Problem mit ihrer Anfrage gibt. Seien wir ehrlich: Wenn Sie in der Story aufgefordert werden, eine Datenbank den ganzen Tag über zufällig ohne Sicherung, ohne Datenverlust oder Ausfallzeit zu löschen, haben Sie ein Problem und die Pflicht, die Story zu korrigieren.

Es hört sich so an, als ob Ihre Abenteuer in Agile von Scrum korrumpiert wurden. Ich finde, dass Scrum von allen agilen Methoden die am wenigsten agile ist. Es ist eher wie kleine Wasserfälle und zusätzliches Projektmanagement. Dies macht es natürlich am beliebtesten für das Management, das den Eindruck hat, dass sie die Kontrolle von diesen nervigen Entwicklern zurückerhalten, aber Sie sehen natürlich die Realität der Situation.

Bei Agile geht es nicht darum, einem vorgegebenen Weg zu folgen, sondern Sie produktiver und motivierter zu machen. Menschen verarbeiten nicht, sagt das Manifest (umschrieben), und das geht in dem System verloren, das Sie verwenden.

Also ändere es. Wenden Sie sich an das Management und sagen Sie, dass dies ein rückläufiger Schritt ist, dass Ihre Produktivität geringer ist als früher und Sie alle mit der Art und Weise, wie sie funktioniert, unzufrieden sind. Zeigen Sie das Agile Manifest (und seinen bösen Zwilling ) und zeigen Sie, dass Sie nicht nur aus diesem Experiment Lehren gezogen haben, sondern auch die guten Teile daraus in ein besseres System umwandeln möchten (eines, das wie früher funktioniert hat) für dich).

Ich denke, dass ihr einfach daran gewöhnt seid, mehr Eigentum zu haben - und jeder, von dem ich denke, dass er das bevorzugt, seine menschliche Natur.

Leider denke ich, dass viel Software weniger ist, als es sein könnte, weil oft Teile für den Entwickler und nicht für den Kunden geschrieben wurden. Ihr neuer Ansatz sollte das reduzieren, aber auf Kosten Ihres Eigentumsgefühls.

Ich habe keine Ahnung, wie ich vorschlagen soll, dass du die Dinge besser oder lustiger machst, aber es ist eine großartige Frage und ein sehr guter Einblick.

Erhalten Sie User Stories in Form von "Als --Rolle--, ich möchte --Ziel / Wunsch--, damit --Nutzen--"? Es hört sich so an, als ob Ihr Product Owner die Designarbeit übernehmen möchte, und er / sie ist möglicherweise nicht die beste Person, um dies zu tun. Mithilfe des User Story-Musters kann sichergestellt werden, dass der Product Owner am Geschäftsinteresse festhält und die Softwareentwicklung von den Softwareentwicklern durchgeführt wird.

In Scrum haben die Entwickler viel Platz, um Beiträge zu leisten und Ratschläge zu neuen Funktionen, zur Benutzeroberfläche und zur Benutzerfreundlichkeit abzugeben. In Scrum ist eine Zusammenarbeit und Konversation zwischen Geschäftsleuten und Entwicklern erforderlich, die dies ermöglicht. Am Ende hat der Produktbesitzer jedoch immer das letzte Wort, da er für die Maximierung des Geschäftswerts der Software-Inkremente verantwortlich ist, die Sprint für Sprint erzeugt werden (mit anderen Worten, der ROI).

Aus dem Agilen Manifest:

Unsere oberste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufriedenzustellen.

Der Product Owner, der Ihnen mitteilt, wie Benutzeroberfläche und Funktionalität implementiert werden müssen, ist jedoch nicht akzeptabel. In diesem Fall sollten Sie das letzte Wort haben, da Sie für die interne Qualität der von Ihnen erstellten Software verantwortlich sind.

Vielleicht arbeiten Sie in einem Unternehmen, das von Entwicklern gegründet wurde, in denen Programmierer die Freiheit hatten, die gewünschten Funktionen zu implementieren. Die meisten agilen Methoden machen jedoch eine klare Trennung zwischen Geschäftsleuten und dem Team, das für die Erstellung von Software verantwortlich ist (Entwickler, Tester ...). Dies ist an den meisten Orten die häufigste Arbeitsteilung. Wenn meine Annahmen stimmen, kann ich verstehen, dass Sie das Gefühl haben, dass Sie keinen Einfluss mehr auf das Gesamtbild haben können, aber mit dem Wachstum des Unternehmens, denke ich, wäre das sowieso der Fall gewesen, Scrum oder nicht.

In Bezug auf Analyse-, Design- und andere von Ihnen erwähnte Metaentwicklungsaktivitäten (die wiederum nicht vom Product Owner durchgeführt werden sollen) sollten agile Teams funktionsübergreifend und silofrei sein. Niemand sollte über das gesamte Wissen rund um eine bestimmte Entwicklungsaktivität verfügen. Vielleicht haben Sie also die Möglichkeit, sich dort zu diversifizieren, anstatt nur "Code Monkeying" zu betreiben.

Im Gegenteil, ich habe festgestellt, dass die Entscheidung eines Produktbesitzers über die Funktionalität es mir ermöglicht, mehr Zeit für die Erstellung von Qualitätscode zu verwenden. Wenn es berechtigte Bedenken gibt, kann ich die Entscheidungen der Produktbesitzer jederzeit in Frage stellen, was normalerweise zu fruchtbaren Diskussionen führt.

Wir üben hier Scrum. Wir haben ein 14-tägiges Planungstreffen, bei dem wir die aktuellen Geschäftsprioritäten sowie die Erfolge und Misserfolge des vorherigen Sprints einfließen lassen und als Team entscheiden , was wir für den nächsten Sprint angehen möchten.

Dazu sortieren wir den Rückstand auf einer Platine vertikal nach Komplexität und horizontal nach Geschäftspriorität. Danach hat der Product Owner seine Eingaben erhalten, sodass das Team entscheiden muss, was wir tun möchten. Natürlich ist es verpönt, eine hochkomplexe Aufgabe mit niedriger Priorität zu übernehmen, aber wir entscheiden dies als Team. Dies verlängert die Planungssitzungen, lohnt sich jedoch und ist ein zentraler Bestandteil des Agile-Prozesses.

Und wir haben manchmal Mikromanagement, aber das ist ein anderes Problem.

Das eigentliche Problem, das Sie beschreiben, ist eine verbreitete Pathologie, wenn Teams eine Methodik anwenden: Sie schalten ihr Gehirn aus. Dies gilt für ein agiles New-School-System ebenso wie für ein Heavyweight-System der alten Schule.

F: Die Methodik schreibt x vor, aber x funktioniert nicht gut. Was sollen wir machen?

A: Verfeinern Sie Ihre Implementierung von x. Vielleicht hören Sie auf, es ganz zu tun. Die Methodik ist nicht der Boss von dir!

In diesem speziellen Fall scheint es, als würde der Product Owner zu viel tun. Fühlen Sie sich wohl, mit ihm darüber zu sprechen? Würden Sie sich wohl fühlen, wenn Sie nicht "Scrum machen" würden? Wenn der Product Owner nicht auf konstruktives Feedback reagiert, ist dies kein methodisches Problem, sondern ein Problem mit dem Product Owner.

Ich bin nicht wirklich mit dem ganzen Gedränge einverstanden, da es seit einiger Zeit mehr Wasserfälle gibt.

Aber um ehrlich zu sein, klingt dies eher nach einer Frage des Managementpersonals als nach einer Frage der Projektmanagementtechnik. Es basiert mehr auf Menschen als auf Techniken.

Die Rolle von Führungskräften in einem selbstorganisierenden Team wäre ein Blogbeitrag über etwas, das in Ihrem Beitrag zu fehlen scheint. Wo entscheidet das Team, welche Arbeit im Sprint geleistet wird? Wo ist das Team am Prozess und an der Arbeit beteiligt? Haben Sie jemanden, der Scrum so gut kennt, dass Sie Scrum machen, und keine perverse Version davon?

Ich hatte die gleichen Erfahrungen mit Scrum und nenne es gerne die "Tyrannei der Geschichte".

Meiner Erfahrung nach scheinen Entwickler im Bereich Creative / Design / Frontend mehr darunter zu leiden als Personen, die an der Backend-Arbeit beteiligt sind.

Der einzige Ausweg, den ich bisher gefunden habe, war entweder Scrum loszuwerden - oft nicht möglich und / oder angemessen, weil es schließlich seine Vorteile hat - oder so etwas wie die 20-prozentige Zeit von Google einzuführen, um Entwicklern eine kreative Möglichkeit zu bieten, abgesehen von dem "Sie". Sie können frei wählen, wie Sie die Anmeldeseite implementieren möchten ", da Sie in Wirklichkeit nicht so sind, wie Ihre Implementierung durch den vorhandenen Code und die Systemarchitektur eingeschränkt ist - es sei denn, Sie haben die Freiheit, zwischen einer for- und einer while-Schleife zu wählen Freiheit.

Es gibt einen großen Unterschied, ob Sie entscheiden, was zu tun ist oder was zu tun ist .

Nach meiner Erfahrung ist es nur ein langer Weg, von der Aufforderung zur Entscheidung, was zu tun ist, bis zur Entscheidung, was zu tun ist.

Am Ende dieses Weges stellt sich normalerweise heraus, dass wir nicht angewiesen wurden, weil sie Macht mögen und nicht, weil sie nichts Besseres zu tun haben. Ganz im Gegenteil, am Ende dieses Weges - wenn sie genügend Vertrauen in unser Team gewinnen - scheinen sie erleichtert zu sein und geben uns glücklich so viel Kontrolle, wie wir können (und wenn ihr Vertrauen wirklich fest ist, versuchen sie sogar zu bestehen) mehr als das)

Oh und meiner Erfahrung nach hat das im Grunde nichts mit Scrum / Agile zu tun. Passiert mit Gedränge, iterativ, Wasserfall, was auch immer. Es scheint, dass die Vertrauenssache prozessunabhängig ist

In unserem Team sagt uns der Product Owner, was zu tun ist und wir entscheiden, wie wir es tun. Es ist wirklich wichtig, diese Trennung zu haben, sonst geraten Sie in die von Ihnen beschriebene Situation.

Nach meiner Erfahrung besteht Scrum darin, Sie genau zu beobachten, was Sie tun. Es sitzt einfach auf deiner Schulter und schaut zu, was du tust. Obwohl es seinen eigenen Vorteil hat, hasse ich die Scrum-Methodik. Es erwartet die Zählung, nicht die Qualität. Die Qualität wird durch die Scrum-Methodik beeinträchtigt.