Wie verwalte ich agile Entwickler, die mit traditionellen (seriellen) Geschäftsleuten arbeiten? [geschlossen]

Guten Tag,

Meine Arbeitsumgebung hat einige Probleme. Unser IT-Team versucht, agiler zu sein, aber wir bekommen kein wirkliches Buy-In vom Geschäft. Sie nehmen an unseren täglichen Stand-Ups und Sprint-Überprüfungen teil und helfen bei der Sprint-Planung. Dann drehen sie sich um und sammeln 4 Monate lang Anforderungen für ein Projekt, bevor sie mit einem (meistens) seriellen Entwicklungsstil fortfahren. Die Sprintziele sind Dinge wie "XX% näher an die Veröffentlichung bringen".

Für das IT-Team haben sie die Sprints zu einer Art Todesmarsch gemacht. Wir beenden einen Sprint an einem Tag und starten am nächsten Tag einen neuen Sprint. Es gibt keine Reflexionen oder Änderungen zwischen Sprints, nur während.

Nachdem ich noch nie zuvor eine der agilen Methoden angewendet hatte, hatte ich keine sehr angenehme Einführung in sie. Meine Fragen sind also:

1) Sollte zwischen den Sprints etwas Zeit (vielleicht eine Woche oder so) liegen, um die Reflexion / Selbstbeobachtung / Veränderungen / etc. Durchzuführen? Oder sind Back-to-Back-Sprints die Norm?

2) Gibt es eine Überlebenschance für ein agiles Team ohne agile Geschäftsgegenstücke? Wenn nicht, gibt es einige Übergangsmethoden oder sogar Tipps, um das Unternehmen zu einer iterativen, wenn nicht unbedingt agilen Denkweise zu bewegen?

3) Sollte Ihr gesamtes Team bei jedem Sprint dabei sein? Wir haben fast 20 Programmierer in einem Sprint, arbeiten aber an völlig anderen Projekten (normalerweise Teams von 3-5, manchmal größer). Ist es normal, einen einzelnen Sprint zu haben, oder sollten wir versuchen, mehrere unabhängige Sprints zu verwalten? Sollten wir versuchen, die mehreren Sprints gleichzeitig im Gleichschritt zu halten, oder sollten sich ihre Zeitpläne überschneiden und flexibel sein dürfen?

Alle Gedanken oder Ratschläge werden geschätzt. Dies ist mein erstes Mal, dass ich für eine Frage von SO komme. Bitte lassen Sie mich wissen, ob es bessere Möglichkeiten gibt, diese Art von Fragen zu formulieren (FAQ war ziemlich hilfreich, aber immer noch nicht sicher, ob ich sie perfekt befolge). Vielen Dank!

1) Normalerweise können Sie einfach den letzten Sprint in einer Besprechung überprüfen, die nächste planen und damit beginnen. Überprüfen Sie insbesondere, wie genau die Aufgabenschätzungen waren, und geben Sie diese in die Schätzungen für den nächsten Sprint ein. Sie können den nächsten Sprint verzögern, wenn Sie auf Kundenfeedback aus den Ergebnissen des vorherigen warten müssen und glauben, dass Feedback die Aufgaben für den nächsten Sprint beeinflusst.

2) Es wird nicht einfacher, aber das Team kann natürlich erfolgreich sein. Dein Kommentar

Die Sprintziele sind Dinge wie "XX% näher an die Veröffentlichung bringen"

ist ein bisschen besorgniserregend, da Sie im Idealfall nachweisbare Features / Funktionen als Ziele in einen Sprint einbeziehen möchten.

3) Sie sagen, es gibt 3-5 völlig unterschiedliche Projekte. Wenn sie nicht miteinander verwandt sind, dh für verschiedene Produkte, müssen sie nicht synchronisiert werden, sie sollten jedoch jeweils als unabhängige Sprints behandelt werden. Es hört sich so an, als ob Ihre Teams für jeden Sprint wahrscheinlich eine gute Größe haben.

1) Sollte zwischen den Sprints etwas Zeit (vielleicht eine Woche oder so) liegen, um die Reflexion / Selbstbeobachtung / Veränderungen / etc. Durchzuführen?

Eine Woche? Du spinnst wohl. 2 Stunden ist das Limit.

Oder sind Back-to-Back-Sprints die Norm?

Absolut. Ansonsten drehen Sie Ihre Räder.

Gibt es eine Überlebenschance für ein agiles Team ohne agile Geschäftsgegenstücke?

Das Geschäft ist niemals "agil". Agil ist etwas, was Sie tun. Nicht die. In der Tat niemals sie. Sie fragen nur nach zufälligen Sachen. Du schaffst es.

Wenn nicht, gibt es einige Übergangsmethoden oder sogar Tipps, um das Unternehmen zu einer iterativen, wenn nicht unbedingt agilen Denkweise zu bewegen?

Keiner. Sie zerlegen die Anforderungen in Sprints. Es ist deine Disziplin. Nicht ihre.

Sollte Ihr gesamtes Team bei jedem Sprint dabei sein?

Ja.

Wir haben fast 20 Programmierer in einem Sprint, arbeiten aber an völlig anderen Projekten (normalerweise Teams von 3-5, manchmal größer).

Was? Das ist kein Team. Das sind ein paar Teams. 4 oder vielleicht 5 separate Teams.

Ist es normal, einen einzelnen Sprint zu haben, oder sollten wir versuchen, mehrere unabhängige Sprints zu verwalten?

Keine Ahnung wovon du sprichst. Aber da Sie anscheinend 4 oder 5 Teams zusammen haben, ist es klar, dass Sie massive Verwirrung stiften werden.

Sollten wir versuchen, die mehreren Sprints gleichzeitig im Gleichschritt zu halten, oder sollten sich ihre Zeitpläne überschneiden und flexibel sein dürfen?

Jedes Team - und die Sprints des Teams - sind das Problem des Teams. Niemand anderes.

Einige Leute Dinge, die große Projekte wie dieses ein "Scrum of Scrums" sein sollten. Teams setzen ihre Ziele, bauen ihre Sachen. Vertreter jedes Teams treffen sich regelmäßig, um die Teams zu koordinieren und zu für beide Seiten vorteilhaften Veröffentlichungen zu gelangen.

Es tut mir leid, dass Sie sich in einer offensichtlich dysfunktionalen Organisation befinden.

Wenn Sie Fortschritte messen möchten, müssen Sie unbedingt 100% vollständige Meilensteine ​​einplanen. Wenn es jemals Raum für ehrliche Meinungsverschiedenheiten darüber gibt, was ein bestimmter Meilenstein ist, besteht die natürliche Tendenz darin, dass die Person, die die Arbeit ausführt, eine möglichst optimistische Interpretation darüber vornimmt, wie viel sie getan hat, und die Person, die hört, was sie sagt, um das zu hören auf die optimistischste Art und Weise. Dies bedeutet, dass die Nachrichten immer besser werden, wenn Sie die Kette hochgehen, was zu einer völligen Trennung zwischen der Realität und dem führt, was die Spitze hört. http://www.davar.net/HUMOR/JOKES/SHIT.HTM ist eine humorvolle und völlig realistische Interpretation dieses Phänomens.

Wie schlimm ist diese Trennung? Bedenken Sie. Im durchschnittlichen Projekt verdoppelt sich die tatsächliche Zeit bis zur Fertigstellung (falls Sie jemals dort ankommen) im Durchschnitt der ursprünglichen Schätzungen. Unabhängig davon, um wie viel sich das Projekt verzögert, erhalten die Verantwortlichen in der Regel erst etwa zwei Wochen vor dem Fälligkeitsdatum die ersten Hinweise darauf, dass das Projekt im Rückstand ist, da dies der Punkt ist, an dem die Trennung zwischen den Erwartungen und Die Realität kann nicht länger verborgen bleiben.

Daher sind die XX% näheren Ziele keine tatsächlichen Anforderungen. Ihr Team sollte sich buchstäblich weigern, diese als tatsächliche Anforderungen zu akzeptieren. Es ist Ihre Aufgabe, sie darüber zu informieren, dass Sie konkrete, umsetzbare Aufgaben benötigen, und bei der Planung müssen sie in bestimmte Aufgaben unterteilt werden, die höchstens einige Stunden dauern können.

Zweitens müssen Sie, wie andere gesagt haben, Ihr Team unbedingt in kleinere Einheiten aufteilen, die wahrscheinlich unterschiedliche Zeitpläne haben müssen. Untersuchungen haben ergeben, dass ein einzelnes Software-Team von 20 Personen, die an einer Sache arbeiten, ungefähr so ​​viel leisten kann wie ein Team von 5 bis 8 Personen. (Ich bin auf diese überraschende Tatsache in Steve McConnells ausgezeichnetem Buch Software Estimation gestoßen .)

Drittens ist es eine wirklich große rote Fahne, dass es sich wie ein Todesmarsch anfühlt. Wenn es sich wie ein Todesmarsch anfühlt, ist es wahrscheinlich ein Todesmarsch. Softwareentwickler erzielen in der Regel Spitzenleistungen, wenn sie 35 bis 40 Stunden pro Woche arbeiten. (Ich habe diese Zahl von Steve McConnells Rapid Development erhalten .) Längere Arbeitszeiten können zu vorübergehenden Leistungssteigerungen führen, auf Kosten einer langfristigen Leistungsminderung. Ein großes Projekt ist ein Marathon, Sie müssen selbst Schritt halten.

Viertens muss es wirklich einen Rhythmus für einen Sprint geben. Als ich in einem Scrum-Team gearbeitet habe, fanden wir es sehr nützlich, jeden Sprint in zwei Abschnitte zu unterteilen, die wir "langer Fokus" und "kurzer Fokus" nannten. Während des "langen Fokus" haben wir die Softwareentwicklung auf die Aufgaben konzentriert, die für diesen Sprint vereinbart wurden. Während des "kurzen Fokus" haben wir alle notwendigen Dinge getan, die wir brauchten, um viele Unterbrechungen und Aufgabenwechsel zu ermöglichen. Zu diesem Zeitpunkt haben wir die Qualitätssicherung, die Fehlerbehebung, verschiedene Besprechungen und die Schätzung der Aufgaben für den nächsten Sprint durchgeführt und uns schließlich darauf geeinigt, was im nächsten Sprint passieren soll und was nicht. Dies hat bei uns sehr gut funktioniert, da viele Softwareentwicklungen nur durchgeführt werden können, wenn Sie sich in der "Zone" befinden, was im Allgemeinen nicht der Fall ist.

Wenn Sie einem solchen Rhythmus folgen, haben Sie einen weiteren Vorteil, wenn Sie unterschiedliche Zeitpläne zwischen den Teams haben: Ihre QA-Mitarbeiter können immer an dem Team arbeiten, das sich gerade in der QA befindet, wodurch sie ein konstantes Arbeitsniveau haben.

Viel Glück und seien Sie sich bewusst, dass Sie die Unterstützung ohne die Unterstützung von oben möglicherweise nicht beheben können. Wenn dies der Fall ist, besteht Ihre realistischste Option möglicherweise darin, eine gesündere Organisation zu finden, zu der Sie gehören können, anstatt zu versuchen, Ihre Organisation zu etwas zu machen, zu dem sie nicht werden wird.

1. Ich habe die Erfahrung gemacht, dass Sprints im Allgemeinen mit einem gewissen Zeitverlust verbunden sind, um Retrospektiven durchzuführen, Funktionen zu demonstrieren und den nächsten Sprint zu planen. Zum Beispiel wird der letzte Tag eines Sprints oft als Abschreibung angesehen, da es 3 Besprechungen gibt, die sich normalerweise über diesen Tag erstrecken, sodass ein zweiwöchiger Sprint 9 Arbeitstagen entspricht. Die Retrospektive am Ende eines Sprints kann Änderungen bringen, die im nächsten Sprint versucht werden müssen, der gewissermaßen fast sofort beginnt.

2. Eine Chance ja, aber eher klein, als ob Sie Scrum verwenden, sollte es einen Product Owner geben, der vom Management genehmigt wurde, um direkt zu priorisieren, wie dringend einige Geschichten im Vergleich zu anderen sind. Es muss ein gewisses Verständnis dafür geben, welche Verantwortung sie haben, obwohl ein anderer Teil darin besteht, dass "XX% näher an der Veröffentlichung" meiner Meinung nach eine eher schlechte Metrik ist, da dies dazu neigt, keine Fehler und andere Last-Minute-Probleme zu berücksichtigen, die kaum richtig zu beheben sind Schätzung in meiner begrenzten Erfahrung. Es gibt auch etwas zu sagen, um zu verstehen, wann Änderungen an Prioritäten dem Team bekannt sein und bei der Planung eines Sprints verwendet werden können. Das Management-Buy-In ist von entscheidender Bedeutung, wenn sie nicht verstehen, was Sie tun. Es kann sein, als würden Sie versuchen, Lieferungen zu tätigen, während Sie auf einem stationären Laufband laufen. Während sich deine Beine bewegen, bist du nicht

3. Nicht unbedingt, aber manchmal kann das der Fall sein. Der Schlüssel ist zu wissen, wie viel jeder Entwickler dem Projekt zugewiesen ist, und dies konsistent zu halten, damit dies bei einer Geschwindigkeit aus den ersten Sprints hilfreich ist, um zukünftige Geschwindigkeiten vorherzusagen, anstatt als Anzahl der Arbeitsstunden nutzlos zu sein Die Projekte springen zu viel herum, um leichter abschätzen zu können, wie viele Punkte in einem Sprint erzielt werden können. Jedes Projekt sollte seine eigenen Sprints haben, wenn das Projekt groß genug ist, um Wochen Arbeit zu umfassen.

Viel Glück bei der Schulung des Managements in Bezug auf das, was es zu tun hat und wie dies funktioniert, da dies Ihre große Hürde sein kann, die Sie hier überwinden müssen.

Wenn Ihr Projekt Scrum verwendet, sollten Sie einen Scrummaster haben, dessen Aufgabe es ist, alle Parteien darüber zu informieren, wie genau der Prozess funktionieren soll. Wenn Sie Scrum machen, klingt es so, als ob der Scrummaster seinen Job nicht macht, da es eine RIESIGE (und nicht ungewöhnliche) Hürde ist, keinen Buy-off von der Geschäftsseite des Projekts zu haben.

Sagen Sie den Programmleuten, sie sollen es vermasseln, wenn sie sagen, dass sie XX% näher kommen, um fertig zu werden. Sagen Sie ihnen, dass Sie die erforderlichen X, Y und Z bis zu diesem und jenem Datum beenden werden. Wenn sie den Zeitplan abschließen möchten, fragen Sie sie, was sie entfernen möchten, wenn sie ihnen nicht mitteilen möchten, dass sie entweder Teile entfernen oder Zeit hinzufügen. Wenn Sie sagen, dass Sie es schaffen oder sonst nichts Gutes tun. Wenn sie drücken, weisen Sie Ihren Projektmanagercode zu, um diesen Sprint abzuschließen. Denken Sie daran, Agilität ist eine Teamleistung. Wenn die Leute des Projektmanagements nicht 12 Stunden am Tag arbeiten, sind sie besser da, um Pizza und Limonaden für die Leute zu holen, und jeder Bonus, wenn es darum geht, Dinge planmäßig oder vorzeitig zu erledigen, geht besser zu den Leuten, die auch die Arbeit erledigt haben. Sagen Sie der oberen mgmt, wenn Sie auch haben, sie sind wahrscheinlich diejenigen, die Agile auf Sie gedrückt haben, ohne die Projektmanager zu schulen.

Verfolgen Sie Ihren Fortschritt, nehmen Sie Anpassungen vor und wählen Sie die nächsten Anforderungen aus. Wenn das Projekt erst geliefert wird, wenn das Ganze abgeschlossen ist, sorgen Sie sich nicht um die Priorität der Funktionen, sondern darum, welche Funktionen für Sie wichtig sind, damit sie für zukünftige Teile ausgeführt werden können. Sie müssen das Eigentum daran übernehmen. Es sollte auch kein Todesmarsch sein. Scrum-Projekte sollten den Arbeitsaufwand messen, den Sie während eines NORMALEN Sprints erledigen können. Diese 10 (oder 9 wie oben angegeben) normalen 8-Stunden-Arbeitstage.

Eine Sache, die ich vor einigen Jahren auf der Agile-Konferenz gehört habe, war, dass Ihr Team wie eine Fabrik ist und pro Sprint X Autos (oder in Ihrem Fall Merkmale) produzieren kann.

Auch Ihre Sprint-Teams sollten 3 bis 5 Personen sein, nicht 20. Das könnte ein Teil des Problems sein. Jedes Team sollte seine Geschichten auswählen (Anforderungszeilen, wenn Sie möchten) und daran arbeiten. Sie sollten separat scrumgen, sich aber auf einer bestimmten Basis mit einer großen Gruppe treffen, um Ideen auszutauschen.

Bei der Verwaltung dieser Teamtypen kann es für die Manager besser sein, separat zu scrollen, um festzustellen, welche teamübergreifenden Aufgaben erforderlich sind, und die richtigen Personen in Kontakt zu bringen. Ein 20-Personen-Standup ist eintönig und langweilig für die Beteiligten.