Scrum: Umgang mit mangelnder Motivation

Nach dieser „Scrum setzt stark auf eine hoch motivierte, eng zusammenarbeiten, übergreifende und selbstorganisierten Teams.“ Wie gehen Sie mit Mitarbeitern um, die möglicherweise nicht so motiviert sind, den Code zu übernehmen? Wie bringt man jemanden dazu, sich für eine Übernahme zu interessieren?

Ich weiß nicht, ob dies das Problem Ihres Teams ist, aber es war definitiv für uns, als wir Scrum zum ersten Mal einführten. Eines Tages kam unser Management zu uns und sagte, dass Sie von nun an nicht mehr in einzelnen Silos arbeiten werden. Stattdessen arbeiten Sie als Scrum. Hier sind eine Reihe neuer Prozesse, denen Sie alle folgen müssen und die Sie befolgen werden.

Der Schlüssel ist, dass sie nie zu uns, den Entwicklern, gekommen sind und gefragt haben, wie ihr arbeiten wollt. Was wird dich glücklicher machen? effizienter?. Ich hörte also: "Sie besitzen keinen Code mehr. Alles, was Sie schreiben, wird mit Füßen getreten (Sie wissen, Teambesitz). Sie werden keinen Finger bewegen oder rühren, weil wir Ihre Zeit jetzt stundenweise verwalten." Oh, und jetzt haben Sie jeden Tag einen langweiligen 15-minütigen Stand-up, bei dem die Leute Dinge besprechen, die Sie nicht interessieren, und es dauert normalerweise 30 Minuten, und dann wird alle zwei Wochen ein überaus langweiliges 4-stündiges Planungstreffen stattfinden, das sicher zum Kotzen ist alles Leben aus dir heraus.

In Wirklichkeit ist dies nicht Agile oder Scrum, sondern es geht nur darum, von einem Managementstil zu einem anderen zu wechseln, bei dem alles immer noch zentral gesteuert wird, und dies hat mir nicht nur das ganze Leben geraubt, sondern mir auch viel Freiheit gegeben Zeit, meinen Lebenslauf zu aktualisieren.

In den letzten zwölf Monaten, nachdem ich mich mehrfach dafür eingesetzt hatte, dass unser Teammanager etwas anderes probierte, nahm er mich tatsächlich auf meine Vorschläge auf, und ich denke, wir hatten ein sehr erfolgreiches Jahr.

Ich glaube, die wichtigste Änderung für uns war, den Entwicklern viel mehr Stimme und Freiheit bei der Auswahl zu geben, wie wir arbeiten möchten. Einige Dinge, die wir getan haben:

1. Teilen Sie das große "agile" Entwicklungsteam in 3 kleine auf, sodass jedes nur 3-4 Entwickler hat. Dies macht alle engagiert und Einzelpersonen werden nicht ertränkt.
2. Stellen Sie sicher, dass alle Mitglieder desselben Teams im selben Funktionsbereich arbeiten, damit sich die Mitarbeiter darum kümmern, worüber andere in Stand-Ups und Iterationsplanungen sprechen.
3. Anstatt einfach auszuwählen, wer an was arbeitet, und Geschichten / Aufgaben zuzuweisen, haben wir einen Rückstand erstellt, und das Team selbst hatte viel Einfluss darauf, wie die Arbeit aufgeteilt wird.
4. Da wir viele neue Mitglieder hatten, haben wir mit einem Silosystem begonnen, in dem jede Person einen Hauptverantwortungsbereich besitzt. Dies ermöglichte es neuen Leuten, sich auf kleinere Bereiche eines unbekannten Produkts zu konzentrieren und schneller das Gefühl zu bekommen, dass sie nicht in der Sandbox eines anderen spielen. Aber 6-8 Monate nach Beginn des Programms begannen sich diese Bereiche zu verwandeln, als die Grenzen grauer wurden. Jetzt fühlen sich die Jungs in den Teams, in denen ich bin, ziemlich wohl, wenn sie in den Code anderer eintreten oder andere Entwickler in ihrem arbeiten lassen.
5. Codeüberprüfungen aller Einsendungen waren der Schlüssel (und dies war das erste, worauf wir bei Scrum verzichtet haben):
   • Wissenstransfer in Bezug auf Programmiertechniken / -methoden
   • Es war großartig für andere, Code zu lernen, den sie sonst nicht gesehen hätten
   • Ihr Team hat die Möglichkeit zu kommunizieren und Kontakte zu knüpfen, was die Teamdynamik verbessert
   • Und ich denke, Code-Reviews werden ein oder zwei Fehler auffangen, aber ich sehe ihren Wert hauptsächlich in den oben genannten Aspekten.
6. Das Management muss dem Team zuhören. Wenn das Team sagt, dass etwas nicht funktioniert oder geändert werden muss, und dies einfach ignoriert, werden die Teammitglieder einfach auschecken und das Management das Projekt bearbeiten lassen. Wenn Sie möchten, dass Menschen motiviert werden, müssen sie unverfallbar sein, und sie werden nur dann unverfallbar, wenn sie das tun, was sie für richtig halten, und nicht das, was ihnen von oben gesagt wird.

Es gibt viele Gründe für mangelnde Motivation, aber wahrscheinlich ist das häufigste das Gefühl, nicht mitreden zu können. Als unser Team anfing, Scrum zu machen, bemerkte ich, dass sich die am wenigsten motivierten Leute über Scrum umdrehten, nachdem sie gesehen hatten, wie ihre Vorschläge aus den Retrospektiven umgesetzt wurden.

Eine Reihe kleinerer Probleme kann demotivierend sein. Eine Sache, die letzte Woche auftauchte, war beispielsweise ein Teammitglied, das 4:00 Meetings nicht mochte. Das ist leicht zu beheben.

Mit anderen Worten, der beste Weg, um herauszufinden, was Ihr Team demotiviert, besteht darin, sie zu fragen.

Indem Sie ihnen das individuelle Eigentum an dem Code geben.

Viele Geschäfte arbeiten nach einem "Team Ownership" -Modell. Dies ist ideal für die Zusammenarbeit und Risikominderung, aber nicht so gut, um Einzelpersonen zu motivieren, persönlich verantwortlich zu sein. Teambesitz kann zu durchschnittlichem Code führen, da es keinen individuellen Besitzanreiz gibt.

Lösung: Weisen Sie jedem Abschnitt des Codes Einzelpersonen als Verwalter dieses Teils des Codes zu, ermöglichen Sie jedoch den vollständigen Teamzugriff auf die gesamte Codebasis.

Siehe auch: /software//a/33464/1204