it-swarm.dev

Verwandelt Scrum aktive Entwickler in passive Entwickler?

Ich bin ein Webentwickler und arbeite in einem Team von drei Entwicklern und einem Designer. In ungefähr fünf Monaten haben wir die agile Scrum-Softwareentwicklungsmethode implementiert. Aber ich habe das komische 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 Ihren Entscheidungen. 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 einfach etwas dazwischen liegen. Je mehr Entscheidungsfreiheit Sie haben, desto selbstbewusster wird Ihre Arbeit. Dies scheint eine Regel zu sein. Weil wir dazu neigen, unser Leben selbst zu gestalten.

Es gibt einen großen Unterschied zwischen Ihnen entscheiden, was zu tun ist oder zu sagen, 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 mehr das Gefühl, ich entscheide, was ich tue.

Aufgrund der Scrum-Methodik kommen jetzt viele Entscheidungen einfach vom Product Owner. Er priorisiert PBIs , er analysiert, wie die Software funktionieren sollte, manchmal sogar, wie die Benutzeroberfläche und die Funktionalität implementiert werden sollten. Ich weiß, dass dies Teil der Scrum-Methodik ist, und ich weiß auch, dass dies in Zukunft zu einem besseren Produktverkauf führen kann. Jetzt habe ich jedoch das Gefühl, ich werde immer aufgefordert, etwas zu tun, anstatt mich für etwas zu entscheiden. Dieses Syndrom hat mich jetzt passiver gegenüber der Arbeit gemacht.

  1. Ich neige dazu, weniger zu suchen, um eine bessere Lösung, einen besseren Ansatz oder eine bessere Technik zu finden
  2. Ich wache morgens nicht auf und erwarte eine angenehme Arbeit. Ich fühle mich eher gezwungen zu arbeiten, um zu leben
  3. Ich habe mehr Hunger, 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 Teezeiten und bin weniger begeistert, wieder an die Arbeit zu gehen
  6. Ich bin jetzt mehr bereit, dass die Arbeit früher beendet wird, damit ich nach Hause komme

Das große Problem ist, dass ich dieses Verhalten auch bei meinen Kollegen sehe und diagnostiziere. Ist es das Ergebnis von Scrum? Hat Scrum wirklich das Gefühl, dass das Entwicklungsteam keinen Anteil an der Erstellung der gesamten Software hat, wodurch das Projekt passiv wird? Wie kann ich dieses Gefühl überwinden?

105
Saeed Neamati

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

Dies ist ein ernstzunehmender Indikator dafür, dass etwas von den Schienen geraten ist. Ein agiles Projekt sollte sich nicht so anfühlen. Diese Rhetorik "Menschen über Prozess" sollte beinhalten: "Wir zwingen unsere Leute nicht dazu, 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. (dh: "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 einmischen, wenn sich die Geschichte im Sprint-Rückstand befindet. Sprechen Sie früh in der Entwicklung der Geschichte mit dem Produktbesitzer 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 zur Sprache. Wenn Sie einen von Tweak vorgeschlagenen Prozess entwickeln können, erleichtert dies den Verkauf für einige Teams.

51
Sean McMillan

Ihr Problem ist nicht Scrum (und wie Jarrod Roberson in den Kommentaren erwähnt hat, ist es nicht Scrum, was Sie beschreiben) - es ist das Mikromanagement des Product Owner und Ihr ( und Team) mangelnde Durchsetzungskraft .

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

Du liegst falsch. Nur aus einem kurzen Blick auf Wikipedia-Seite für Scrum kann man Folgendes erkennen: "das Team, eine funktionsübergreifende Gruppe, die die eigentliche Analyse, das Design, die Implementierung, das Testen usw. durchführt." Siehst du? Der Product Owner fordert Sie auf, was zu tun, aber es liegt am Team, zu entscheiden, wie, dies zu tun.

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

Übrigens Mikromanagement tut aktive Entwickler in passive Entwickler verwandeln.

62
Lukas Stejskal

Was Sie beschreiben, ist NICHT SCRUM

Ihr Produktbesitzer ist überfordert, wenn er Ihnen sagt, wie Sie Ihre Arbeit technisch erledigen sollen. Darum geht es bei SCRUM überhaupt nicht.

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

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

Ja, der Product Owner sollte Funktionen priorisieren, was zuerst gemäß den Kundenanforderungen geliefert werden muss, aber die Entwickler sollten das Engineering und Design übernehmen, nicht der Product Owner.

Ich bin nicht der Meinung, dass Entwickler GUIs und Workflows entwerfen sollten, es sei denn, sie sind speziell beauftragt und geschult, mit den Kunden zu arbeiten und die Funktionalität direkt mit den Kunden zu teilen. Programmierer erstellte GUIs, die in einem Vakuum erstellt wurden, erfüllen selten die Kundenanforderungen.

Bei SCRUM geht es darum, einen leichten Prozess, der vorhersehbar und wiederholbar ist, über das agile Manifest zu bringen.

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

28
user7519

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 Miniaturwasserfälle und zusätzliches Projektmanagement. Dies macht es natürlich am beliebtesten für das Management, das das Gefühl hat, die Kontrolle von diesen lästigen Entwicklern zurückzugewinnen, aber natürlich sehen Sie die Realität der Situation.

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

Also ändere es. Sprechen Sie das Management an und sagen Sie, dass dies ein rückläufiger Schritt ist, dass Ihre Produktivität geringer ist als früher und dass Sie alle mit der Funktionsweise unzufrieden sind. Zeigen Sie das Agile Manifesto (und sein böser Zwilling ) und zeigen Sie, dass Sie nicht nur Lehren aus diesem Experiment gezogen haben, sondern auch die guten Teile daraus zu einem besseren System entwickeln möchten (Eine, wie Sie sie früher hatten, die für Sie gut zu funktionieren scheint).

11
gbjbaanb

Ich vermute vor Scrum, jeder hat einfach getan, was er wollte: yippee ki-yay mf'er. Ihre Benutzer sind Ihre Wohltäter und sie steuern die Geschichte und bezahlen die Rechnungen. Der Product Owner sorgt dafür, dass die Geschichte fertig wird. In gewisser Weise kam Ihre Gruppe 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 machen, damit ich meine Wahlfreiheit behalten kann." Finden Sie einen anderen Wohltäter und keine neue Entwicklungsmethode.

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

11
JeffO

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

Leider denke ich, dass viel Software weniger ist, als es sein könnte, da Teile oft für den Entwickler und nicht für den Client geschrieben werden. Ihr neuer Ansatz sollte dies reduzieren, jedoch auf Kosten Ihres Eigentumsgefühls.

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

8
Jonno

Erhalten Sie User Stories in Form von "Als - Rolle-- möchte ich - Ziel/Wunsch - damit - Nutzen -"? Es hört sich so an, als ob Ihr Product Owner die Designarbeit erledigen möchte, und er/sie ist möglicherweise nicht die beste Person, um dies zu tun. Durch die Verwendung 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.

5
Michael Munsey

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

Aus dem Agilen Manifest:

Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.

Der Product Owner, der Ihnen sagt, 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 dafür verantwortlich sind die interne Qualität der von Ihnen erstellten Software.

Vielleicht arbeiten Sie in einem Unternehmen, das von Entwicklern gegründet wurde und in dem Programmierer die Freiheit hatten, die gewünschten Funktionen zu implementieren. Die meisten agilen Methoden stellen jedoch eine klare Trennung zwischen Geschäftsleuten und dem Team her, das für die Erstellung von Software (Entwickler, Tester ...) verantwortlich ist. Dies ist an den meisten Orten die häufigste Arbeitsabteilung. Wenn meine Annahmen stimmen, kann ich das Gefühl verstehen, dass Sie nicht mehr in der Lage sind, "das Gesamtbild zu beeinflussen", aber mit dem Wachstum des Unternehmens wäre das wohl 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 sollten) sollten agile Teams funktionsübergreifend und silofrei sein. Niemand soll über das gesamte Wissen über eine bestimmte Entwicklungsaktivität verfügen. Vielleicht haben Sie also die Möglichkeit, sich dort zu diversifizieren, anstatt nur "Code Monkeying".

4
guillaume31

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

3
Misko

Wir üben hier Scrum. Wir haben ein zweiwöchentliches Planungstreffen, bei dem wir die aktuellen Geschäftsprioritäten sowie die Erfolge und Misserfolge des vorherigen Sprints berücksichtigen und entscheiden, als Team, was wir für den nächsten Sprint angehen möchten.

Eine Möglichkeit, dies zu tun, besteht darin, den Rückstand auf einem Board vertikal nach Komplexität und horizontal nach Geschäftspriorität zu sortieren. Danach hat der Product Owner seinen Input erhalten, daher ist es Sache des Teams, herauszufinden, 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. Es macht Planungssitzungen länger, aber es lohnt sich und ist ein zentraler Bestandteil des Agile-Prozesses.

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

3
Tim

Das eigentliche Problem, das Sie beschreiben, ist eine häufige Pathologie, wenn Teams eine Methodik anwenden: Sie schalten ihr Gehirn aus. Dies gilt für ein agiles System der neuen Schule genauso wie für Schwergewichtsysteme 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 ganz damit auf. Die Methodik ist nicht der Boss von dir!

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

3
Ian Olsen

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

Aber um ehrlich zu sein, klingt dies eher nach einem Problem des Managementpersonals als nach einem Problem der Projektmanagementtechnik. Wie in mehr Menschen als Technik basiert.

2
temptar

Ich hatte die gleiche Erfahrung mit Scrum und nenne es gerne die "Tyrannei der Geschichte".

Aus meiner Erfahrung scheinen Entwickler auf der Kreativ-/Design-/Frontend-Seite mehr darunter zu leiden als Menschen, 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 Googles 20% Zeit einzuführen, um Entwicklern einen kreativen Ansatz zu bieten, abgesehen von "Sie". Sie können frei wählen, wie die Anmeldeseite "implementiert werden soll, da Sie in Wirklichkeit nicht so sind, wie Ihre Implementierung durch den vorhandenen Code und die vorhandene Systemarchitektur eingeschränkt ist - es sei denn, man berücksichtigt die Freiheit, zwischen 'a für und eine Weile Schleife 'eine Freiheit.

2

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

2
JB King

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

1
Anto

Es gibt einen großen Unterschied zwischen Ihnen Entscheidung, was zu tun ist oder wenn Ihnen gesagt wird, was zu tun ist.

Nach meiner Erfahrung ist es nur ein ziemlich langer Weg von gesagt zu werden, was zu tun ist von zu entscheiden, 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 haben nichts besseres zu tun. Im Gegenteil, am Ende dieses Weges - wenn sie genügend Vertrauen in unser Team gewinnen - scheinen sie erleichtert zu sein und geben uns gerne so viel Kontrolle wie wir damit umgehen können (und wenn ihr Vertrauen wirklich fest ist, versuchen sie sogar, mehr als das zu bestehen)

Oh und meiner Erfahrung nach hat dies im Grunde nichts mit Scrum/Agile zu tun. Geschah mit Scrum, iterativ, Wasserfall, was auch immer. Scheint, dass die Vertrauenssache prozessunabhängig ist

1
gnat

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

1
thegreendroid